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

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 ?
  and should we add a config example showing client-first or
server-first as recommended first ssl_bump+access rules?

Amos
Received on Wed Jul 18 2012 - 12:52:43 MDT