Summarization of CRIME Attack on SSL

October 2, 2012 by Bruce Morton     No Comments

I’ve written a few blogs on CRIME, but now that Juliano Rizzo and Thai Duong have presented CRIME at Ekoparty 2012, I thought a summary is due.

CRIME is short for “Compression Ratio Info-Leak Made Easy.” In their presentation, Rizzo and Duong reminded us that HTTPS provides confidentiality, integrity and authenticity; however, CRIME decrypts portions of an HTTPS message, such as a cookie, which can lead to the victim’s session being hijacked.

As previously stated, the CRIME attack takes advantage of compression. Compression is used at many levels and the speakers discussed TLS compression, SPDY header compression and HTTP response gzip compression.

If we compare plain text, encrypted text and encrypted compressed-text, you might think that we are going from least secure to most secure. But that’s wrong. If an adversary can trick you into compressing and encrypting a message of his choice, you could be revealing sensitive information in another part of the message, such as a cookie header.

For TLS compression or SPDY header compression, you must use DEFLATE. DEFLATE uses LZ77 to scan the input, look for repeated strings and replace them with back-references to the last occurrence. DEFLATE also uses Huffman coding to replace common sequences with shorter codes.

The resulting compression will make the encrypted message shorter. If the attacker can inject known information into the message before compression and encryption, then they can find out if the added information is a match (i.e., the compressed message will be shorter). If the message stays the same length, then they know the added information was not a match and they try again.

Through repeated use, the attacker can eventually match the session cookie. Voila. The session is compromised.

For a better explanation of the SSL compression attack, please take a look at these references:

In order to implement CRIME, the attacker needs two items. First, they need to sniff the victim’s network traffic. This can be done in many ways such as sharing a LAN, he’s hacked a router or he’s a network administrator.

Second, they need to load code into the victim’s browser. This can be done by tricking the victim into visiting a compromised or malicious website or by injecting the code into the victim’s legitimate HTTP traffic.

The good news is the risk of CRIME attacks on SSL has been mitigated. Chrome and Firefox have disabled TLS compression and SDPY header compression. Internet Explorer, Safari and Opera did not support TLS compression or SPDY, so no changes were required.

Regarding SPDY moving forward, the plan is SPDY/4 will not be susceptible to CRIME.

Rizzo and Duong concluded that the problem is not over, however. TLS compression may also be a problem in the future with other non-browser implementations. They also think HTTP gzip may be a bigger problem than either SPDY or TLS compression.

They reminded everyone that compression is everywhere. I assume that means: watch out.


Bruce Morton has worked in the public key infrastructure and digital certificate industry for more than 15 years and has focused on SSL and other publicly trusted certificates since 2005. He has been an active member of the CA/Browser Forum that released guidelines for extended validation (EV) certificates and Baseline Requirements for SSL certificates. Bruce oversees the governance and compliance of Entrust’s publicly trusted PKI.

Add to the Conversation