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

On 19.07.2012 04:45, Alex Rousskov wrote:
> 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?

I mean IMO its *implied* by the way the Upgrade specs are written.

The client has explicitly asked for Upgrade to TLS from the particular
endpoint it has connected to (proxy or otherwise). So any proxy which
was implementing the Upgrade header would be expected to respond by
doing its own handshake without consulting the server.
  In our terminology that is client-first bumping.

Firstly, I'm asking whether you have any other interpretation of that
specific HTTP request case.

Then I'm asking if you think its actually a good idea to do/advise it
that way. Or if we should go beyond the letter of the specs and document
bump server-first as the best default option.

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

squid.conf definitely, maybe both.

With some variance as per what we decide above above on client-first vs
server-first default.
This is what I'm thinking about for the config file:

version 1)

DOC_COMMENT
#
# With SSL-bump Squid supports the HTTP/1.1 Upgrade feature to improve
security on the client-to-proxy connection.
# Recommended SSL-bump operations for Upgrade
#
acl UpgradeSSL req_header_regex Upgrade +i ^(TLS|SSL)/
ssl_bump client-first UpgradeSSL
#
# Uncomment these rules to prevent non-SSL/TLS protocol bumping even
being attempted.
# NOTE: this allows clients to avoid bumping by sending garbage in an
Upgrade: header.
# acl Upgrade req_header_regex Upgrade .
# ssl_bump none Upgrade
#
# Your ssl-bump access policies here.
...
DOC_END

version 2)

POSTSCRIPTUM: acl UpgradeSSL req_header_regex Upgrade +i ^(TLS|SSL)/
POSTSCRIPTUM: ssl_bump client-first UpgradeSSL
POSTSCRIPTUM: ssl_bump none all

... making it a default policy, with admin having full override ability
from the actual config file.

Amos
Received on Thu Jul 19 2012 - 00:47:29 MDT