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?
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
For this example, we suppose that the cookie in each HTTP request looks like this:
The attacker knows the
When DEFLATE sees that, it will recognize the repeated
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
He then just has to repeat the process (
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
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
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
|show 16 more comments|
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:
but should contain much more text from the POST header, like so:
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.
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:
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?
protected by Community♦ Sep 13 '12 at 17:16
This question is protected to prevent "thanks!", "me too!", or spam answers by new users. To answer it, you must have earned at least 10 reputation on this site.