This weekend, a proposal (not a standard, and not yet even proposed as such by a Working Group) submitted to the IETF called “Explicitly Trusted Proxy in HTTP/2” has generated a huge amount of noise from “privacy activist” Lauren Weinstein as an attempt by carriers to force “officially sanctioned snooping” on us all, and lots of people have jumped on the bandwagon to cry foul and shame, including The Register.
Unfortunately, neither Weinstein nor any of those reposting him seemed to bother to even read and understand the five-paragraph abstract right at the beginning of the draft. And if you read the whole thing, you find something important:
- This draft proposes that any such proxy not interfere with any traffic that is protected by https.
[Edit: People have asked, where does the draft say this? It's right in the Table of Contents. http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01#section-4.3 :
4.3. Secure Forward Proxy and https URIs
The Proxy intercepts the TLS ClientHello analyses the application layer protocol negotiation extension field and if it contains "h2" value it does not do anything and let the TLS handshake continue and the TLS session be established between the User-Agent and the Server (see Figure 8).
So the draft proposes using different ALPN extensions for https ("h2") vs. http ("h2clr") resources and that the proxy would not do anything for https, similar to CONNECT semantics for HTTP/1.1 proxies.]
That is, any traffic with actual “end-to-end” security and privacy, that Weinstein and I both value so much, stuff like email, banking, Facebook, Twitter, etc. is completely unaffected by this proposal.
A little background on HTTP, HTTPS, and HTTP/2 is necessary here to explain further. Traffic on the web can come in two forms today: HTTP and HTTPS. HTTP is plaintext, able to be viewed and modified by anyone along the network paths your traffic traverses. HTTPS communications are protected by TLS and, importantly, authenticated by a digital certificate issued to a web server. This allows your client to know who it is talking to and prevent anyone else on the network from viewing or modifying traffic.
The “Trusted Proxy” proposal is actually about a third mode of operation that has been proposed (again, not standardized) for HTTP/2, called opportunistic encryption. This means that clients and servers could choose to “upgrade” to TLS in the absence of a digital certificate identifying the remote server. Does this provide “end-to-end” security? No. In fact, it works pretty much exactly like the horrible Apple TLS bug that everybody’s been so up-in-arms about. You’ve made up a key with someone, but you don’t know who. Your carrier can still substitute itself in this process to read and modify your traffic, or it can simply disallow the protocol “upgrade” and force you back to plaintext HTTP/1.1. The only thing opportunistic encryption aims to do is make it more expensive for “passive dragnet attackers” (read: the NSA and similar state actors) to analyze captured traffic on a giant scale.
Carriers, for motivations discussed in the draft, see many costs and few benefits to this approach. They’d especially like to be able to provide caching to give faster and more affordable service to people in locations with constrained bandwidth, like in the developing world.
What this proposal says is, for traffic that is already only pretend-secure, let us offer you the option to upgrade to an actually-secure connection to us, your ISP, and we’ll give you better quality of service.
To analyze the security and privacy impact of this, we’ll divide the “cloud” part of network diagrams between you and the server you want to reach into three zones.
- “Front haul” is the stuff between you and your carrier’s network, such as your home router, the wifi hotspot at the coffee shop, etc.
- “Carrier network” is the network equipment managed by your ISP.
- “Back haul” is the stuff between your carrier’s network and the server at the other end.
In the current world, for plaintext HTTP, the bad guys can live in any of the three zones. In the world of the HTTP/2 optimistic encryption proposal, the bad guys can still live in any of the three zones, they just have to actually live there, not just be watching.
The carrier is always in the position of an active attacker, in either world. Optimistic encryption cannot protect you from your ISP.
Now, what about the “Explicit Trusted Proxy” proposal? In this world, the carrier proxy strongly identifies itself to you with a digital certificate, and establishes a secure channel to you across the front haul portion of the network.
An interesting result of this is that bad guys can no longer live in the front haul zone. That’s actually hugely beneficial to users. You’ve reduced the attack surface of your connection by eliminating many of the most hostile parts of the network like easily compromised home routers and wifi hot spots.
In fact, what this proposal looks a lot like is a one-click, in-the-browser VPN solution, for insecure traffic only. It’s the same kind of thing people use today to avoid censorship and unwanted traffic-shaping by tunneling their traffic securely to the back haul zone.
Considering that you have no choice but to trust your carrier anyway for traffic that is insecure or only “optimistically” encrypted, this proposal is a win for security and privacy. If you could initiate this protocol by making an HTTPS connection to an off-path host, and so use the VPN provider of your choice instead of your carrier, it would be an even bigger win.
In summary, before you cry wolf, take a minute to read the draft.
P.S. One thing this whole episode has finally convinced me of is that “opportunistic encryption” is a bad idea. I was always dubious that “increasing the cost” of dragnet surveillance was a meaningful goal (those adversaries have plenty of money and other means) and now I’m convinced that trying to do so will do more harm than good. I watched way too many extremely educated and sophisticated engineers and tech press get up-in-arms about this proxy proposal, as if the “encryption” it threatened provided any real value at all. “Opportunistic encryption” means well, but it is clearly, if unintentionally, crypto snake-oil, providing a very false sense of security to users, server operators and network engineers. For that reason, I think it should go, to make room for the stuff that actually works.