Hacker News Reader

Comment by mschuster91 | Hacker News Reader

Actually a binary format (designed to be machine-friendly) is better for MITM injections as it's easier to parse and manipulate... the only benefit of HTTP2/SPDY is that iirc it requires TLS.

I'm waiting for the first carrier to perform SSL MITM.

View on HN

They're already planning it: "Involve the user: Obtain user consent to trust service provider to decrypt select HTTPS"

Quote from someone working for a satellite internet provider for airlines.

Source: http://www.atis.org/openweballiance/docs/OWAKickoffSlides051... page 27

As bad as it is, at the least it should be easy to opt-out of that (unless they do something ridiculous like charge you extra if you refuse to opt-in). Just remove the certificate your ISP gives you.

> I'm waiting for the first carrier to perform SSL MITM.

Nokia, funnily enough, did this on certain dumbphone models. Not a carrier, I know, but still interesting.

http://gaurangkp.wordpress.com/2013/01/09/nokia-https-mitm/

> the only benefit of HTTP2/SPDY is that iirc it requires TLS.

Yeah...except the NSA-agent-hiring IETF [1] gave up on that at the last minute.

http://arstechnica.com/security/2014/01/nsa-employee-will-co...

HTTP2 doesn't require encryption but it does compress the headers. I'm guessing compression makes it too CPU-intensive for telecoms to manipulate the headers on the fly.

I wish they'd require encryption. Perhaps make http:// be TLS but without certificate verification.

Then the telecoms would MITM it anyways.

Certificate pinning and web-of-trust verification would make that difficult to maintain for long.

It's unlikely they'll ever get mass usage because both are uncomfortable to work with.

If a certificate is compromised, changing it means all pinned clients will get a huge warning. Either the user ignores the warning (in which case pinning is useless) or he doesn't and the site is harmed. Keeping a compromised certificate is even worse.

For WoT you first need a web of trusted individuals.

Unfortunately key distribution over insecure channels is still an unsolved problem.

This is in progress. HTTP 2.0 does exactly what you specify. The tcpinc working group at the IETF is also looking at adding this at a lower level for all TCP connections.

Uh, they removed the TLS requirement.

Reply on news.ycombinator.com