Re: Proposal: Explicit HTTP2S proxy with any node refusal

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.

On Tue, Nov 26, 2013 at 3:40 PM, Adrien de Croy <adrien@qbik.com> wrote:
>
> fundamentally this proposes a compromise between level of trust of the proxy
> vs performance.
>
> Since we don't trust the proxy not to alter content, we have to endure extra
> round trips to set up the second layer of TLS
>
> So the question is, are we trusting the proxy or not?  Sounds like not
> really.
>
> I can see situations where pressure comes to bear on middleware vendors to
> MITM the second layer so that they can alter content.  So I think we need to
> think long and hard before deciding to prohibit that at this stage.
>
> I agree the justification for doing this would be greatly reduced compared
> to the current justification for MITM.
>
> Maybe there's another way to get message integrity without incurring another
> TLS 3 way.
>
> Adrien
>
>
>
> ------ Original Message ------
> From: "Peter Lepeska" <bizzbyster@gmail.com>
> To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Sent: 27/11/2013 11:29:46 a.m.
> Subject: Proposal: Explicit HTTP2S proxy with any node refusal
>
> Problem statement:
>
> As Mark, Roberto, and others have argued in multiple Internet Drafts, an
> explicit, trusted proxy is preferable to a transparent MITM proxy as
> intermediary of HTTP2S traffic (HTTP2 over TLS). One problem in developing a
> standard for an explicit, trusted proxy is the process by which a proxy
> establishes trust. We don't try to tackle that problem here but believe that
> it should be no easier than the current process by which MITM proxies
> establish trust, which is to install a CA certificate into the browser's
> certificate database. So, for instance, one possibility is that the browser
> will have a "trusted proxy partition" in its certificate database and a
> proxy will only be trusted if its certificate is installed there. Again,
> this problem is not solved here.
>
>
>
> The harder problems in designing a standard for explicit trusted proxies are
> 1) the need for message authentication and integrity, meaning the browser
> and server can be confident that the proxy has not tampered with the data
> and 2) any node refusal, by which I mean that all actors (browser, proxy,
> and server) should both express their intentions and be able to refuse
> participation on a per object basis. Three scenarios illustrate the issue of
> any node refusal:
>
> 1)    Web server says no: A cache (or optimizing proxy) improves end user
> response times and network utilization. A user will often elect to trust
> this proxy, allowing it to view HTTP2S traffic in the clear, in order to
> receive the benefit of the optimization. Many content owners will also allow
> this, especially when serving publicly accessible content. However, some
> content owners (financial institutions, for instance) may not ever want to
> allow a proxy to view traffic in the clear, even if the end user allowed it.
>
> 2)    Proxy says no: Enterprise anti-malware middleboxes do not want to
> allow any traffic to pass into or out of the enterprise that cannot be
> examined. In this case, a proxy wants to be able to inform the web server
> that it will not pass traffic on to the end user that it cannot see.
>
> 3)    User/Admin says no: Of course, the obvious scenario is where the user
> says no. In this case, we have no trusted proxy.
>
> In order for #1 to be true, allowing a web server to always say no, the
> proxy must not be able to run in stealth mode. In order for #2 to be true,
> the proxy server must be able to pass an indicator to the web server that it
> requires the ability to see all traffic.
>
>
>
> Solution:
>
> The ideas in James’ Internet Draft Intra-connection Negotiation create an
> opportunity for addressing these two problems. The proposed solution
> consists of a) requiring trusted proxies to have their own point-to-point
> HTTP2S session with the browser when processing traffic from an HTTP2S
> content server and b) establishing an intra-connection, end-to-end, TLS
> session using a NULL cipher (no encrypting but still authenticating and data
> integrity checking) between browser and web server and using it to send
> traffic through a trusted proxy. In this case, the traffic over the air is
> encrypted by the point-to-point TLS sessions, while still being viewable by
> the proxy, and, at the same time, the browser and web server can
> authenticate and validate the integrity of the data and any node can refuse
> participation.
>
>
>
> The following diagram illustrates the idea:
>
>
>
>    Browser                                        Proxy
> Server
>
>       |                                             |
> |
>
>       |                                             |
> |
>
>       | 1)Establish HTTP2S (HTTP2 over TLS) session |
> |
>
>       |<------------------------------------------->|
> |
>
>       |                                             |
> |
>
>       | 2)CLIENT_HELLO over HTTP2S                  |
> |
>
>       |============================================>|
> |
>
>       |                                             |
> |
>
>       |                                             |      3)Establish
> HTTP2S session            |
>
>       |
> |<------------------------------------------>|
>
>       |                                             |
> |
>
>       |                                             |      4)Forward
> CLIENT_HELLO over HTTP2S    |
>
>       |
> |===========================================>|
>
>       |                                             |
> |
>
>       |                                             |      5)SERVER_HELLO
> over HTTP2S            |
>
>       |
> |<===========================================|
>
>       |                                             |
> |
>
>       | 6)Forward SERVER_HELLO over HTTP2S          |
> |
>
>       |<============================================|
> |
>
>       |                                             |
> |
>
>       |                                             |
> |
>
>       | 7)Complete TLS negotiation, specifying a NULL cipher, across two
> HTTP2S sessions         |
>
>
> |<========================================================================================>|
>
>       |                                             |
> |
>
>       |                                             |
> |
>
>       |                                             |
> |
>
>       | 8)Unencrypted HTTP2 traffic includes MACs for auth and integrity
> validation              |
>
>
> |<========================================================================================>|
>
>
>
> Note: the “===” lines indicate a message sent over the Intra-Connection
> HTTPS stream, so these are over HTTP2, over the point-to-point TLS sessions,
> but they travel end-to-end between browser and server.
>
>
>
> Because the browser receives the web browser’s certificate in the
> SERVER_HELLO in step 6, it will be able to authenticate the server the same
> as it would if the trusted proxy were not present. This removes the problem
> of transitive trust caused by MITM proxies. One can imagine the browser
> displaying a double lock to indicate that both the proxy and the content
> server have certificates that have been authenticated – of course the proxy
> needs an additional layer of validation but again we will not go into that
> here. The important point is that the proxy is not able to view the traffic
> unless the browser trusts it and also unless the browser itself has
> authenticated the web server’s cert with its own database of CAs.
>
>
>
> Message integrity and authentication between browser and web server prevent
> the proxy from operating in stealth mode, where its presence is undetectable
> by the web server. The web server can thus refuse to take part in the
> trusted proxy session on a per object basis. For instance, requests for the
> logo of a financial institution might be allowed to be viewed by a proxy,
> but requests for sensitive financial information might be refused. This is
> what really separates the proposal from simply standardizing MITM because it
> means the web server will always be aware of the presence of the proxy and
> because, if it decides to, it can say no. I think this is a powerful feature
> and one that legitimate middleboxes should also be in favor of, as it allows
> them to express their intention in an above board way (I would like to
> optimize this traffic or I must see this traffic in order to scan it for
> malware) and to be distinguished from rogue MITMs.
>
>
>
> Additionally, the browser will always know when an object was manufactured
> by the proxy and it can decide whether or not it wants to use it. For
> instance, a proxy might send the browser a cached copy of an object the
> browser requested. This cached copy will not contain the MAC proving that it
> was generated by the web server so the browser will need to make the
> decision whether or not to use this object. Again, in many cases the browser
> will agree to because it provides a benefit to the end user.
>
>
>
> Lastly, and this is not illustrated in the above drawing, the proxy can flag
> the TLS data frames it uploads to the web server to indicate whether or not
> it will allow encrypted responses. If not, as might be the case for a
> security, malware-detecting appliance, then the web server can decide
> whether or not it wants to send the data in a way that the proxy can see.
> And, if not, then the user can be messaged that the site is not viewable
> with appropriate messaging.

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