12

It appears that Chrome, Firefox, and soon Edge, support the new Brotli compression algorithm over HTTPS only.

I can't find anything on whether this new compression algorithm is susceptible to the BREACH attack. The only relevant thing that I found was at the end of section 12 of RFC 7932:

A possible attack against a system that sends compressed data over an encrypted channel is the following. An attacker who can repeatedly mix arbitrary (attacker-supplied) data with secret data (passwords, cookies) and observe the length of the ciphertext can potentially reconstruct the secret data. To protect against this kind of attack, applications should not mix sensitive data with non-sensitive, potentially attacker-supplied data in the same compressed stream.

From that paragraph it appears that Brotli is still susceptible to BREACH. If my understanding of BREACH (and the related CRIME attack) is correct, compression is unsafe over HTTPS.

In this case is it safe to use Brotli for HTTPS content? If not then why are browser vendors supporting it?

Community
  • 1
rink.attendant.6
  • 2,227
  • 4
  • 22
  • 33

1 Answers1

10

support the new Brotli compression algorithm over HTTPS only.

In theory yes. In practice Chrome will currently accept brotli compressed answers with plain HTTP too, even though it does not announce support for brotli in plain HTTP. Firefox only supports answers in HTTPS.

If my understanding of BREACH (and the related CRIME attack) is correct, compression is unsafe over HTTPS.

This is a wrong generalization. The BREACH attack only affects dynamic content which contains secret information like CSRF tokens which the attacker likes to guess. It works only if the attacker is able to reflect own data into the original content like in case of reflected data from filled in forms. The attacker must also be able to detect changes in the size of the compressed content, i.e. using passive sniffing of the connection (classic BREACH attack) or through timing (HEIST attack). It is still secure to compress content where no reflection is possible and of course content which contains no secrets the attacker likes to guess. This especially means that compressing static content is safe.
As for the CRIME attack it is enough to disable TLS level compression which current browsers have done already. CRIME has nothing to do with content compression in HTTPS.
See also Is gzipping content via TLS allowed.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • I think it is very reasonable to generalize that compression in TLS/HTTPS is unsafe. There was a consensus to remove compression from TLS 1.3 entirely for exactly that reason. https://www.ietf.org/mail-archive/web/tls/current/msg11619.html and https://github.com/tlswg/tls13-spec/pull/29 – JZeolla Feb 05 '17 at 20:21
  • 6
    @JZeolla: you are mixing up TLS level compression which includes HTTP headers and bodies and HTTP content compression which includes only the body and not the headers with the cookie or similar data. Browser already don't use TLS level compression but they still use HTTP level compression. While TLS level compression is removed in TLS 1.3 HTTP level compression is not removed. In contrary: new compression algorithms like brotli get deployed. – Steffen Ullrich Feb 05 '17 at 20:32
  • 1
    Right, definitely agree and thanks for the clarification. It appears I read the above too quickly; I thought the original question was if Brotli could cause issues if used in TLS compression, as I was substituting "HTTPS" with "TLS" in my head, instead of "HTTP over TLS". – JZeolla Feb 05 '17 at 20:45