top | item 7296128

Explicit Trusted Proxy in HTTP/2.0

109 points| rdlowrey | 12 years ago |tools.ietf.org | reply

45 comments

order
[+] saurik|12 years ago|reply
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 anyway (as the actually-secure https connections are marked in a way where this feature does not apply), making this a misunderstanding?
[+] higherpurpose|12 years ago|reply
I thought the whole point of HTTP2.0 was to make traffic encrypted by default, and not let bit vulnerability holes in the protocol like this. Saying "it just makes it as before" doesn't make me feel better.

Why are we moving to HTTP2.0 otherwise? For a 5 percent increase in speed? The big selling point of HTTP2.0 from my perspective was the "always-on encryption".

[+] flipgimble|12 years ago|reply
It should be discussed as long as its new or interesting to someone so people can form their own opinion of a potentially important security issue. Your statement is suspiciously close to trying force a consensus opinion that there is nothing to see here. While I give you the benefit of the doubt, this type of steering of online discussion that benefits those that would like to weaken internet security. It might help linking to the previous discussion as well.
[+] nitrogen|12 years ago|reply
A possible objection to the proposal is that those who opt not to use "trusted" proxies will be making themselves more visible, like users of Tor are more visible.
[+] Lukasa|12 years ago|reply
As discussed yesterday, this is not 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.

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 anyway, and in that situation you're already screwed.

Would it kill HN to actually read one of these specs instead of just whining about it?

[+] rdlowrey|12 years ago|reply
I don't really care to argue this point so I'll just explain why I find this extremely problematic. What percentage of browser users have any concept of how TLS works? This an exceedingly low number. You're essentially creating a dragnet to capture and decrypt the contents of transfers for a huge number of people who likely have no idea that they're volunteering their (sensitive) information. Browser users are not TLS experts. They will click right through warnings without a second thought. No, this standard doesn't harm the very small minority of people capable of protecting themselves. It only takes advantage of everyone else. This is why, to me, dismissing this off-hand as no big deal is seriously negligent. Yes, I've read the draft. Yes I have the technical experience and qualifications to understand fully what it proposes. And yes, I believe this is an egregious thing to propose.
[+] noselasd|12 years ago|reply
This simply means that phone/tablet manufacturers together with carriers will pre-install and trust the proxy certificates of the carrier, without any end user consent.

This will easily allow the carriers to perform their duty of Lawful Interception

[+] atmosx|12 years ago|reply
The problem is that this feature can (and will be) used as a legal backdoor for ISPs to snoop traffic, simple as that.

Even they don't want to, they will probably have to after a subpoena. While if you don't implement this and other backdoors to the protocol, you won't be able to do it. At least not transparently.

[+] joliss|12 years ago|reply
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: http://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/?in...

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 not 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.

[+] barrkel|12 years ago|reply
I particularly like how the Privacy section is completely blank.
[+] rdlowrey|12 years ago|reply
Section 6 (Security Considerations) is truly shocking. And Section 7 (Privacy Considerations)? Whaddya know? It's empty!
[+] dschiptsov|12 years ago|reply
In some third-world countries you cannot get a telecom licence unless you "implement" this, or your license could be easily revoked or canceled.

In Russia, for example, there are explicit regulations which says that no telecom company can operate unless it provides "monitoring and law-enforcement facilities".

My guess is that each country nowadays has regulations of this sort, so telecom equipment manufactures are forced to "add required functionality". Of course, US has such "secret" regulations.)

So, it is much better to face the reality and to standardize this shit to reduce the pain of telecom "workers".)

[+] alephnil|12 years ago|reply
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.
[+] lallysingh|12 years ago|reply
NSA will have the ISP keys, that's a given.
[+] crbaker|12 years ago|reply
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.
[+] yeukhon|12 years ago|reply
This would be an awesome term project for students studying computer security to find problems in the draft, if there is any.