Er, actually reading the specification, it's about proxying <i>http</i> resources, not <i>https</i> ones. This proposal is strictly better than the transparent proxying that's common on the internet today.<p><pre><code> 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.
</code></pre>
...<p><pre><code> 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).</code></pre>
This article ignores the context behind the proposal. Many companies, schools, and prisons are MITMing all SSL traffic today for a variety of liability reasons. Today those users get no notice that their Web browsing is being observed and censored. Trusted proxies are intended to give those users some notice that they're being MITMed.<p>I agree that MITM proxies shouldn't be used on the public Internet and thus we shouldn't make it easier to do so, but what about the people who are already being MITMed? Is there another way to solve this problem or must we throw corporate Web users under the bus to save the public?
The specification indeed is about proxying http resources, not https ones. So it's not initially as alarming as some other proposals discussing trusting proxies to intercept SSL connections. For more details, you can refer to <a href="https://insouciant.org/tech/http-slash-2-considerations-and-tradeoffs/#Proxies" rel="nofollow">https://insouciant.org/tech/http-slash-2-considerations-and-...</a>.<p>This specific proposal is interesting because it specifically is related to opportunistic encryption proposals, in particular, the one that allows sending <a href="http://" rel="nofollow">http://</a> URIs over an unauthenticated TLS connection: <a href="http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03#section-3.6" rel="nofollow">http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-...</a>. The problem here for proxies is, if you mix http and https (authenticated) traffic on the same TLS connection, the proxy cannot tell if it can safely MITM the connection. The proxy vendor would like to know if it can do so, probably for network management / caching / content modification reasons. Of course, the point of the opportunistic encryption proposal is to increase security (although its actual effective impact is controversial: <a href="https://insouciant.org/tech/http-slash-2-considerations-and-tradeoffs/#OpportunisticEncryption" rel="nofollow">https://insouciant.org/tech/http-slash-2-considerations-and-...</a>). But if you believe in opportunistic encryption's security purposes, then it doesn't seem to really make sense to make the MITM'able traffic identifiable so proxies on the network path can successfully MITM them without detection.
It actually appears that the RFC openly admits the potentials for abuse here:<p>"6. Security Considerations<p>This document addresses proxies that act as intermediary for HTTP2 traffic and therefore the security and privacy implications of having those proxies in the path need to be considered. MITM [4], [I-D.nottingham-http-proxy-problem] and [I-D.vidya-httpbis-explicit-proxy-ps] discuss various security and privacy issues associated with the use of proxies. Users should be made aware that, different than end-to-end HTTPS, the achievable security level is now also dependent on the security features/capabilities of the proxy as to what cipher suites it supports, which root CA certificates it trusts, how it checks certificate revocation status, etc.<p><i>Users should also be made aware that the proxy has visibility to the actual content they exchange with Web servers, including personal and sensitive information.</i>"
I've become increasingly more disgusted with IETF since I found out they have at least a few NSA agents working with them on protocols, and more importantly <i>refusing to kick them out</i> - even after all the Snowden revelations with NSA trying to subvert and undermine encryption protocols:<p><a href="http://mirrors.dotsrc.org/fosdem/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm" rel="nofollow">http://mirrors.dotsrc.org/fosdem/2014/Janson/Sunday/NSA_oper...</a><p>Then I find out that they've been working with Cisco on another similar thing to this one for "legal intercepts", a.k.a "trusted backdoors", like we're seeing above.<p><a href="https://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-wp.pdf" rel="nofollow">https://www.blackhat.com/presentations/bh-dc-10/Cross_Tom/Bl...</a><p>With NIST being already corrupted by the NSA, and now W3C becoming corrupted by MPAA, too, I think we're seeing the decay and fall of the "standard bodies", because I don't believe the Internet will tolerate these moves. The Internet will ignore them, do its own thing, and make it popular. I think future standards will be built from the bottom-up, and if I'm not mistaken most of the Internet so far has been built that way anyway.
The best part: the "Privacy" section of the document is blank.<p><a href="http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01#section-7" rel="nofollow">http://tools.ietf.org/html/draft-loreto-httpbis-trusted-prox...</a>
There are some kinda legitimate uses for this in certain environments -- enterprise DLP, various kinds of filtering, etc. Potentially even caching and stuff on the distant end of really weird network connections (when I go to Mars in ~30y, I'd like to have as much cached as possible, and converted to message-based vs. connection-oriented protocols).<p>We have good enough workarounds for this right now (putting wildcard CA certs on devices and proxying that way), but they're not awesome. So, if there were a way to keep this from being used for evil, it could make some existing non-evil activities easier.<p>But, on balance, the risk of evil might be too high.
There was another article on here a week or two ago effectively blasting the http/2.0 wg for doing stupid things. I think it was the "HTTP 308 incompetence expected" article.<p>Now this. I'm beginning to wonder if I want anything to do with HTTP/2.0.
Ok - here is a suggestion: The Right to root.<p>Just as a citizens letters, papers and home are inviolable, should our new papers our new homes be also inviolable - if I own a device, No-one should legally be allowed control over it?
The amusing thing about this is that MITM can also be used to one's personal benefit -- I run a local filtering proxy that strips off most of the crap on the majority of sites, and I've had to do a bit of hex editing to be able to do that without the browser complaining.<p>Look at it another way: With browsers becoming more and more unconfigurable and nearing the point of being user-hostile, it is any wonder that the content providers would want their content, whether or not the user likes it, to be delivered unchanged and forced upon the user? All the Snowden stuff has made us feel that way, but what I'm saying is that the one who is doing the MITM isn't always malicious.
I'm not an expert in internet security or crypto. Some of the comments below raise some interesting points both defending the intent (and implementation) of it and pointing out the flaws. However, as an unsophisticated person interested in my data security, this sounds absolutely awful. Hopefully more clarity on this emerges.
This proposal is so stupid it's hard to believe someone actually made it. Really beats the purpose: Why use SSL? Who am I protecting my data from if the ISP is snooping??? The kid on the Internet Cafe who just found about SSLSnoop?<p>At this point the right proposal should be to just remove SSL altogether, no need to make circles over it.
Carriers are fighting against being turned into dumb pipes.<p>Google is fighting to turn carriers into dumb pipes.<p>I can't take this Google consultant seriously in that context.