CRIME (Compression Ratio Info-leak Made Easy)

CRIME was presented in 2012 by Juliano Rizzo and Thai Duong, the researchers behind BEAST. When TLS compresses data before encrypting it (TLS 1.2 and earlier could negotiate DEFLATE compression), the size of each encrypted record depends on how well its content compresses. An attacker who can make the browser send requests containing chosen text next to a secret, such as a cookie in the same headers, and who can observe encrypted lengths, can guess the secret byte by byte: a correct guess repeats existing text and compresses slightly better. SPDY's header compression was vulnerable in the same way.

Why it matters

The response was straightforward: browsers disabled TLS compression, server libraries followed, and TLS 1.3 removed compression altogether. HTTP/2 replaced SPDY's header compression with HPACK, which was designed with this attack in mind. The lasting lesson is that compressing secrets together with attacker-controlled data before encryption leaks information through length. BREACH (2013) applied the same idea to HTTP response compression such as gzip, which TLS settings cannot fix; it needs application-level mitigations, such as masking CSRF tokens per request or not compressing responses that reflect user input alongside secrets.

Example

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -i '^Compression'
# Compression: NONE

Common misconceptions

• Turning off gzip in nginx fixes CRIME. CRIME targets TLS-level compression, which current libraries already disable; gzip is relevant to BREACH, a different attack.
• CRIME is a reason to avoid HTTP/2. HTTP/2's HPACK header compression was designed to resist CRIME-style attacks.
• Encryption hides the size of the data. TLS hides content, not length; that gap is exactly what CRIME and BREACH exploit.