Preventing CRIME and BREACH with HTTP Padding

Compression side-channel attacks, notably CRIME and BREACH, exploit the way data compression algorithms reduce the size of redundant information, allowing attackers to deduce secret tokens byte by byte. HTTP padding serves as a crucial defense mechanism by injecting randomized, variable-length data into headers or payloads. This article explains the mechanics of compression-based exploits, how padding disrupts the side-channel leakage, and how secure web development leverages this technique to maintain transport security.

The Mechanics of CRIME and BREACH

Both CRIME (Compression Ratio Info-leak Made Easy) and BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) are side-channel attacks targeting data compression algorithms such as DEFLATE.

  • CRIME focuses on transport-layer compression (such as TLS compression) and early application protocols like SPDY. It targets secrets such as HTTP cookies.
  • BREACH bypasses TLS-level mitigations by attacking HTTP-level response compression (like gzip or Brotli), extracting secrets such as CSRF tokens directly from the response body.

These attacks rely on a chosen-plaintext strategy. An attacker injects controlled input alongside a secret value (like an authentication token) within the same compression context. If the attacker's guess matches a portion of the secret, the compression algorithm replaces the duplicate string with a pointer, resulting in a noticeably smaller payload size. By iteratively measuring ciphertext size differences across multiple requests, the attacker can reconstruct secrets character by character.

How Padding Neutralizes the Attack

Compression exploits require a direct, measurable correlation between plaintext redundancy and the resulting ciphertext size. Padding breaks this deterministic relationship.

When HTTP padding is applied, the server (or client) appends a randomized amount of arbitrary data to the headers or the response body. This alters the payload size in unpredictable increments:

  1. Masking Compression Gains: Under normal circumstances, a correct character guess reduces the compressed output by a measurable fraction. Introducing random padding causes the output length to fluctuate regardless of whether a character matched, creating significant noise.
  2. Disrupting the Length Oracle: Because the attacker cannot distinguish between a size decrease caused by a successful match and a size decrease caused by a shorter padding block, the side-channel "oracle" becomes unreliable.
  3. Increasing Work Factor: While small amounts of padding can theoretically be averaged out over vast numbers of statistical samples, sufficiently randomized padding drastically increases the number of requests required to conduct an attack, rendering practical exploitation unfeasible before sessions expire or rate limits trigger.

Implementation in Modern Web Protocols

Mitigating these attacks through padding is implemented at various levels of the web stack:

  • HTTP/2 and HTTP/3 Protocol Padding: Both HTTP/2 (RFC 7540) and HTTP/3 (RFC 9114) feature native padding support for DATA and HEADERS frames. Developers and web servers can set a 1-byte to 256-byte random padding field on individual frames to disguise the exact payload length without altering application logic.
  • Application-Layer Response Padding: For BREACH mitigation on HTTP/1.1 or legacy architectures, applications can inject randomized, hidden HTML comments, dummy JSON fields, or arbitrary custom HTTP headers of varying lengths.
  • Complementary Defenses: While padding provides defense-in-depth, robust web architectures typically pair padding with secret masking (such as XOR-masking CSRF tokens per request) and the strict disabling of TLS-level compression.