Re: Proposal: Explicit HTTP2S proxy with any node refusal

You lost me. I think because you are blending other ideas, which is great
by me but I just want to clarify.

In my proposal, there are three types of messages (requests and responses):
1) End-to-end encrypted that the proxy cannot see
2) End-to-end not encrypted but with message auth and integrety (encrypted
over the air by point-to-point TLS sessions)
3) Messages generated by the proxy that does not contain MACs that the
browser can use if it wishes.

Both #1 and #2 could potentially use the "CONNECT" verb instead of using
Intra-Connection Negotiation as I proposed. For #2, the browser and server
simply negotiate the use of a NULL cipher.

I don't see how your "allow GET over https" fits into this scheme.

Can you explain?

Peter


On Wed, Nov 27, 2013 at 12:07 PM, Willy Tarreau <w@1wt.eu> wrote:

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