Re: filtering HTTPS

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Wed, 14 Mar 2012 03:16:26 +0100

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

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

Yes, and any other form of nesting. As I said CONNECT do not say
anything about the encapsulated protocol. It's just a request for a
bidirectional tunnel to the requested endpoint.

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

Upgrade is defined in HTTP/1.1.

The TLS/1.0 upgrade token is defined in the now deprecated rfc2817.

neither uses Upgrade in combination with CONNECT.

rfc2817 defines CONNECT as a method to forward Upgrade over proxies by
encapsulating the Upgrade request within a 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.

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.

Regards
Henrik
Received on Wed Mar 14 2012 - 02:16:35 MDT

This archive was generated by hypermail 2.2.0 : Wed Mar 14 2012 - 12:00:07 MDT