Re: [PATCH] Add request_header_add option and [request|reply]_header_* manglers fixes

On 07/01/2012 05:25 AM, Amos Jeffries wrote:

> Going by the patch display functions these are what the token names
> should be for consistency:
>
> %LOGIN ==> %ul [username from authentication]
> %SRC ==> %>a [client IP address]
> %DST ==> %<A [destination FQDN]
> %% [no change]

OK.

> The SSL tokens we have not exactly defined a namespace for since logging
> does not log them yet.

FWIW, I am sitting on a patch adding %ssl::bump_mode to logformat :-).
Just waiting for the BumpSslServerFirst patch feedback because
%ssl::bump_mode code depends on that code.

> Since my earlier posts about %ssl:: namespace it
> occurs to me we should probably be taking the opportunity to move to TLS
> terminology. Which would make it "%tls::" prefix to TLS/SSL format
> tokens. Agreed?

No strong opinion, but I think "ssl" is better than "tls". No single
protocol name lasts forever so it is better to use what folks are used
to, and "ssl" is the name most of us use, I think, when we do not care
about the specific security protocol.

If you think "ssl" is too old fashioned, perhaps there is a neutral word
we can use that is likely to be a part of all these protocols?
"secure::"? "security::"?? I would still go with "ssl" though.

We could use "https::" but the pending BumpSslServerFirst patch already
gives Squid ability to tunnel (but not identify) non-http protocols and
I bet those features will only expand. We might also support secure
communication with non-HTTP servers. So perhaps we should not restrict
this to HTTP.

> Proposed tokens:
>
> %user_cert_subject ==> %tls::{DN}>cert
>
> %user_ca ==> %tls::{DN}>ca

According to some examples in src/cf.data.pre, the parameter goes before
the namespace, right after the % sign! If we are changing this horrible
syntax, perhaps we can fix it so that the parameter follows its option
instead of "it of front in jumping"?

    %ssl::>cert_subject{DN}
    %ssl::>cert_issuer{DN}

And there is some confusion regarding DN. Squid uses "DN" to mean "the
whole name on one line" (see ssl_get_attribute) so if we follow our
convention, the options do not need a DN parameter (at least until other
parameters are supported):

    %ssl::>cert_subject
    %ssl::>cert_issuer

Also, Squid does not log information from the CA certificate in this
context. Both names are extracted from the _user_ certificate, one from
the subject field and the other one from the issuer field. If we are
renaming, it is probably better to emphasize that as shown in the above
example rather than mislead the admin that they can log something from
the CA certificate.

Here is a certificate example with issuer and subject DNs:

> Certificate:
> Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
> OU=Certification Services Division,
> CN=Thawte Server CA/emailAddress=server-certs_at_thawte.com
> Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
> OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala_at_freesoft.org
...

> * since we have no need to limit the attributes pulled from the
> certificate or CA I've used the same syntax as HTTP headers to access
> particular named field-values.

Yes, this is a good approach, although it will require more work to
support parameters. We do not need that for now, I guess.

> * Is there a long name we can use instead of "DN" ?

We could spell it out as "DistinguishedName" but I do not think we
should because "DN" is how that info is presented to the user by all
certificate viewing programs I have seen so far. And we do not really
need "DN" as discussed above.

> Attached is a quick experimental patch to add these tokens to libformat.
> Its got a few bugs I can see already, but you get the idea?
>
> (snipping the rest of this since we get WAY off topic of the patch. You
> seem to understand what the problems well enough. )

Thank you,

Alex.
Received on Sun Jul 01 2012 - 19:05:42 MDT