BREACH - a new attack against HTTP. What can be done?

Question

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)

Answer 1

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.

Answer 2

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

ADDED
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.

Answer 3

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.

Answer 4

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.