Crack in Internet's foundation of trust allows HTTPS session hijacking | Hacker News Reader

Crack in Internet's foundation of trust allows HTTPS session hijacking

arstechnica.com

162 pointsaspratley32 comments

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

well, as pointed out in the article, this attack is most likely to be done if you are nation state, so you can see the packets, but the victim is using https so you can't watch it directly.

Yes, but the only point of SSL is to protect against an attacker who can see the packets. If nobody can see the packets, why bother with SSL at all?

Because the attack only works if you can also change the messages that pass by. Passive observation is not enough, that means it won't work if you're just eavesdropping.

There is for the most part no difference between the ability to observe IP traffic in real time and the ability to intercept and modify IP traffic.

You misunderstood the vulnerability here a bit.

It works even when you have "passive observation". All you need is two things 1) to make the victim run your JavaScript, irregardless where you make your victim fetch and run your script. And 2) sniff his packets to see what is going over the wire. You can do both things very easily for example in a caffe on an open WiFi network. Or in a caffe with WPA2 where you and your victim are on the same wifi, using the same password from the caffe. (Arp poisoning your victim...)

Take the "you and victim are at secure wpa2 caffe", the bartender gives both of you the wifi password. You perform an ARP poisoning on your victim, now all his communication goes through your computer, you act as gateway for him. Now you have 2 from above. Then you can for example replace his request for a http://cdn.google.com/jquery.js with your own jquery.js spiced with this new CRIME fancy JavaScrip as well, in which you just create a lot of img elements with src set to say https://facebook.com. And so on as described in CRIME you can reveal the victims session cookie for example.

The tools to perform arp have been around since the stone age, the tools to serve your victim your own .js for some random request of his over http have also been around since the stone age. And now we have crime to reveal parts of the victims supposedly secure communication channel as well.

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

in hindsight everything looks very basic. If this was so simple, why didn't you come up with it?

Maybe "basic" isn't the word I would use, but I thought the same thing. This is one of those vulnerabilities that is completely obvious... in retrospect.

> a target site which uses TLS and SPDY

Note that the article says that the vulnerability applies to TLS /or/ SPDY -- in particular, it sounds like TLS+DEFLATE sessions are vulnerable, even in the absence of SPDY.

It has been known since 2002. https://news.ycombinator.com/item?id=4511242

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?

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.

This would just mean you would have to run a very large number of requests, and take an average of them. That might be trickier, but if you can persuade a page to auto-reload it sounds quite possible.

Another option, a little trickier, is that you could take user-definable values (like cookies) and not compress them. I haven't looked carefully at DEFLATE, but in many other compression systems you can choose to simply not compress a short part of the stream. This could get complicated of course.

You already need to make multiple requests (apparently 6 per byte, using a binary search like algorithm). You can do that in the background of any page using JavaScript.

This is not an effective workaround. Without your suggestion, the length of encrypted packages is f(x), where x is the chosen plaintext, and f(x) happens to be smaller if x correctly guesses one character of the secret.

With your suggestion, the length of encrypted packages is f(x) + E, where E is a random variable (noise) that does not depend on x.

Because of that, an attacker simply has to repeat the attack sufficiently many times to gather statistics on package lengths until there is one value of x for which packages are clearly shorter on average than for the rest. This is very similar to the type of sampling you would do in a timing attack.

So your suggestion does make the attack slightly more complicated, but qualitatively, the system remains broken.

How about padding to a multiple of X bytes?

then an attacker will pad it to be close the threshold of the multiplier. The difference between X multiples and X+1 multiples will still allow the attacker to determine the difference in compression size.

The attacker controls at least part of the body such that he can select the length of the message. If the attacker pads his guess such that the total message length is N X+1, then for a successful guess the message length is NX and for a non successful one (N+1) * X. You would need too give the message a random length independent of the body to make this attack unfeasibly.

But adding a random length, random comment within the body of your HTML might eliminate the correlation between a correct key character and compressed length.

That’s the same thing.

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.

The URL can be attacker-controlled

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'm not sure what motivates this comment... the issue at hand is certainly not a vulnerability in the SPDY protocol.

"CRIME works only when both the browser and server support TLS compression or SPDY"

If it would make more sense, then s/protocol/implementation/g or whatever you need to do to make sense of this.

How ever you choose to frame it, the targets are TLS and SPDY.

Huh? SPDY uses TLS. The target is basically "web browsers".

"web browsers" that support TLS compression or SPDY (which uses TLS compression)

It's quite possible to use a browser that supports neither. Indeed I'm using one right now.

Does the SPDY spec require TLS compression? IIRC, TLS is needed. Hence, SPDY+http compress+no TLS compression is workable, no? It's not ideal but would still work...

You're confusing SSL and TLS with OpenSSL and gnutls. TLS is basically a revised version of SSL developed by the same groups and through the same processes as SSL. The GNU project subsequently created gnutls, which is an implementation of both SSL and TLS just like OpenSSL is - the only reason it's named after TLS and the older libraries are named after SSL is because the older ones predate TLS.

s/clone/revised version/

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

Reply on news.ycombinator.com