BREACH

lore

cryptographysecurity

A 2013 variant of CRIME that targets HTTP response compression instead of TLS.

Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext works even without TLS compression by attacking gzip at the HTTP layer, inferring secrets reflected in compressed responses. Mitigations include masking tokens and disabling reflection of user input.

BREACH is CRIME's successor and applies the same compression side channel to HTTP response bodies rather than to TLS itself. Because HTTP compression is used essentially everywhere and disabling it costs real bandwidth and performance, the easy remedy that closed CRIME was unavailable.

The conditions are specific and common: the response must be compressed, must reflect some attacker-supplied input, and must contain a secret such as an anti-forgery token in the same body. Given those, an attacker measures response sizes across many crafted requests and extracts the secret character by character.

The defences are all uncomfortable trade-offs, which is why it is still a live consideration. Masking tokens with a per-request random value works and requires application changes. Adding random padding to responses raises the cost of the attack without eliminating it and wastes bandwidth. Separating secrets from reflected content is correct and requires knowing where all your secrets appear. BREACH is a good illustration that some vulnerabilities cannot be patched, only designed around, and that a genuinely useful feature can be the thing that makes an attack possible.

Also known as: BREACH, Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext

Sources

  • CVE-2013-3587 (2013)

All glossary entries