I was hoping that feature branch would start with the code you mentioned. For my use case, just piping the data into the backend is more than sufficient, and I'd be happy to flesh out the number of items that are being parsed. In addition to the already-extant X-Forwarded-For, I'd recommend the following:
- X-SSL-Protocol - X-SSL-Cipher - X-Client-Cert-Verify - X-Client-Cert - X-Client-Cert-Serial - X-Client-Cert-Subject-DN - X-Client-Cert-Issuer-DN An additional X-Compromise-Attempt or X-Illegal-Headers would be a nice option for backends that want to know when clients try to pass these reserved headers from outside. I can follow this up with a bit of example code to grab each of these out of the SSL connection object. k On Tue, Nov 6, 2012 at 11:16 PM, Willy Tarreau <[email protected]> wrote: > Hi Karel, > > On Tue, Nov 06, 2012 at 02:47:33PM +0100, Karel Sedlá??ek wrote: > > I understand that there's some prototypical functionality for analogies > to > > nginx $ssl_client_s_dn et al. I'd be quite happy to get my hands on this, > > as I've been having issues with way too many components of my stack re: > > properly extracting certificate info, supporting newer cipher suites, or > > even exposing the certificate info in their TLS bindings/implementations. > > For better or worse, nginx is also not a solution, as its current > > proxy_pass method fully buffers the request, killing websocket. The other > > solution is that I write a very small streaming proxy to unwrap the TLS > and > > inject the relevant headers, but haproxy already does 99% of this, and > that > > level of code duplication seems like madness. > > We've already experimented with this at Exceliance. We've not produced code > that makes us happy. We developped the fetches not for ACLs but in order to > extract fields to put into logs and HTTP headers. What we need to do now is > to add the configuration language to map ones to the others. We've made > some > attempts but were not much satisfied with them. To be honnest, we're > currently > stabilizing the code for dev13 first and we'll get more focused on this > just > after. > > The code is not much an issue, we need to decide how we'd like users to > configure this in a flexible way to satisfy all needs. This can be > discussed > right here on the list if you want, after all it's a development list and > it's where the users are (ie those who decide in the end). > > > Code beauty is not a major > > concern to me at this point, and I'd be happy to contribute back any > > changes I make--could we get a feature branch for this in github? > > Feel free to do so if you want but better settle on how this should be > configured and used first, it would avoid painful issues at the end. > > Willy > >
