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

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

You got most of it. I'm working out how to implement Upgrade support
around what bumping already does.

And yes that 101 will need to be implemented before we can claim
full/proper RFC 2817 Upgrade support. I thought we could still support
it in the existing bump fashion without the 101 though.

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

Er. So if I'm getting your point right. When implementing Upgrade:TLS
we should do so before bumping and disable the bump from happening?

>
>> Firstly, I'm asking whether you have any other interpretation of
>> that
>> specific HTTP request case.
>
> I am afraid my interpretation is very different.

Yes.

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

Okay. Will do.

Amos
Received on Thu Jul 19 2012 - 03:39:46 MDT