10 ms·
Google disables compression for OpenSSL in Chrome - SSL exploit coming?
- sanxiyn 14y agoman sshd_config. Compression: Specifies whether compression is allowed, or delayed until the user has authenticated successfully. The argument must be "yes", "delayed", or "no". The default is "delayed". I don't know why they chose "delayed" as default, but this seems to prevent this attack.
- tptacek 14y agoThe SSH protocol is nothing like TLS. The SSH security model is nothing like the TLS security model. Pornin's guess about Thai and Juliano's attack does not break the TLS authentication model; it breaks the confidentiality guarantees TLS makes to the application layer. If you authenticated TLS with certificates the way SSH authenticates with keys, you wouldn't worry about the compression attack. So, not so much.
- jgrahamc 14y agoYes. See: http://security.stackexchange.com/a/19914 http://security.stackexchange.com/a/19914
- tveita 14y agoCompressed Redundancy in Message Exploit?
- Flenser 14y agoCompression Reveals Information Meant (to be) Encrypted?
- EwanToo 14y agoFascinating explanation / prediction, thanks.
- nitrogen 14y agoIs my understanding correct that the attack described there requires all of 1. cookies associated with the target, 2. the ability to monitor the length of requests to the target, and 3. the ability to send requests to the target (e.g. JavaScript injection, malicious website)? I guess this is actually an instance where those Hollywood "guess the password one character at a time" animations would make sense.
- jgrahamc 14y agoYou need three things: 1. To know the format of cookies used for the web site you are targetting. Specifically, whatever cookie contains authentication. 2. The ability to injection a request to the target web server while someone is connected (such as with JavaScript, an XSS, or plug-in). 3. Ability to monitor the SSL connection is it is transported across TCP. Would have been fun if they called this the CPE1704TKS attack instead of CRIME: http://www.youtube.com/watch?v=NHWjlCaIrQo http://www.youtube.com/watch?v=NHWjlCaIrQo
- ivanr 14y agoTo expand on your second point, if you have 3, then in many cases you also have the ability to intercept and modify non-encrypted traffic. Meaning, if the victim is using a secure web site and a non-secure site at the same time, the MITM can infiltrate the non-secure site and use it to generate requests to the secure site.
- xhrpost 14y agoI think you're correct here but how would you manipulate the cookies being sent when sending XSS requests from a different domain?
- cstejerean 14y agoyou don't need to manipulate the cookies being sent, only the body of the message. The browser will send the correct cookie in the header, you control the body, and use the length of the message to determine how close the cookie value in the body is getting to the one in the header.
- ChuckMcM 14y agoVery interesting, using differential analysis on the compression output is pretty clever.
- tptacek 14y agoNote that it is effectively the same attack as ECB byte-by-byte decryption, except using record length instead of repeated blocks as the signal.
- tlrobinson 14y agoHeh, anyone else notice the proposed attack strongly resembles Level 8 in the last Stripe CTF?
- tptacek 14y agoThat Stripe CTF was deceptively excellent. If you (the reader of this comment) got through it and had fun, I promise, we'd be both interested to talk to you and an interesting company for you to talk to. www.matasano.com/careers.
- amalcon 14y agoInteresting. The attacker would also need to push the request size up to the next block boundary, but it should work. At least we can still do compression at the HTTP (or other higher-level protocol) level. That gets us most of the benefit anyway.
- __alexs 14y agoI suspect most TLS libraries will flush the compression buffer after each write call so its highly likely that every request will end on a deflate block boundary already.
- geofft 14y agoStupid question: does TLS's compression use the _same_ compression state for both directions of the connection? That seems hard to me, because they could be sending information in parallel, and there's no provision for syncing streams. So I suspect the attack there cannot work on TLS, and in fact the demo code posted in a comment attacks local zlib, not TLS. I think the actual attack, if it's along these lines, involves getting the server to echo back your guess of the cookie, so that the cookie and your guess are both on the same stream. Perhaps with TRACE?
- tlogan 14y agoThis attack procedure applies only for dictionary based compressions. Correct? What would be the procedure if you use bzip2 (which is based on Burrows-Wheeler transformation) compression?
- bcoates 14y agoIt shouldn't matter so long as redundancy between headers and body result in a smaller cyphertext.
- daeken 14y agoDue to the nature of compression algorithms using BWT, changing a single byte in the uncompressed data might give you +/- 5 bytes difference in the size of the compressed data; that makes pulling off an attack like this much, much, much more difficult. Don't get me wrong, you'll get variance with deflate as well, but it's nowhere near the level of something like bzip2. I do a lot of experimentation with new compression techniques for web demos, and I recently implemented my own compression algo from scratch based around the same building blocks as bzip2. The variance I saw was just staggering; a tiny change in my source material would totally warp the output.
- tlogan 14y agoI would love to see somebody proving or disproving whether BZip2 is susceptible to these type of attacks. My assumption is that small changes in MTF transformation and tweaks in creating encoding table will make it impossible to crack using this method.
- makomk 14y agoUnless I'm missing something, I reckon there's a really obvious improvement on that, but Stack Exchange doesn't let new users leave comments. Think of the old puzzle where you've got 9 bags of gold coins which weight 10 grams each and one bag of shaved coins which weigh only 9 grams each and you need to figure out which bag has the shaved coins in only one weighing. You should be able do the same thing here - add one "Cookie: secret=A", two "Cookie: secret=B" and so on. Because of the limited look-back window in the compressor you'll need to interleave them like ABCD...BCD...CD... but it should give more information. Edit: Wait, I am. That wouldn't work because it'd compress the repeated subsequences. D'oh.
- comex 14y agoYou could still probably get more than a bit per request along those lines with some experimentation.
- makomk 14y agoProbably, yeah. Thinking about it, one obvious approach might be to try and overlap the last step of guessing one byte with the first step of guessing the next byte, for instance.
- tonyb 14y agoDoesn't look like this has anything to do with an exploit. It is because some older web servers who don't support TLS also don't support compression. See:http://code.google.com/p/chromium/issues/detail?id=31628 http://code.google.com/p/chromium/issues/detail?id=31628
- EwanToo 14y agoThat's always possible, but why would the bug report linked from the code change be private then? http://code.google.com/p/chromium/issues/detail?id=139744 http://code.google.com/p/chromium/issues/detail?id=139744
- abadidea 14y agoNo, I doubt that something closed in early 2010 has much to do with a new patch that has a rationale disabled from public viewing which implies it's a security emergency.
- tonyb 14y agoYou are correct, I misread the code commit. The link to the 2010 bug was removed from the code, not added to it.
- tptacek 14y agoI think 'jgrahamc is right.
- tptacek 14y agoYou think you have a handle on how hard it is to get crypto right. Then you get a result like this. As an expert (not me; I'm not smart enough to say this) would put it: "if attacker data is mixed with defender data, none of the branches in the cryptosystem code can depend on the content".
- ZoFreX 14y agoI think crypto is possibly the best example in all of software development and/or computer science of how dangerous "unknown unknowns" are, and how a little knowledge is a dangerous thing (although threads are a serious competitor for the latter trophy). I've studied cryptography theory, and I've implemented various ciphers and attacks, and the more I learn the more certain I become that I would never, ever use any of my own crypto code in production.
- cperciva 14y agoI think it's time for me to write a blog post entitled "on the provable security of spiped". Seriously, we know how to build secure cryptographic protocols. Unfortunately, step #1 is "don't try to be backwards compatible with the horribly broken things people were doing in the 1990s".
- tptacek 14y agoWhat, compressing before encrypting?
- cperciva 14y agoYes. There's absolutely zero excuse for including compression as part of a cryptographic protocol.
- tptacek 14y agoCan you point to an instance where you said anything like that, here or anywhere else, before last week? It's easy for me to believe that you've internalized "minimize data-dependent branches in crypto code" and thus wouldn't have designed a compressed encrypted transport. It is very hard for me to believe that you would have spotted this flaw immediately had anyone pointed out to you that TLS supported compression. There is well-regarded (though not by me) crypto advice recommending that people compress before encrypting, to destroy structure in the plaintext.
- cperciva 14y agoIt is very hard for me to believe that you would have spotted this flaw immediately had anyone pointed out to you that TLS supported compression. I'm not claiming that I'd have noticed this particular attack. I'm saying that having compression in a supposedly secure transport layer was an obviously bad idea even before it was clear how it could be exploited. I don't need to get into a car accident to know that driving at night with my car's headlights turned off is a bad idea. There is well-regarded (though not by me) crypto advice recommending that people compress before encrypting, to destroy structure in the plaintext. There's a huge difference between compressing data and compressing an authentication channel. This is why compression should not be included in the secure channel -- it should be left up to the higher-level code to decide if compression is (a) completely pointless or (b) will leak information dangerously.
- pbiggar 14y agoReading the title, I thought that Chrome was turning of gzip based compression for HTTP bodies when using SSL. According to http://security.stackexchange.com/a/19914 http://security.stackexchange.com/a/19914 (linked above by jgrahamc), it is in fact header compression that is TLS specific. So a giant sigh of relief from me.
- wladimir 14y agoThanks for noting this. I also got this wrong on the first reading. Having to drop gzip compression of the content would be terrible. I fathom that header compression helps if you have many requests (polling etc), but for most websites it is much less influential in bandwidth usage.
- Reflejo 14y agoRelevant: http://www.ekoparty.org/2012/juliano-rizzo.php http://www.ekoparty.org/2012/juliano-rizzo.php
- tlrobinson 14y ago"The good news is we've got working patches for most of the issues. The bad news is some of them might contribute to global warming" Disabling compression could certainly contribute to global warming in a relatively small way...
- cryptbe 14y agoProblem 1 in Stanford's crypto class [1]: Data compression is often used in data storage or transmission. Suppose you want to use data compression in conjunction with encryption. Does it make more sense to A. Compress the data and then encrypt the result, or B. Encrypt the data and then compress the result. Now we know the correct answer is Neither. [1] http://crypto.stanford.edu/~dabo/cs255/hw_and_proj/hw1.pdf http://crypto.stanford.edu/~dabo/cs255/hw_and_proj/hw1.pdf
- tptacek 14y agoIf you're encrypting and storing files, the answer is (A). The question is, in light of this result, frustratingly imprecise.
- geofft 14y agoWell, B makes no sense. A makes sense, but might have leaks, that depending on use case (and in particular, whether the attacker can execute chosen plaintext attacks like in SSL) may or may not weaken the system, but it still makes sense. For a confusing example of a fairly leaky cryptosystem involving compression that works well in practice and has a proof of security that is aware of the leak, see Douceur et al.'s "convergent encryption". http://research.microsoft.com/apps/mobile/publication.aspx?id=69954 http://research.microsoft.com/apps/mobile/publication.aspx?i...
- tonfa 14y agoDoes the attack apply to SPDY as well?
- njs12345 14y agoI think it does, although not precisely as described in the SO post above: in SPDY the request headers are compressed separately before any TLS compression would apply, so the attacker would have to put her guess of the cookie in the request headers or the URL (as the URL is sent as a pseudo-header in SPDY).
- ivanr 14y agoIt would be interesting to know if there were any changes in the SPDY implementation. It too supports compression before encryption and may be affected by the same problem.
- forgotusername 14y agoColour me stupid, but is there something to prevent inserting indeterminate padding while sending headers? e.g. imagine a request like GET / HTTP/1.0 X-Pad: GET / HTTP/aaaaaaa Where X-Pad randomly repeats previous bytes, and perhaps 0..8 bytes of random/repeating variable-length data. By randomizing the effectiveness of the compression, surely this attack can be generally prevented by the browser? You could argue that given enough samples the noise could be filtered and the attack still remains, but the same could be said the same for many successful patches over the years (TCP sequence number randomization, Kaminsky's DNS issue, etc.), and the number of samples required would be pretty infeasible.
- riannucci 14y agoI'm fairly certain this could be defeated with a little differential cryptanalysis. Similar approaches to defeating side-channel attacks on smart card power usage have been tried and defeated :/
- StavrosK 14y agoIf it's random, you can just get enough samples and remove the noise. It'd have to be padding to a given number of bytes, but that probably has a vulnerability too.
- caf 14y agoThere's no point - you're better off just disabling TLS compression and doing whatever compression of the body-only at the HTTP level.
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- cryptlamex 14y agoCRIME researcher says 4 request are enough to decrypt: https://twitter.com/julianor/status/245943430570704896 https://twitter.com/julianor/status/245943430570704896
- Daniel_Newby 14y agoTo decrypt each byte.
- anonymous 14y agoSo, to summarize for the laypeople, if the user has Javascript and/or cookies disabled, this exploit will not work?
- fakjshflaskjhf 14y agoJavascript just makes the attack faster, but it can be accomplished with raw html. Cookies are required though; it's what you are after when using this attack.
- anonymous 14y agoFascinating. And how about if the cookies are marked "secure"? (This can be done manually in some browsers, e.g., elinks).
- Daniel_Newby 14y agoHidden <iframe> elements would probably work just as well. It might even work with JacaScript turned. Have a page with nested iframes. Serve each one from a different IP address and have the server not answer right away. The server answers with the first iframe having a chosen URL while Eve snoops the wire. Eve tells the server which URL to use for the next iframe body that it sends. Repeat until the cookie is deduced. The server can use a nested tree of iframes to avoid having a bazillion iframes in the top level document.
- anonymous 14y agoAdd to the list of all the malicious things that can be done using <iframe>. Why <iframe> elements are even allowed by any purportedly "secure" browser is beyond me. Is their functionality really worth the risk?
- alanh 14y agoIs this a disabling of compression on both ends? No DEFLATE on either requests or responses? Will a site using HTTPS be able to serve compressed assets (like javascript & css)? If not, we’ll urgently need a way for site devs to whitelist precomputed (and thus immune) static assets for compression.
- caf 14y agoIt's a disabling of the optional compression at the TLS layer. HTTP content compression is not affected.
- alanh 14y agoSo what, exactly, is no longer compressed? Merely the headers themselves, and the content is not affected?
- caf 14y agoPretty much, yes. With the proviso that if you didn't have HTTP Content-Type compression for your content before, then it might still have been compressed at the TLS layer, and won't be now.
- shanemhansen 14y agoWhile this is probably security related, disabling compression is actually a good practice for clients which make a large number of SSL requests (like a browser). OpenSSL allocates alot of memory per connection for compression/decompression. See http://journal.paul.querna.org/articles/2011/04/05/openssl-memory-use/ http://journal.paul.querna.org/articles/2011/04/05/openssl-m... for a great discussion of why SSL_OP_NO_COMPRESSION might make sense for you. Even if you don't have direct access to the library code creating SSL objects, there are still some tricks with ctypes, ffi, dlopen that have the same effect.