Re: Proposal: Explicit HTTP2S proxy with any node refusal

On Wed, Nov 27, 2013 at 08:37:38AM -0500, Peter Lepeska wrote:
> > 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?

Yes that's exactly that. Let's simply imagine what any proxy admin needs to
do :
  - inspect contents exchanged with webmails and social networks
  - offer the guarantee to their users that a few sites are whitelisted
    and will not be deciphered

So the admin will configure the proxy this way :
  - allow CONNECT paypal.com mybank.com yourbank.com theirbank.com
  - reject CONNECT
  - allow GET over https

At the moment with HTTP/1.1 this is not possible so the two policies are
merged into a single choice that depends on the place where the proxy is
deployed :
  - either allow CONNECT for a few sites and reject all other https sites.
  - or decrypt everything even what shouldn't. Anyway the user hardly knows.

Regards,
Willy

Received on Wednesday, 27 November 2013 17:08:01 UTC