Following on from CRIME, now we have BREACH to be presented at Black Hat in Las Vegas Thursday (today). From the linked article, it suggests that this attack against compression will not be as simple to turn off as was done to deter CRIME. What can be done to mitigate this latest assault against HTTP?

EDIT: The presenters of BREACH have put up a website with further details. The listed mitigations are:

  • Disabling HTTP compression
  • Separating secrets from user input
  • Randomizing secrets per request
  • Masking secrets
  • Protecting vulnerable pages with CSRF
  • Length hiding
  • Rate-limiting requests

(note - also edited title and original question to clarify this attack is against HTTP which may be encrypted, not HTTPS specifically)

  • 14
    See also Is HTTP compression safe? which has some analysis of this kind of attack. Security.SE got there first - 11 months before Black Hat. Go, team us!
    – D.W.
    Commented Aug 2, 2013 at 18:42

4 Answers 4


Though the article is not full of details, we can infer a few things:

  • Attack uses compression with the same general principle as CRIME: the attacker can make a target system compress a sequence of characters which includes both a secret value (that the attacker tries to guess) and some characters that the attacker can choose. That's a chosen plaintext attack. The compressed length will depend on whether the attacker's string "looks like" the secret or not. The compressed length leaks through SSL encryption, because encryption hides contents, not length.

  • The article specifically speaks of "any secret that's [...] located in the body". So we are talking about HTTP-level compression, not SSL-level compression. HTTP compression applies on the request body only, not the header. So secrets in the header, in particular cookie values, are safe from that one.

  • Since there are "probe requests", then the attack requires some malicious code in the client browser; the attacker must also observe the encrypted bytes on the network, and coordinate both elements. This is the same setup as for CRIME and BEAST.

  • It is unclear (from the article alone, which is all I have right now to discuss on) whether the compressed body is one from the client or from the server. "Probe request" are certainly sent by the client (on behalf of the attacker) but responses from the server may include part of that which is sent in the request, so the "chosen plaintext attack" can work both ways.

In any case, "BREACH" looks like an attack methodology which needs to be adapted to the specific case of a target site. In that sense, it is not new at all; it was already "well-known" that compression leaks information and there was no reason to believe that HTTP-level compression was magically immune. Heck, it was discussed right here last year. It is a good thing, however, that some people go the extra mile to show working demonstrations because otherwise flaws would never be fixed. For instance, padding oracle attacks against CBC had been described and even prototyped in 2002, but it took an actual demo against ASP in 2010 to convince Microsoft that the danger was real. Similarly for BEAST in 2011 (the need for unpredictable IV for CBC mode was known since 2002 as well) and CRIME in 2012; BREACH is more "CRIME II": one more layer of pedagogy to strike down the unbelievers.

Unfortunately, a lot of people will get it wrong and believe it to be an attack against SSL, which it is not. It has nothing to do with SSL, really. It is an attack which forces an information leak through a low-bandwidth data channel, the data length, that SSL has never covered, and never claimed to cover.

The one-line executive summary is that thou shalt not compress.

  • 5
    thou shalt not compress secrets. Modern javascript frameworks like angularjs can beautifully work around this issue by separating presentation and data. Compress the presentation, not the (sensitive) data.
    – user239558
    Commented Aug 2, 2013 at 19:31
  • Is it me or does the attack seem stupid? If the attacker can inject code into your browser using a https page wouldn't this attack be the least of your worries?
    – user5575
    Commented Aug 6, 2013 at 17:38
  • 2
    The idea is that the attacker can inject his Javascript in a HTTP page from another site, and the Javascript then proceeds to make your browser send requests to the target HTTPS server. Because of the Same Origin Policy, the Javascript cannot send arbitrary requests to the target HTTPS site (in particular no POST), but it can send basic GET requests by manipulating the DOM and adding some <img> tags. Commented Aug 6, 2013 at 17:44
  • 1
    Several corrections: the breachattack.com site has the paper. The paper has full details. The attack works on and compressed, encrypted data, not just http or http compression, so long as the secret is consistent and the attacker gets multiple tests. Systems other than browsers are vulnerable. Breach targets the server's response, where crime/beast targeted the client request. They're the same attack, otherwise. Breach can attack header secrets if tls compression is enabled.
    – atk
    Commented Aug 22, 2013 at 2:23
  • "... then proceeds to make your browser send requests to the target HTTPS server" - And now we have POODLE... Yet another CSRF that the browser cannot seem to contain even though CSRF is in its anecdotal security model. The W3C should just move CSRF out of its security model because it does such a poor job of defending against it (that seems to be standard fair: if it can't be addressed (like Protected Storage for WebCrypto), just drop it from the model).
    – user29925
    Commented Dec 8, 2014 at 6:32

BREACH, like CRIME, is a compression-related attack. Turning off compression makes the attack impossible.

Note that in this case it appears that you turn off a different compression configuration; whereas CRIME exploits TLS-layer compression, BREACH exploits HTTP-layer compression.

  • 2
    I'm having a hard time digging through the ranting and hyperbole, but it seems BREACH relies on HTTP compression rather than TLS compression, so it's different. Commented Aug 1, 2013 at 23:19
  • @mr.spuratic So the compression is done in Apache rather than... Apache. Yeah, it's different, but not so different that it can't be dealt with.
    – tylerl
    Commented Aug 1, 2013 at 23:43

I just thought of a way to add "Randomizing secrets per request", "Length hiding", and "Rate-limiting requests" to a CSRF mitigation measure.

  1. Consider which forms you wouldn't want an attacker to POST on the user's behalf. These are the forms you'd protect from CSRF.
  2. For each page view, generate a random salt of random length. Send this salt as a hidden input. The random length should help add noise to lengths, even if your front-end load balancer strips comments or otherwise minifies your HTML.
  3. Compute a hash of the salt, the session ID, and a server-side secret, and send this CSRF key as another hidden input.
  4. Optionally log the salt or CSRF key to a table. This allows for rate limiting a particular user account or IP address to a number of hashes per hour and for limiting replays of a particular salt.
  5. When you process the form, compute the hash in the same way as the previous steps, using the salt in the form, and make sure it matches the CSRF key.

The attack works by inferring info from the payload size. Artificially padding served HTTPS pages (e.g. a randomly sized comment string) could mitigate its effectiveness.

  • 5
    This isn't actually that much of a mitigation; you can simply collect more packets and the variation(s) will become statistically significant. Obviously, this can be an impediment and slow down an attacker, but it doesn't stop the attack. The proper fix is to close the side-channel (stop compression). Commented Aug 2, 2013 at 10:15
  • That's a good point. While it'd certainly make it harder, it'd still be an issue.
    – Max David
    Commented Aug 5, 2013 at 18:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .