Re: Proposal: Explicit HTTP2S proxy with any node refusal

On Tue, Nov 26, 2013 at 05:17:08PM -0800, James M Snell wrote:
> Well, a full TLS flow inside the http/2 connection may not be
> necessary, but there would have to be some kind of key agreement to
> base the message integrity on.. so we'd definitely have to eat up a
> round trip or two if we went with this approach... unless the
> agreement was negotiated out-of-band (i.e. derived from the external
> TLS or some prior agreement). That gets a bit messy, however.

Wait a minute guys, currently this works *exactly* the same way because
when you use an explicit proxy and want to connect to an https:// URI,
you send a CONNECT method to the proxy to establish a tnunel to the
origin server then you pass your TLS handshake over there. So there is
no difference.

That's exactly what we discussed more than one year ago, offering multiple
possibilities to the user :
  1) connect securely to the proxy, communicate in clear through it and to
     the origin server ;

  2) connect securely to the proxy, communicate in clear through it and have
     the proxy encrypt to the origin server (aka "GET https://").

  3) connect securely to the proxy, and communicate using a TLS tunnel to the
     origin server (equivalent of CONNECT, but with true confidentiality over
     the wire). This is what is described by Peter here.

Most users will prefer #3, and when proxy refuses #3 for the requested site
or whatever, users should be offered the option to switch back to #2 with the
warning about what this implies "this proxy's admin will see everything
exchanged with the site, do you really want to continue ?".

In #3, concerning the extra roundtrip, that's not exact, it's exactly the
same number of round trips as when doing a direct connection to the origin
server. The connection is first established to the proxy and then multiple
streams may be opened there. We can do that in HTTP/1 for http:// URL since
the proxy knows the message length, but not for https:// because of the
CONNECT method which terminates with the connection close. But in both
cases, you save the DNS round trip.

That why I'd really want to see explicit proxies, it will save some round
trips where it matters, especially in mobile environments. And more
importantly we won't see anymore new connections start fresh with a small
congestion window for each object fetched! *That* is critical for performance.

Willy

Received on Wednesday, 27 November 2013 06:20:50 UTC