Re: [PATCH] support Upgrade header in ssl-bump decision.

On 07/18/2012 06:52 AM, Amos Jeffries wrote:
> On 11/07/2012 4:38 p.m., Alex Rousskov wrote:
>> On 07/10/2012 09:25 PM, Amos Jeffries wrote:
>>> When the Upgrade: header is present and indicating some non-HTTPS
>>> protocol there is no reason to ssl-bump. Doing a bump would be
>>> detrimental to the client connection.
>>>
>>> This patch seeks to make bump only happen if:
>>> a) no Upgrade header is present (old-style HTTPS CONNECT)
>>> b) the Upgrade header indicates TLS/ protocol is being wrapped.

>> I like the intent, but this would be an easy way for somebody to prevent
>> Squid from bumping their connection, right? Since SslBump is used where
>> clients are not trusted by default, it feels wrong to give such an easy
>> default escape door, especially since the admin cannot close it.
>>
>> Should we let the admin decide? We already have ACLs that can detect the
>> presence of an Upgrade CONNECT header, compare its value, etc. We can
>> recommend prohibiting bumping for non-TLS Upgrade CONNECTs in ssl_bump
>> documentation.

> Sigh. Okay. Documentation update only then.
>
> Would you agree that client-first bumping is indicated by the presence
> of Upgrade:TLS ?

Do you mean that a to-be-bumped CONNECT request with an Upgrade:TLS
header should use client-first instead of the usually recommended
server-first mode, all other factors being equal? I probably need to
read up on the Upgrade specs, but can you explain why client-first would
be preferred in such a case?

> and should we add a config example showing client-first or
> server-first as recommended first ssl_bump+access rules?

To squid.conf.documented? Or to one of the wiki pages?

Thank you,

Alex.
Received on Wed Jul 18 2012 - 16:45:23 MDT