On Wed, Nov 7, 2012 at 8:07 AM, Willy Tarreau <[email protected]> wrote:
> Hi Karel,
>
> On Wed, Nov 07, 2012 at 05:55:15AM +0100, Karel Sedlá??ek wrote:
>> 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
>
> From what I've seen on the net and at various customers, we cannot fix
> the header names, we need to have them user-configurable. Also, some
> users want some of these info, others want some other info. For example
> I know at least one place where the whole PEM cert is desired (we don't
> have it right now), because of encoding issues in the ASCII representation
> of the subject DN.
Right; my intention with including the header names wasn't to suggest
that they can't be configurable, but because they were c&p'ed out of a
file that I had been working on to fill this functional role. They
should certainly be configurable.
>
> What I'd like to do is to be able to define the equivalent of a new reqadd
> directive which supports fetch names. It could probably be done in the
> http-request rulesets, which can be set both in frontends and backends.
> It could also be done somewhere else. The idea would be to reuse the
> string construction we have for log-format (which allows to mix text and
> tags and adjust the format, quoted vs non-quoted).
>
> For instance it could end up with something approximately like this :
>
> http-request add X-Client-Cert-Subject-DN %{ssl_c_s_dn}
> or :
> http-request add X-Client-Date %{ssl_c_notbefore}-%{ssl_c_notafter}
>
> Among the points I'm thinking about, maybe http-request is not well
> suited because it's called early and we'd prefer something that is
> called late, just before use_backend (for the frontend) and just
> before use-server (for the backend). That would avoid issues with
> conditions based on these headers in the request, and will also allow
> us to clear them. We must find a syntax which avoids as much as
> possible conflicts with regex so that we can reuse it later when we
> want to introduce this in reqrep, redirects, etc... That's why I think
> that %{} is not bad at all.
I'm ok with %{}; other common syntaxes include #var $var #{} and ${},
particularly in the case you allow variables to be operated on, e.g.
${var / 2}.
>
>> 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.
>
> These ones are obvious to do by configuration and do not need any code,
> they're just an ACL. You could even imagine to replace each of these
> headers with X-Illegal-$header-name for logging purposes.
Ditto for this regarding configurability. And, glad to hear it.
>
>> I can follow this up with a bit of example
>> code to grab each of these out of the SSL connection object.
>
> I did this exercise several weeks ago and found that if we systematically
> add each header that at least one user is interested in, you have so large
> requests that they don't fit in buffers anymore. And that's not counting
> the varying header names ! So clearly we need to make them configurable.
Ditto again; the headers (i.e. their corresponding properties) that I
listed are an overlapping set of data. Probably you wouldn't need the
whole client cert and each of its individual parts at the same time.
If you're doing certificate-based auth, you probably either just want
the subject CN (and configure HAProxy to reject unverified client
certs) or the CN and verified status. If you want to verify the cert
as well, until HAProxy supports doing OCSP client cert verification,
you could use either the whole cert (preparing the request yourself),
or, if it's your own infrastructure issuing certs, set up a service to
reject serial numbers, and have HAProxy pass the serial along. Because
there are many possible use cases, there should be many possible
options, but only a small subset of them is likely to be used at any
given time.
>
> Some tricks about encoding are important too. If some headers contain
> commas, we're supposed to quote-encode them. Idem for spaces at begin
> or end of values. For example, if the following subject is sent as-is
> in a header :
>
> C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft,
> CN=www.freesoft.org/[email protected]
>
> Then the header technically contains 6 comma-delimited values, which
> intermediaries are free to split into 6 different headers if needed,
> or even to remove spaces around commas. So this value must have quotes
> around it. But I'm sure that not all software support quotes, so this
> again must be a user-selectable encoding format.
There seems to be little incentive to split the headers as described,
so I doubt many applications do that. Testing products to see if they
support quoting is dead easy, though, so if that's the canonical form
I suspect you could get a decent cross section on it pretty easily.
Consider supporting base64 encoding of this value.
>
> Willy
>
