Re: filtering HTTPS

On 14.03.2012 15:16, Henrik Nordström wrote:
> ons 2012-03-14 klockan 14:18 +1300 skrev Amos Jeffries:
>
>> huh? it says exactly what protocol the tunnel is intended to contain
>> (switch to).
>
> On GET/OPTIONS yes, but only for the transport, not tunnel.
>
> You can use Upgrade on CONNECT as well if you want. But it's for the
> client<->proxy only and says nothing about the contents of the tunnel
> requested by CONNECT.
>
> CONNECT www.example.com:80 HTTP/1.1
> Upgrade: TLS/1.0
> Connection: Upgrade
>
> instructs the proxy that the client wishes to have the client<->proxy
> connection wrapped in TLS/1.0. If the proxy agrees it sends a
> HTTP/1.1
> 101 Switching Protol response and any further communication from that
> point is wrapped in SSL client<->proxy, without changing the tunnel
> (it
> may still be SSH, IMAP, SMTP or whatever).

Telling us a bump is needed to find out more.

The *inverse* of this is what I'm saying is significant. When TLS is
*not* present its clearly not going to be something we can ssl-bump.
Therefore skip the bumping and don't interfere.

>
>> For a bit of perspective: We could take a GET with Upgrade:, send it
>> unchanged to a peer and treat the resulting TCP connection as an
>> Upgraded tunnel over which native X traffic happens. No different to
>> handling a CONNECT today.
>
> Clients may only send Upgrade together with Connection: Upgrade as
> it's
> a hop-by-hop directive, so any proxying of the directive would
> technically be a protocol violation.

We are asking an HTTP peer to Upgrade its hop. We have not sent
acceptance to the client, and will relay the peers reject/accept. No
violation there. We just loose control of a HTTP connection by trying is
all.

Amos
Received on Wed Mar 14 2012 - 03:13:07 MDT