Re: filtering HTTPS

On 14.03.2012 13:32, Henrik Nordström wrote:
> ons 2012-03-14 klockan 12:33 +1300 skrev Amos Jeffries:
>
>> Another option is to notice any Upgrade: headers in the CONNECT
>> requests. That is a major hint about what the tunnel contains.
>
> What? Upgrade is not related to CONNECT. It says absolutely nothing
> of
> what the tunnel contains.

huh? it says exactly what protocol the tunnel is intended to contain
(switch to). TLS being the major one that *might* be HTTPS, but
definitely needs bumping to find out. For other values it can be used to
eliminate the bumping quickly like the HTTPS cache, or whitelist
suggested already. Perhapse as feeding info for those.

>
> CONNECT is request for a end-to-end tunnel.

Only so far as HTTP hops are concerned. The data inside the tunnel may
well be another CONNECT request opening more hops *after* the end.

>
> Upgrade is request for hop-by-hop protocol upgrade, starting with the
> response to this request if accepted.

My reading of the Upgrade RFC is that when sent on CONNECT is it a
request for the recipient to be the end of the HTTP end-to-end tunnel
part and turn itself into that Upgraded type.

Neither CONNECT nor Upgrade indicate that their end-point is the last
hop for the data inside. Only that the HTTP ends immediately for Upgrade
and at the indicated server for CONNECT.

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.

>
> Have you actually seen Upgrade in combination with CONNECT anywhere?

Only in the Upgrade RFC examples.

Amos
Received on Wed Mar 14 2012 - 01:18:16 MDT