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

On 19.07.2012 15:46, Alex Rousskov wrote:
> On 07/18/2012 09:39 PM, Amos Jeffries wrote:
>
>> I'm working out how to implement Upgrade support
>> around what bumping already does.
>
> I do not think the two features are related.
>
>
>> 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.
>
> I do not see how. Any compliant client would expect 101 first.
>
>
>>> 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
>
> Yes.
>
>> and disable the bump from happening?
>
> No. The bumping decision does not depend on whether we upgraded
> communication with the client or not. As far as bumping is concerned,
> the client connection may have been upgraded to some FooBar17
> protocol.
> It would make no difference to what the bumping code has to do.

I'm not talking about Upgrade:FooBar17 here. I'm talking about the
specific case where "Upgrade:TLS/" is sighted.

The other protocols FooBar17 would be handled (or not) and bumping left
to do its whatever.

Amos
Received on Thu Jul 19 2012 - 03:51:44 MDT