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.
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.
> 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.
> 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.
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.
Willy
