Key Takeaways

  • Classical computer science curricula taught engineers to compress data before encrypting it because encryption randomizes data and destroys compression efficiency.
  • Encryption hides the content of a payload, but it does not hide the length of the transmitted ciphertext.
  • Compression algorithms eliminate redundancy by replacing repeated byte strings with shorter pointers, meaning a smaller ciphertext directly reveals data repetition.
  • An attacker who controls part of a request can guess characters one by one, watching for packet size drops to extract credentials.
  • Thai Duong formalized this dynamic in Thai Duong's Compression Side-Channel Secret Recovery Method, forcing internet standards to abandon TLS-level compression.

The Thai Duong's Compression Side-Channel Secret Recovery Method

Step 1: Inject Chosen Plaintext alongside the Target Secret

Take a chosen plaintext payload and cause the target system to concatenate that message directly alongside the secret target data, such as a session cookie or password.

Step 2: Compress and Encrypt the Combined Stream

Allow the system to compress the combined plaintext and encrypt the resulting payload using an unknown encryption key, producing a ciphertext transmitted across the wire.

Step 3: Measure Ciphertext Length for Redundancy

Observe the exact byte length of the ciphertext. Because encryption does not hide message length, a shorter ciphertext indicates that the injected payload shares redundant character sequences with the secret.

Step 4: Iteratively Guess Characters to Reconstruct the Secret

Vary the injected characters systematically. By detecting which character permutations result in maximal compression, recover the secret string character by character without ever obtaining the cryptographic key.

When This Works (and When It Doesn't)

This method applies whenever an encrypted channel compresses sensitive static data alongside attacker-controlled input before transmission, leaking the secret through ciphertext length variations.

It works reliably against protocols that bundle authentication cookies, session headers, and reflection parameters into a single compression context, which is why attacks like CRIME broke HTTPS implementations across browsers. The vulnerability relies on deterministic compression engines like DEFLATE that search for repeated byte patterns. If an attacker can force a client to issue hundreds of requests containing guessed strings, the cipher itself offers zero defense.

It breaks down when system operators disable compression at the protocol transport layer, or when compression occurs strictly across isolated, non-mixed data boundaries. If the secret data lives in an isolated buffer that never shares a dictionary or sliding window with user-controlled input, redundancy matching fails. Similarly, adding random noise or variable padding can obscure size differences, though padding schemes often prove brittle against statistical averaging over large request volumes.

What to Do With This

If your web application handles sensitive user sessions, audit your HTTP compression settings across your reverse proxies and API gateways before Friday. Many teams enable Gzip or Brotli indiscriminately across all outbound responses to shave latency numbers on internal dashboards.

Run an audit across your Nginx, Cloudflare, or AWS CloudFront configuration files. Look for configurations where dynamic responses reflect user query parameters while simultaneously outputting session tokens, CSRF tokens, or secret API credentials. Disable HTTP compression globally on any response endpoint that outputs authentication tokens alongside reflected user input. If you need compression for static assets, isolate those endpoints to dedicated subdomains where authentication headers are never passed.