Crack in Internet's foundation of trust allows HTTPS session hijacking (opens in new tab)

So for this to work, an attacker needs to be a Man In The Middle, and get the attacked client to execute some malicious Javascript, which in turn crafts requests to a target site which uses TLS and SPDY. The MITM intercepts and compares the encrypted and compressed payload for recurring patterns that result when using DEFLATE. By playing with the crafted requests, he can e.g. guess cookie values that were added by the browser to the request (as many XSS attacks work) by comparing the lengths of the encrypted payloads.

See http://security.blogoverflow.com/2012/09/how-can-you-protect... for technical details.

This seems to be a very basic attack, wondering why this attack vector wasn't publicly known much earlier...

Could this be worked around with some added random-length non-redundant data so that the 3rd party can draw no conclusions from the varying responses?

Of course this works as long as the additional deceit doesn't defeat the advantages of compression and even then it still feels like security through obscurity.

I never liked SPDY to begin with. It always seemed to be gratuitously promoting a "new" protocol when many of the speed gains can be had from simply paying better attention to existing protocols, e.g. using pipelining for multiple resources from the same domain. A lot of the "slowness" of the web comes from ignorance and laziness, not lack of capable protocols. It was disturbing how much mindshare SPDY seemed to be getting just based on hype.

And TLS always seemed like a replacement for SSL, when what's really needed are _alternatives_ to the SSL model, not a GNU clone that proclaims it can do the same or better.

This is just my opinion. I apologise if it offends anyone.

Fortunately there are alternatives. You just have to look beyond the hype.

I don't see how this attack would work on SPDY, unless you could add arbitrary headers to the request. CRIME works because the entire request is compressed together, whereas in SPDY the header block is compressed separately.

Ah, so that's why Google removed TLS compression with Chrome as discussed here: http://news.ycombinator.com/item?id=4510829

1. User disables Javascript

2. User's browser cannot automatically request resources (e.g. via img src tag). Either user prefers to download images manually (e.g. as text-based browser allow) or because he has fine-grained control over his name lookups (e.g. a managed HOSTS file or authoritative nameserver on localhost). User request the resources he wants specifically (how many would deliberately choose to download an ad?). He does not leave download choices to browser authors and web developers.

3. User's browser does not advertise compression support. User does not allow web pages to issue HTTP requests e.g. via Javacript. User downloads JSON directly and parses it to obtain the desired resource URL's.

4. User has no desire to compress HTTP headers. User is not interested in SPDY.

What if someone has automated this sort of common sense approach so that it's so simple your grandmother would find it easy to use?

Would this make security consultants, browser authors and web developers upset?

What I hate about this vuln is there's no practical fix for many web servers because there was never an option to disable the TLS compression. They're rushing to backport those options now. The good thing is it seems the top three browsers don't even use TLS compression [anymore].