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

On 02.07.2012 07:05, Alex Rousskov wrote:
> 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.

What exactly does that log? a yes/no flag whether bumping happened?

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

Yes I too am against anything specific cross-layer like "https::".

I suggested TLS because SSL is on the way out everywhere except the
OpenSSL library.

No string preferences myself, but leaning towards TLS naming across the
board as the visual marketing representation that we actually are
actively upgrading Squid to the modern network standards. This kind of
falls into the category of whether we continue the "old" SSL trend for
consistency or begin the TLS naming trend now. Given that this is new
code for 3.3 I'm bending towards starting the "TLS" documentation / UI
polish.

>
>> 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}
>

Er, yes. Nasty syntax. Well, I wasn't proposing changing that really,
but good point, we should. Patch to fix that being submitted separately
for audit.

> 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

How many of these are there? i.e. is it appropriate to hard-code them,
or would a parameter and sub-parameter be better?

NP: we do have the whole ssl:: namespace, but it could be a maintenance
hassle to keep registering new tokens and document them.

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

Hmm. Okay. I wasn't able to find any text about it in a quick check
through OpenSSL documentation, so assume it was abbreviation for "Domain
Name", matching the IPs and Domains you are adding in the other fields.

On the side:
   With BumpServerFirst they will be able to eventually log details from
the server certificate though too right?
   And do we have the CA certificate available anywhere handy to provide
logging for that as well?

Now would be a good time to define names for the lot and reserve the
non-implemented ones.

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

Aha. Okay. In that case I think you are right. It should be the default
attribute displayed if no {} parameter is provided in the format.

Thank you
Amos
Received on Mon Jul 02 2012 - 00:18:17 MDT