Wasn't this already discussed on Hacker News, in quite some detail, yesterday? And wasn't the big revelation that this only applied to traffic that was not CA verified and thereby was inherently man-in-the-middle-attackable <i>anyway</i> (as the actually-secure https connections are marked in a way where this feature does not apply), making this a misunderstanding?
As discussed yesterday, this is <i>not</i> a new MITM vulnerability. To make this work you need to establish a TLS connection to the proxy which is verified in the usual certificate authority way. Note that the standard says that user agents that discover they're talking to a trusted proxy should obtain user consent to talk to that proxy.<p>Any situation in which someone can force your machine to trust one of these proxies is a situation when they had administrator access to your machine <i>anyway</i>, and in that situation you're already screwed.<p>Would it kill HN to actually read one of these specs instead of just whining about it?
Before people start associating this with actual HTTP/2.0, it is worth emphasizing that this is a separate document. None of this "trusted proxy" MITM nonsense is in the HTTP/2.0 draft: <a href="http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/?include_text=1" rel="nofollow">http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/?in...</a><p>Thankfully, it seems fairly unlikely that the trusted proxy thing is going to get anywhere: It serves the interests of Ericsson and AT&T, but <i>not</i> those of the HTTP/2.0 spec authors (who are from Google and Mozilla) or server and browser vendors that will have to implement HTTP/2.0.
Some context: <a href="http://lauren.vortex.com/archive/001076.html" rel="nofollow">http://lauren.vortex.com/archive/001076.html</a><p>"What they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping."
In some third-world countries you cannot get a telecom licence unless you "implement" this, or your license could be easily revoked or canceled.<p>In Russia, for example, there are explicit regulations which says that no telecom company can operate unless it provides "monitoring and law-enforcement facilities".<p>My guess is that <i>each</i> country nowadays has regulations of this sort, so telecom equipment manufactures are forced to "add required functionality". Of course, US has such "secret" regulations.)<p>So, it is much better to face the reality and to standardize this shit to reduce the pain of telecom "workers".)
It is an improvement compared to HTTP/1.1, in that it allows for opportunistic encryption, and it is those connections that can be cached (or if you so prefer, snooped). This will still make it harder for NSA and similar agencies to do mass surveillance without traces. They would either have to insert their own certificate, or get the private key from the ISP. That is far more difficult to do in a covert manner. This alone makes HTTP/2.0 an improvement.
I understand that HTTP/2.0 needs to address both scalability and security, but the proposed "trusted" proxies smells really bad.
Knowing what we know today, in that the current level of security offered by HTTP/1.1 is barely adequate to protect web citizens from real and present threats, shouldn't we be radically rethinking HTTP security.