W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Proposal: Explicit HTTP2S proxy with any node refusal

From: James M Snell <jasnell@gmail.com>
Date: Wed, 27 Nov 2013 08:34:48 -0800
Message-ID: <CABP7RbeytAS_uCycV+D-pF5DjsNswwkvKKtwXOg1WgA_AepDAg@mail.gmail.com>
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: Adrien de Croy <adrien@qbik.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Wed, Nov 27, 2013 at 5:48 AM, Peter Lepeska <bizzbyster@gmail.com> wrote:
> "Maybe there's another way to get message integrity without incurring
> another TLS 3 way."
>
> I don't know of one but I could imagine optimizations that might reduce the
> round trips at the expense of keeping TLS and HTTP2 layers separate. I think
> it's important to realize Willy's point that this is no different from the
> tunnelled TLS that CONNECT enables today. And in fact building this as an
> extension of CONNECT might make more sense than using new HTTP2 semantics to
> achieve pretty much the same thing.
>

Indeed. The idea behind the NEGOTIATE mechanism I describe in my draft
is intended to provide for some additional possibilities, but it's not
anywhere near clear yet whether those possibilities are (a)
interesting, (b) practical or (c) realistically feasible. There's
still a ton of work to be done on it.

Today, it ought to be possible to use CONNECT only to enable the most
basic (and likely currently most common) case... however doing so
means performing a complete TLS handshake over a stream. NEGOTIATE
intent at this point is to give us a means of experimenting with
alternatives so that maybe (hopefully) we could come up with a more
efficient approach. Whether or not we'll find it, I'm not yet sure.

> "I agree the justification for doing this would be greatly reduced compared
> to the current justification for MITM."
>
> That's the really big point, I think. By reducing the proxy's power to just
> what it needs to get its job done, we have a proposal that might be
> acceptable to those who currently see the existing "trusted proxy" proposals
> as merely standards-based MITM.
>

Exactly. The Intra-Connection approach ought to provide us a way of
bringing trusted intermediaries into the flow legitimately, without
standardizing an attack on TLS. Will there still be NSA's out there?
Sure, absolutely. Can we be sure that we can trust all intermediaries
that use the Intra-Connection approach? Of course not.

- James

> Peter
>
>
> On Tue, Nov 26, 2013 at 6: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 16:35:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC