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

On 07/01/2012 06:18 PM, Amos Jeffries wrote:

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

It logs '-', 'none', 'server-first', or 'client-first'. Quite useful
when you do not always bump or have complex sequences like
authentication of CONNECT followed by appropriate bumping depending on
the authentication result. Here are the docs:

> ssl::bump_mode SslBump decision for the transaction:
>
> For CONNECT requests that initiated bumping of
> a connection and for any request received on
> an already bumped connection, Squid logs the
> corresponding SslBump mode ("server-first" or
> "client-first"). See the ssl_bump option for
> more information about these modes.
>
> A "none" token is logged for requests that
> triggered "ssl_bump" ACL evaluation matching
> either a "none" rule or no rules at all.
>
> In all other cases, a single dash ("-") is
> logged.

but we are digressing again :-).

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

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

I do not recall any question or conversation that starts with something
like "Can we do foobar with TLS transactions?" when the topic is not
specific to TLS. Folks use SSL or HTTPS as a "secure connection"
moniker. This is just my limited experience, of course.

>>> 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"?

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

Thank you.

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

IIRC, there are about ten standard certificate properties but only a
handful of commonly used ones. I do not think we should parameterize
first-level fields, especially because this will force us to use two
levels of parameters in some cases.

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

Well, even if we use parameters, we still have to register and should
document them.

> On the side:
> With BumpServerFirst they will be able to eventually log details from
> the server certificate though too right?

Sure. That is possible even with the current bump-client-first. Nobody
wanted to log server certificate details badly enough, I guess.

> And do we have the CA certificate available anywhere handy to provide
> logging for that as well?

Kind of. OpenSSL should have access to that because it needs to validate
the chain from the user or server certificate to the Root CA. Squid can
extract that from OpenSSL state (we do that in the validation callback
already when validation fails). There could be many CAs in that chain
though so logging anything other than the Root CA would be tricky.

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

Not sure we should spend time on that, especially as a part of a header
mangling project :-). It should be OK to add new fields/parameters as
needed, no? In general, I would just go by the names browsers and
OpenSSL uses to display certificate fields.

Cheers,

Alex.
Received on Mon Jul 02 2012 - 01:05:49 MDT