6 ms·
Crack in Internet's foundation of trust allows HTTPS session hijacking
- hendrik-xdest 14y agoAh, so that's why Google removed TLS compression with Chrome as discussed here: http://news.ycombinator.com/item?id=4510829 http://news.ycombinator.com/item?id=4510829
- deleted 14y ago[deleted]
- pestaa 14y agoCould 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.
- CJefferson 14y agoThis 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.
- tlrobinson 14y agoYou 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.
- nhaehnle 14y agoThis 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.
- StavrosK 14y agoHow about padding to a multiple of X bytes?
- warp 14y agothen 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.
- yk 14y agoThe 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.
- smoyer 14y agoBut adding a random length, random comment within the body of your HTML might eliminate the correlation between a correct key character and compressed length.
- alanh 14y ago
- gaunab 14y agoSo 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-yourself-from-crime-beasts-successor/ 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...
- runn1ng 14y agowell, 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.
- quonn 14y agoYes, 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?
- stygianguest 14y agoBecause 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.
- tptacek 14y agoThere 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.
- 14y ago
- deleted 14y ago[deleted]
- protobluffers 14y agoI 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.
- thurn 14y agoI'm not sure what motivates this comment... the issue at hand is certainly not a vulnerability in the SPDY protocol.
- protobluffers 14y ago"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.
- peterwwillis 14y agoWhat 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].
- colinmarc 14y agoI 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.
- yuliyp 14y agoThe URL can be attacker-controlled
- dumbdumbdumb 14y ago1. 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?