- From: Adrien de Croy <adrien@qbik.com>
- Date: Tue, 26 Nov 2013 23:40:07 +0000
- To: "Peter Lepeska" <bizzbyster@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-Id: <em6783a080-c205-424d-a128-7c738c782802@bodybag>
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 Tuesday, 26 November 2013 23:40:48 UTC