Skip to content

CONCEPT Cited by 1 source

Compression side-channel attack

A compression side-channel attack exploits the fact that the size of a compressed payload depends on the content being compressed — specifically, how much it repeats or matches a known pattern. When an attacker can cause their own content to be compressed alongside a secret (session cookie, CSRF token, auth header, sensitive form field), they can guess the secret one byte at a time by watching the compressed-output size change.

The attack shape

  1. Attacker injects controllable content into a response that also contains the secret (e.g. via a URL parameter that gets echoed in the response body, or a cookie-dependent compressed field).
  2. Attacker tries guess₁ for the secret's next byte; the server compresses the response (which now contains the guess + the secret + attacker-controlled prefix). If the guess matches the secret's next byte, the compressor collapses the guess into a back-reference (smaller output); if it doesn't, no collapse (larger output).
  3. Attacker measures the compressed-response size — directly (length-prefixed encoding), or indirectly (timing, TCP packet count).
  4. Attacker iterates with each candidate byte value, finds the one that produced the shortest output, commits it as the next byte of the secret, and moves on.
  5. Over ~256 guesses per byte × (secret length) bytes, the attacker extracts the whole secret.

Canonical instances

  • CRIME (2012) — attacked TLS compression (Deflate in TLS records) to extract session cookies. Browsers responded by disabling TLS compression entirely.
  • BREACH (2013) — attacked HTTP response-body compression (gzip / Brotli) when the response echoed attacker-controlled query-string content alongside CSRF tokens. Defenses include disabling HTTP compression on sensitive responses, randomising response length, and rate-limiting.
  • SDCH-era attacks — extended the class to shared-dictionary compression: if the dictionary bridges cross-origin responses, the attacker can compress attacker-chosen content against the victim's cached dictionary.

Why SDCH was especially vulnerable

SDCH's cross-origin dictionary model meant a dictionary fetched from origin A could compress responses from origin B. An attacker could craft a malicious dictionary (or influence a shared dictionary) whose content was chosen to produce size-oracle signals on the victim's sensitive responses. SDCH was un-shipped from Chrome in 2017 in part because this attack class couldn't be bounded without abandoning the cross-origin model.

Why RFC 9842 closes most of the SDCH class

RFC 9842 enforces same-origin dictionary scope: a dictionary served by origin A is only usable to compress responses from origin A. Attackers can't stitch a malicious dictionary from a different origin into the victim's sensitive response path.

Residual risk remains: same-origin compression side channels are still possible when an attacker has a vector to inject content into the same origin's sensitive response — the classical BREACH attack. RFC 9842 reduces the surface but doesn't eliminate the class.

Standard defenses

  • Disable compression on responses containing secrets (simplest; highest cost in bandwidth).
  • Randomise response length with padding bytes (breaks the size oracle probabilistically).
  • Separate compression contexts so attacker-controlled input isn't compressed against secrets (requires careful application-layer design).
  • Rate-limit requests per session (increases attack time, doesn't fundamentally prevent).
  • Use constant-time cryptographic comparisons for sensitive fields at generation time (doesn't help with response-content-based oracles).

Seen in

Last updated · 200 distilled / 1,178 read