Hacker News Reader

Comment by gaunab | Hacker News Reader

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

View on HN

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

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.

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.

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.

> 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

Reply on news.ycombinator.com