Explicit Trusted Proxy in HTTP/2.0
tools.ietf.org
tools.ietf.org
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".
I for one used to be thinking like that. I had my A4 paper with all my computers fingerprint in my pocket and painstakingly checked it every time I was at a new computer. In my university, studying in the computer security program, I think I was the single person checking fingerprints. Not even the system administrators did it.
I guess in practice, ssh today is nothing more than cosmetic compared to telnet.
I don't understand the comparison you're trying to make between SSH and a proposal to transparently MITM a protocol that is designed to be transparently MITM'd. Unless your gripe is that we shouldn't have protocols like that to begin with, in which case I agree, but you should direct your angst to the people who proposed HTTP/2.0 OE, not this proposal.
In return for using ssh over telnet, I get security against any passive attack and attacks past first login. Thus the functionality is on a technical basis superior to telnet (except if you use IPsec, then telnet is better than SSH).
A personal question: when you install a new personal laptop or server, do you check the fingerprints of every ssh connection? Do you prune the CA list and remove any entry that you personally can't vouch the trustfulness of? This is after all what SSL require of each user, so it would be interesting to know if a founder of an software security company do this to his own personal equipment.
Sadly he now seems to have changed his mind about the validity of this approach, mostly because users and devs alike dislike complexity in their decision process as to what is secure and what is merely obscured.
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?
It's also worth noting that this is a proposal. You didn't actually make this mistake yourself but I do want to highlight it: the HTTP WG is not yet discussing this as anything more than a suggestion (see http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/... ). If you are worried about this sort of proposal becoming a draft, I highly recommend you join the working group and keep an eye on the proxy discussions.
This will easily allow the carriers to perform their duty of Lawful Interception
* get an alert when going to e.g. www.google.com as the carrier tries to hijack the session with a fake certificate.
* the carrier have their own versions of libraries/browsers/etc. installed on the phone that disables certificate checks/alerts that would pop up when they hijack a session.
* the carrier have actually gotten hold of a certificate for www.google.com - which I'm sure is doable, but harder, and is thus able to perform a successful mitm attack.
With this approach, the carrier just needs to generate their own certificate, install it on the phone they sell, and can proxy any service they want without user alerts. A significant lower entry bar.
This is simple on the client and avoids any security warnings. It's supported in quite a few firewalls and even squid, so it would be very easy for a carrier to roll out tomorrow if they needed to.
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.
uers 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. 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.
Now the question is, did you???
I've seen the link[2] you posted and I didn't find ANYWHERE the part where it specifically talks about HTTP and not HTTPS. There's even the above part explaining making things even more complicated...
[1] http://tools.ietf.org/html/draft-loreto-httpbis-trusted-prox...
[2] http://hillbrad.typepad.com/blog/2014/02/trusted-proxies-and...
ps. I really did read them both, I just tend to be a little strong-opinionated.
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.
"What they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping."
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".)
I have no illusion that NSA can be stopped if they target someone, but it should be possible to make it impractical to just tap plaintext from the internet backbone as they do today. If data generally is encrypted _unless_ they do MITM attack it will be too expensive to just collect everything.
This is of cause not enough in itself, but it is certainly a step in the right direction.