Evil or benign? ‘Trusted proxy’ draft debate rages on
Discussion over the ATT-authored Internet Draft “Explicitly Trusted Proxy in HTTP/2” continues, with commentary unpicking the likely implications of the draft.
One question is whether or not there’s as great a threat to user privacy as was stated by Lauren Weinstein in the blog post discussed in El Reg yesterday. According to Brad Hill, a security technologist and co-chair of the W3C Web Application Security project, the answer is “no”.
Hill takes aim at both Weinstein and your humble correspondent from Vulture South, stating: “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.”*
While The Register couldn’t find this form of words in the Draft, in further discussion with Hill, he told us: “There’s nothing there about MITM in authenticated connections, only in traffic that would otherwise be plaintext or only opportunistically encrypted.”
“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”, Hill contends.
If traffic is flagged as an https: resource, Hill explained, the “Trusted Proxy” draft states it should pass unmolested – only unencrypted traffic would trigger the proxy.
(The post is well worth reading, by the way, for its detailed explanation of the modes of privacy proposed in the HTTP2 standard, the stream of which the Trusted Proxy Draft is part).
While scorning the concerns about the Trusted Proxy Draft Hill also concludes that the whole “opportunistic encryption” stream in HTTP2 is a bad idea.
In response, Weinstein told The Register: “Obviously, ISPs are not in a position to “crack” existing properly implemented SSL streams — even the NSA, GCHQ, Russia, China, et al. agencies are hard pressed to do that without a significant amount of work.
“But what the proposal does push is the concept of a kind of “fake” security that would be to the benefit of ISPs but not to most users — and there’s nothing more dangerous in this context than *thinking* you’re secure when you’re really not.”
“It’s a confusing and confounding concept that would be nothing but trouble,” Weinstein concluded.
SANS Institute handler Russ McRee is less sanguine and quite forthright: he believes what’s proposed in the Draft “buggers the CA concept and browser implementation enough to allow ISP’s to stand up ‘trusted proxies’ to MITM and cache SSL content in the name of ‘increasing performance’.”
Columbia U’s Steven Bellovin believes the draft expresses a desire to deal with encrypted user traffic. In an e-mail to The Register, he wrote: “It wants to stop that to provide several services: ‘to allow caching, to provide anonymity to a User-Agent, or to provide security by using an application-layer firewall to inspect the HTTP traffic’, plus some talk about performance. Figure 2 (from the URL you cite) shows that the outbound traffic may or may not even be TLS-protected.”
Bellovin says “there are some legitimate goals here,” but “I also think that this is the wrong way to do it.” He highlighted the Draft’s proposal that users be asked for a consent, which they may not have the capacity to understand.
It should be noted that as an Internet Draft, this is not a standard. Drafts can be and are frequently abandoned in the face of better ideas, or because (as anyone familiar with the impish IETF sense of humour) they were dated April 1.
This one will have some way to run, we suspect. ®
*Bootnote: Here is the entire abstract of Explicit Trusted Proxy in HTTP/2.0:
The purpose of this Internet Draft is to continue the discussion on explicit and trusted proxy as intermediary of HTTP2 traffic.
The httpbis wg has agreed on the HTTP2 usage with HTTP URIs, with or without TLS, without any constraints from the standard (see: issue 314).
To distinguish between an HTTP2 connection meant to transport “https” URIs resources and an HTTP2 connection meant to transport “http” URIs resource, the draft proposes to register a new value in the Application Layer Protocol negotiation (ALPN) Protocol IDs registry specific to signal the usage of HTTP2 to transport “http” URIs resources: h2clr.
This document describes two alternative methods for an user-agent to automatically discover and for an user to provide consent for a Trusted Proxy to be securely involved when he or she is requesting an HTTP URI resource over HTTP2 with TLS. The consent is supposed to be per network access. The draft also describes the role of the Trusted Proxy in helping the user to fetch HTTP URIs resource when the user has provided consent to the Trusted Proxy to be involved.
We cannot identify the form of words “any such proxy not interfere with any traffic that is protected by https” in either the abstract or the entire Draft. However, we note Hill’s reading of the document’s detail, that encrypted traffic will be left alone. ®