Re: Proposal: Explicit HTTP2S proxy with any node refusal

Comments below.


On Wed, Nov 27, 2013 at 1:20 AM, Willy Tarreau <w@1wt.eu> wrote:

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

It is like your #3 except, when no node refuses, the TLS session would use
a NULL cipher. The data in that case is not encrypted but it still contains
a MAC for each message so that browser and web server can authenticate and
check data integrity. You might be right that it's better to build this as
an extension of CONNECT plumbing since that is already the standard
mechanism for establishing an end-to-end TLS session via a proxy. Keep in
mind however that we'd still want to add the proxy messaging to the web
server indicating whether or not it REQUIRED data be sent plaintext TLS,
meaning unencrypted but with auth and data integrity.

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

Can you explain this fall back from #3 to #2 in a little more detail? Why
would the proxy refuse #3? Are you talking about the scenario where the
proxy REQUIRES data be sent in plaintext TLS but the web server refuses?

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