- From: Peter Lepeska <bizzbyster@gmail.com>
- Date: Wed, 27 Nov 2013 08:48:50 -0500
- To: Adrien de Croy <adrien@qbik.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CANmPAYGfY21zxNhVHPTEMmu5SapsAFqp9kz8pR5L0r6xhUgvow@mail.gmail.com>
"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. "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. 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<http://www.ietf.org/internet-drafts/draft-snell-httpbis-keynego-01.txt> 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 13:49:18 UTC