With the advent of CRIME, BEAST's successor, what possible protection is available for an individual and/or system owner in order to protect themselves and their users against this new attack on TLS?
-
2As long as they don't publish anything concrete, there isn't much we can say about that. – CodesInChaos Sep 08 '12 at 19:42
-
11@CodesInChaos That was my thought until Big Bear weighed in with an answer. +1 to the question... because there is an answer and most of us just didn't know enough to say it. – Jeff Ferland Sep 09 '12 at 03:29
-
@JeffFerland, Why is Thomas called Big Bear? – Pacerier Jan 11 '16 at 14:32
-
2@Pacerier: his avatar photo is a bear, and he has several times the reputation of the nearest user making him Big Bear. – Jeff Ferland Jan 11 '16 at 16:18
3 Answers
This attack is supposed to be presented 10 days from now, but my guess is that they use compression.
SSL/TLS optionally supports data compression. In the ClientHello
message, the client states the list of compression algorithms that it knows of, and the server responds, in the ServerHello
, with the compression algorithm that will be used. Compression algorithms are specified by one-byte identifiers, and TLS 1.2 (RFC 5246) defines only the null
compression method (i.e. no compression at all). Other documents specify compression methods, in particular RFC 3749 which defines compression method 1, based on DEFLATE, the LZ77-derivative which is at the core of the GZip format and also modern Zip archives. When compression is used, it is applied on all the transferred data, as a long stream. In particular, when used with HTTPS, compression is applied on all the successive HTTP requests in the stream, header included. DEFLATE works by locating repeated subsequences of bytes.
Suppose that the attacker uses some JavaScript code which can send arbitrary requests to a target site (e.g. a bank) and runs on the attacked machine; the browser will send these requests with the user's cookie for that bank -- the cookie value that the attacker is after. Also, let's suppose that the attacker can observe the traffic between the user's machine and the bank (plausibly, the attacker has access to the same LAN of Wi-Fi hotspot than the victim; or he has hijacked a router somewhere on the path, possibly close to the bank server).
For this example, we suppose that the cookie in each HTTP request looks like this:
Cookie: secret=7xc89f+94/wa
The attacker knows the Cookie: secret=
part and wishes to obtain the secret value. So he instructs his JavaScript code to issue a request containing in the body the sequence Cookie: secret=0
. The HTTP request will look like this:
POST / HTTP/1.1
Host: thebankserver.com
(...)
Cookie: secret=7xc89f+94/wa
(...)
Cookie: secret=0
When DEFLATE sees that, it will recognize the repeated Cookie: secret=
sequence and represent the second instance with a very short token (one which states "previous sequence has length 15 and was located n bytes in the past); DEFLATE will have to emit an extra token for the '0'.
The request goes to the server. From the outside, the eavesdropping part of the attacker sees an opaque blob (SSL encrypts the data) but he can see the blob length (with byte granularity when the connection uses RC4; with block ciphers there is a bit of padding, but the attacker can adjust the contents of his requests so that he may phase with block boundaries, so, in practice, the attacker can know the length of the compressed request).
Now, the attacker tries again, with Cookie: secret=1
in the request body. Then, Cookie: secret=2
, and so on. All these requests will compress to the same size (almost -- there are subtleties with Huffman codes as used in DEFLATE), except the one which contains Cookie: secret=7
, which compresses better (16 bytes of repeated subsequence instead of 15), and thus will be shorter. The attacker sees that. Therefore, in a few dozen requests, the attacker has guessed the first byte of the secret value.
He then just has to repeat the process (Cookie: secret=70
, Cookie: secret=71
, and so on) and obtain, byte by byte, the complete secret.
What I describe above is what I thought of when I read the article, which talks about "information leak" from an "optional feature". I cannot know for sure that what will be published as the CRIME attack is really based upon compression. However, I do not see how the attack on compression cannot work. Therefore, regardless of whether CRIME turns out to abuse compression or be something completely different, you should turn off compression support from your client (or your server).
Note that I am talking about compression at the SSL level. HTTP also includes optional compression, but this one applies only to the body of the requests and responses, not the header, and thus does not cover the Cookie:
header line. HTTP-level compression is fine.
(It is a shame to have to remove SSL compression, because it is very useful to lower bandwidth requirements, especially when a site contains many small pictures or is Ajax-heavy with many small requests, all beginning with extremely similar versions of a mammoth HTTP header. It would be better if the security model of JavaScript was fixed to prevent malicious code from sending arbitrary requests to a bank server; I am not sure it is easy, though.)
Edit 2012/09/12: The attack above can be optimized a bit by doing a dichotomy. Imagine that the secret value is in Base64, i.e. there are 64 possible values for each unknown character. The attacker can make a request containing 32 copies of Cookie: secret=X
(for 32 variants of the X
character). If one of them matches the actual cookie, the total compressed length with be shorter than otherwise. Once the attacker knows which half of his alphabet the unknown byte is part of, he can try again with a 16/16 split, and so on. In 6 requests, this homes in the unknown byte value (because 26 = 64). If the secret value is in hexadecimal, the 6 requests become 4 requests (24 = 16). Dichotomy explains this recent twit of Juliano Rizzo.
Edit 2012/09/13: IT IS CONFIRMED. The CRIME attack abuses compression, in a way similar to what is explained above. The actual "body" in which the attacker inserts presumed copies of the cookie can actually be the path in a simple request which can be triggered by a most basic <img>
tag; no need for fancy exploits of the same-origin-policy.
![](../../users/profiles/655.webp)
- 320,799
- 57
- 780
- 949
-
85Wow. A fantastically impressive answer! P.S. Maybe me need to have more folks claiming they can break widespread cryptosystems, without saying how, if that inspires folks like ThomasPornin to come up with creative attacks like this! – D.W. Sep 09 '12 at 02:18
-
77
-
22Good analysis; I hope CRIME *is* this and we don't have two vulns of this size in play! However, I wouldn't say that being limited to entity bodies makes HTTP-level compression safe in general... whilst a cookie header is an obvious first choice of attack, there is potentially sensitive material in the body too. eg Imagine sniffing an anti-XSRF token from response body by causing the browser to send fields that get reflected in that response. – bobince Sep 09 '12 at 22:19
-
1Hmm I tried this idea, but it didn’t work very well. Some code for those who want to play: http://pastebin.com/qZdNYgfr Still a nice idea, though! – Sep 11 '12 at 06:38
-
21It looks like this one is correct - Chromium disabled TLS compression on August 3rd: https://chromiumcodereview.appspot.com/10825183 – Rory Alsop Sep 11 '12 at 07:14
-
7... and the Chromium commit is linked to a bug that is not public (it gets a 403 error, as opposed to a 404 for non-existent bug numbers). So probably a security bug. – Daira Hopwood Sep 12 '12 at 02:30
-
4
-
1
-
3@DanielSerodio: disabling SSL-level compression on the server seems safer. This can be done with Apache (mod_ssl) since version 2.4.3 (which was released last month). I don't think IIS ever supported SSL-level compression, so nothing to do if your Web server is IIS. – Thomas Pornin Sep 13 '12 at 14:04
-
@ThomasPornin It's worth pointing out that there doesn't seem to be away to explicitly control SSL-level compression on Apache 2.2 (at least as of 2.2.23 from today, unless I'm missing something or they didn't update docs yet). – voretaq7 Sep 13 '12 at 17:04
-
@voretaq7: no indeed. The ability to disable TLS compression has been added to Apache development head last month, and backported to the 2.4 line, but not the 2.2 (the motivation for disabling compression at TLS level appears to be CPU cost, unrelated to the CRIME attack, btw). – Thomas Pornin Sep 13 '12 at 17:11
-
2Wow, very insightful suggestion Thomas, it seems so obvious once you explained your idea! You should be credited for having found and explained the vulnerability first! BTW I'm not surprized by this attack, I used the same method to detect what language a word belongs to : mix the word into some text from various languages, the one resulting in the smallest inflate is quite often in the same language as the word. – Willy Tarreau Sep 13 '12 at 22:20
-
1@DanielSerodio You should ask your question in the comment as it's own question on our site. Click on the [Ask Question](http://security.stackexchange.com/questions/ask) link at the top of the page. – Jeff Ferland Sep 14 '12 at 19:47
-
perhaps this would start discussions of cryptographically secure compression algorithm. – Lie Ryan Sep 26 '12 at 11:28
-
1Is there a similar **Awesome** answer/explantion for the BEAST? I've looked everywhere – sudhacker Sep 27 '12 at 13:39
-
@ThomasPornin What if after compression a small but random number of random dummy bytes were inserted? That should make way more attempts necessary on the side of the attacker. I have no idea how large the max number of random bytes appended would have to be to make attacks unfeasible... It seems though that having up to say 50 extra bytes would take a long time to figure out what the length of the unpadded bytes would be. – Evgeniy Berezovsky Oct 10 '12 at 05:59
-
@FlorianMargaine In case you didn't know, ThomasPornin is a paid bait ;) - a tasty one, admittedly. – Evgeniy Berezovsky Oct 10 '12 at 06:05
-
@EugeneBeresovksy: adding extra bytes is supported by SSL/TLS when using a CBC block cipher (padding adds 1 to 255 bytes, but must be multiple of the block length -- only TLS 1.0+ supports this; with SSL 3.0 the padding must have the minimum possible length). By adding _n_ bytes, you multiply the attacker's effort by a factor _n^2_ or so; since the attacker can often afford _patience_, I would prefer _n = 1000_, which is beyond the supported range. – Thomas Pornin Oct 10 '12 at 09:00
-
Suppose my website has two HTTPS URLs: `secure.company.com` and `cdn.differentTLD.net` (so no auth cookies will be sent). Assume that the CDN holds images and no authentication will be done. Is it safe to enable TLS Compression only for the CDN? I understand that @D.W. and @PulpSpy can infer which file is being downloaded based on their post below. That being said, can a lower-level TLS "secret" be exposed outside of the data that is in the HTTP protocol? (here, we seem to only talk about getting the cookie in the header) Can info gained from the CDN be used against the other domain? – makerofthings7 Dec 03 '12 at 06:47
-
@makerofthings7, you really should post questions like that as a separate question, not add to the comment thread here. That said: if there are no secrets on the CDN site, it is probably safe to turn on TLS Compression on the CDN site -- but probably useless as well, as recent browsers no longer support TLS Compression (specifically to stop the CRIME attack). – D.W. Dec 03 '12 at 06:53
-
@D.W. You're right. I created the question so others can benefit from this: http://security.stackexchange.com/q/24891/396 – makerofthings7 Dec 03 '12 at 13:26
-
@ThomasPornin i am not able to see your profile as your name contain Pornin. and sonicwall is blocking it. – smali Aug 13 '14 at 04:41
-
@ThomasPornin, Even scrolling your answers requires effort, I admire the effort you are putting into this site. Hats Off!!!. I am serious, if not done already, you are much eligible to write some books about security. – Sundararaj Govindasamy Aug 26 '19 at 18:43
To add to Thomas Pornin's outstanding answer, I wanted to point out some prior work on the subject of compression and cryptography. Take a look at the following research paper:
- John Kelsey. Compression and Information Leakage of Plaintext. FSE 2002.
That paper describes chosen-plaintext attacks against systems that (a) compress data before encrypting it, and (b) where an eavesdrop can observe the length of the resulting ciphertexts.
The attacks that are conceptually vaguely similar to what Thomas Pornin describes. The paper even mentions that TLS uses optional compression before encryption. However, at the time I don't think anyone realized that this enables an attack on HTTP over TLS, or that an attacker could learn the value of secret cookies sent over a TLS-encrypted connection. The paper looks at attacks on compression mainly in the abstract, rather than in the specific context of the web, and is pretty theoretical. So, CRIME (or Thomas Pornin's attack) is still a significant novel extension of these ideas.
Nonetheless, this is an interesting paper that anticipates the general sort of attack at issue here, even if it did not realize the consequences for web security. It is interesting that the general sort of issue was first described in the research literature 10 years ago, yet it took that long for the security community to fully appreciate the practical consequences of this work. Crypto sure ain't easy, is it?
![](../../users/profiles/971.webp)
- 98,420
- 30
- 267
- 572
-
4This publication may also be relevant: "TLS Compression Fingerprinting and a Privacy-aware API for TLS." It is possible the browsers disabled compression because of this result. https://www.cosic.esat.kuleuven.be/ecrypt/provpriv2012/abstracts/barghavan.pdf – PulpSpy Sep 11 '12 at 16:17
Just to add to great Thomas answer, it seems that to successfully leak the cookie value the actual POST body sent should not only be the:
Cookie: secret=....
but should contain much more text from the POST header, like so:
POST / HTTP/1.1
Host: thebankserver.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/22.0.1207.1 Safari/537.1
Accept: */*
Referer: https://thebankserver.com/
Cookie: secret=...
This POST contents can be easily constructed with Javascript (e.g. he will retrieve user agent via navigator
object), so that is not a problem in the attack scenario.
In practice, attacker can mutate the body even more, e.g. by putting the cookie value multiple times, putting multiple Cookie headers, using only parts of the POST headers in the body etc.
Based on @xorninja code I've constructed the adaptive algorithm that duplicates the whole request header in the body, and tries to shorten it iteratively if the results for the next cookie character are unclear. Results are promising, at least 8 characters are detected now.. When no character can be detected this way, the request body is shortened by removing one header and the process continues. It can successfully leak arbitrary cookie values. Feel free to improve.
![](../../users/profiles/1918.webp)
- 4,068
- 20
- 30
-
The described attack and published PoC doesn't match this claim: https://twitter.com/julianor/status/245943430570704896 4 requests!? – Sep 12 '12 at 18:03
-
1@nicowass I guess it's possible to use different amounts of repeats of the guessed cookie value to validate multiple candidates at once. I think the CRIME authors simply spend some more time fine-tuning their algorithm. – CodesInChaos Sep 12 '12 at 19:20
-
1@CodesInChaos that's my guess too. The PoC was created in a few hours, just to check if the idea is sound. – Krzysztof Kotowicz Sep 12 '12 at 21:11
-
1Could we protect the cookie value by adding a random length random stream of characters to it? – Aran Mulholland Aug 09 '17 at 20:37
-
@AranMulholland Such session tokens are already a random stream of characters in the first place, under a proper system. If you propose appending a unique random string to _each_ request's auth cookie, there are easy workarounds for the attacker (such doing each trial several times to average out the effects of the random string on compression). You'll only increase their effort by a small factor. – JamesTheAwesomeDude May 30 '22 at 01:14