RE: forward HTTPS proxy | Re: The future of forward proxy servers in an http/2 over TLS world

A couple problems with that model.  First, the wholly protocol-based:  A stream is opened by a HEADERS frame; sending an earlier frame on a stream is a breaking protocol change that would require negotiation prior to use.  (Sending the frame between HEADERS and DATA, and requiring a zero-length DATA frame to close the stream might be a reasonable workaround to this.)



More fundamentally broken is that you have to believe the proxy when it claims the server certificate to be something.  The server doesn't have access to the certificate, and so can't sign any nonce the client might request.  It might be an acceptable fallback, but the ideal is to have full authentication of all parties and integrity along the path.



Previous proposals have involved a TLS-in-TLS proposal, where you would have:

Client <= Auth + Encryption + Integrity => Proxy <= Auth + Encryption + Integrity => Server

Client <============================ Auth + Integrity =============================> Server



This has some properties which are desirable - notably the ability to authenticate the intermediary, still authenticate the end-server, and have an integrity-protected exchange with the end-server.  The intermediary can kill the connection if it sees something it doesn't like, but can't actually modify anything if it allows the connection to continue.



However, this also has some strongly negative properties.  As a technical matter, it requires a change not only on the proxy, but on *every* end server on the planet to accept a TLS-in-TLS connection.  There are ways around that; for example, having the proxy's TLS connection to the server offer an ALPN token for inspected TLS being the next layer.  If the server doesn't support it, it doesn't pick that token, and the proxy and client each have to decide what to do next.  As a political matter, though, it standardizes a method for intermediary inspection.  The IETF has historically been opposed to this unilaterally; see RFC 2804.



I'm personally less opposed when the inspector has control of the client's configuration, which is the scenario you seem most concerned about.  Also, note that defining how an explicitly-configured proxy might handle a requirement to inspect traffic actually doesn't constitute wiretapping in the definition given by that RFC - in particular, the definition says that neither the sender nor any receivers know about the third party.  A system in which the sender must know about the third party (proxy) and the receiver has the opportunity to know might have a chance.  (A snowball's chance, as the saying goes, but a chance nonetheless.)



-----Original Message-----
From: hurtta@hurtta09lk.keh.iki.fi [mailto:hurtta@hurtta09lk.keh.iki.fi] On Behalf Of Kari Hurtta
Sent: Wednesday, March 1, 2017 11:27 AM
To: Alex Rousskov <rousskov@measurement-factory.com>; Willy Tarreau <w@1wt.eu>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>; HTTP working group mailing list <ietf-http-wg@w3.org>
Subject: forward HTTPS proxy | Re: The future of forward proxy servers in an http/2 over TLS world



( Kari Hurtta <hurtta-ietf@elmme-mailer.org<mailto:hurtta-ietf@elmme-mailer.org>> was bouncing after MX change.

  I reverted that change. )



Alex Rousskov <rousskov@measurement-factory.com<mailto:rousskov@measurement-factory.com>>

https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0377.html



> To be more precise, the _browser_ needs that, but, yes, this is

> probably required, and that is exactly why I mentioned secure response

> signing (or something like that) as a prerequisite. The proxy would

> need to somehow forward origin's response signature or public

> certificate (at least). This is where an HTTP extension is required.

> Everything else is already supported (at the protocol level) AFAICT.



If HTTP/2 can be assumed for that https connection from browser to proxy, the that extension can be new HTTP/2 frame. I think that this fits to that place.



Proxy sends that frame to browser before responses HEADERS frame.



This allows browser only show status after the fact. Browser can not examine origin's certificate before it sends to proxy



HEADERS

     + END_STREAM

     + END_HEADERS

       :method = GET

       :scheme = https

       :path = /

       :authority = example.com





Willy Tarreau <w@1wt.eu<mailto:w@1wt.eu>>

https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0375.html



> That's why I think that a technical solution like trusted proxies can

> be good. Let the user know whether he can have a TLS tunnel to the

> origin or has to retry in clear using "GET https://". Let's have the

> same warnings as when I'm asked whether or not I want to share my location with the site.



That can be new HTTP response code for CONNECT.





I think these are new protocol components which are needed on that solution.





/ Kari Hurtta