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

On 07/18/2012 06:47 PM, Amos Jeffries wrote:
>>> 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.

Hi Amos,

    I just read RFC 2817, and it says that "if the server is prepared to
initiate the TLS handshake, it MUST send the intermediate "101 Switching
Protocol" [message]. Since Squid does not send those control messages, I
do not see how the bumping itself and bumping mode in particular is
relevant. We simply do not support Upgrade! Or did somebody add that code?

Furthermore, even if we support Upgrade, we still need to handle the
original CONNECT request after responding with 101. That handling can be
done using client- or server-first bumping mode or no bumping at all,
depending on Squid configuration. The only effect of Upgrade here would
be that our 200 (Connection Established) response to CONNECT would be
sent over a TLS-encrypted connection.

Am I missing something fundamental here?

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

True.

> In our terminology that is client-first bumping.

No, it is not [bumping]. Responding to a client CONNECT+Upgrade request
starts by sending 101 (Switching) and establishing a TLS connection with
the client. That is not bumping (we are not impersonating the server at
this stage). Bumping, if any, comes later, and does not depend on the
established TLS connection with the client.

If bumping after Upgrade does happen, the client-proxy connection would
have these protocols:

    HTTP over bumped SSL/TLS over upgraded TLS over TCP

while the proxy-server connection would have these:

    HTTP over bumped SSL/TLS over TCP

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

I am afraid my interpretation is very different.

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

If one has to bump, server-first is the best mode in general, but there
are exceptions such as serving internal icons. This might be too complex
to fully explain in squid.conf.documented, but I think it is OK to
recommend server-first to admins who are just starting to play with this
and reading squid.conf.documented. Current documentation already
disparages client-first, but we can push folks towards server-first more.

Cheers,

Alex.

>>> 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 - 03:21:07 MDT