Posted by Robert Vamosi on September 13, 2012
A couple of days ago, information about a new attack (CRIME) against Transport Layer Security (TLS) was released. This attack was developed by the same researchers (Juliano Rizzo and Thai Duong) that developed the BEAST attack against SSL/TLS. Although details of the attack are not officially known yet, there is speculation (How can you protect yourself from CRIME, BEAST’s successor?) that it has something to do with TLS compression as specified in RFC 3749. Some testing reveals that this is likely the case.
RFC 3749 specifies a method for compressing data in TLS connections. When a browser attempts to establish a TLS connection, it specifies a list of compression methods that it supports in the “Client Hello” message as shown below.
The server selects one of the compression methods that it supports, and includes it in the “Server Hello” response as shown below.
If the current speculation is correct, the CRIME attack is possible if the Deflate compression method is chosen for a TLS connection.
The attack setup is the same as BEAST. The attacker and the victim have to be on the same LAN. The attacker has to inject code into a HTTP site open in the victim’s browser and make cross-domain requests to a HTTPS site that supports TLS compression. The attacker needs to be able to sniff the traffic that his/her code is generating.
One of the operations in Deflate compression is duplicate string elimination (http://en.wikipedia.org/wiki/DEFLATE#Duplicate_string_elimination). The idea is that the request to the HTTPS site will already contain the user’s cookie if the user is authenticated to the site. So, the request will look like:
Now, if the POST data (which is controlled by the attacker) contains the string “JSESSIONID=X”, the compressed request will be smaller than if the POST data contains the string “JSESSIONID=Y” (for example). This is because a longer duplicate string will be found in the request in the first case, and so, the request will be compressed more. So, an attacker can iterate through all possible characters for the first byte of the cookie and pick the one that generates the smallest request. Then, the attacker can move on to the second byte, and so on. This will allow the attacker to brute force the user’s cookie one byte at a time.
To test the theory, I used a version of cURL that supported TLS compression to submit requests to a server that also supported it. I set the following cookie value in my requests:
When I submitted a POST request containing TEST=X, I saw that the compressed request size was 250 bytes:
When I submitted a POST request containing TEST=? (where ? is any other character), I saw that the compressed request size was 251 bytes:
I was able to continue to brute force the cookie one byte at a time in this manner.
Note that in this case, the server picked the TLS_RSA_WITH_RC4_128_SHA cipher suite. If it had picked a block cipher in CBC mode instead of a stream cipher, this attack would be slightly more complicated as the attacker would have to deal with block boundaries when guessing characters. However, this is not a significant hurdle.
For this attack to be effective, both the browser and the server have to support TLS compression. As of today, the latest versions of Microsoft Internet Explorer, Google Chrome and Mozilla Firefox on Windows do not support TLS compression. Google Chrome was apparently updated in early August to fix this issue: https://chromiumcodereview.appspot.com/10825183/diff/1/net/socket/ssl_client_socket_openssl.cc. I do not know when other vulnerable browsers might have been updated.
Additionally, I had a hard time finding a server that would allow TLS compression to be used. I visited 20+ HTTPS sites that I commonly visit and all of them selected null compression.
This may have been a significant problem a couple of months ago, but it does not currently seem to be an issue. However, you should make sure that you are running the latest versions of browsers and server software.
There are at least two lessons to be learned here: