Hi David, On Wed, Jan 29, 2014 at 10:53:22PM -0500, David S wrote: > I want to use HAProxy to terminate my incoming SSL connections and forward > the messages to my server application. My challenge is that my > application needs information from the client certificates. > > The Proxy Protocol is one way that connection information can be forwarded > from HAProxy to the receiver. I'm interested in extending the Proxy > Protocol to include client certificate information. > > The Proxy Protocol documentation mentions that this has been considered > before.
yes indeed. > Do you have any advice for someone who might start developing a patch to > extend Proxy Protocol? The difficulty lies more in trying to achieve something compatible with existing implementations than writing the code. One of the problems is to consider other information some people might want to pass. I'm thinking about the interface name, SSL/TLS version, ciphers, SSL session ID, SNI, local cert, ... We don't need to implement all this. But we need to ensure that whatever we add will not prevent these from being added later. One possibility would be to add new keywords. But that makes something quite complex to parse for receivers, and it's already very problematic not to know how many bytes to read. For example, in Postfix, postscreen uses recv(MSG_PEEK) and cannot poll, so it would like to know easily how many bytes to read in each block and if possible not to have to parse one char at a time. Another option could be to implement it only in the V2 of the protocol which is binary. The length is variable and depends on the types present in the header. So the parsing is very fast. I think one solution would be to implement a new command which would represent the encapsulated information, and that LOCAL (\x00) or PROXY (\x01) are alwas final. For example, let's imagine we have SSLCRT=\x02 followed by a length and a cert, then by a command again. By doing so we can easily implement up to 254 extra commands, thus as many extra types. One point of particular care is that the length of each field is encoded on 8 bits. If that's not always enough, maybe it would be simple enough to decide to cut large data into chunks. Another possibility would be to use a variable length encoding, but this is not always properly implemented, and is sometimes hard to implement for the sender. For example, if we consider that 16kB per data type, we can encode the length using values 0..191 as 1-byte, and values 192..255 as 14 bits (6 bits followed by an extra byte). But as it stands now, I really think that chunking large data into 255-or-less chunks is much easier for everyone, including the receiver which will need less buffers. > Are there alternatives that I should consider? There's always an alternative, which is to decide whether or not it would make sense to migrate the application to HTTP, where all of this becomes immediately available for free. Maybe at the beginning it's not planned to do so, but in the long term, using HTTP is useful because it adds lots of new possibilities (proxies, compression, cookies, ...). Regards, Willy
