BREACH Mitigation

[d-z-m]

Hello! Wanted to open this issue to gauge the project's willingness to accept a PR to mitigate against a compression based attack on HTTP known as BREACH.

BREACH is an attack that turns the compression ratio of a HTML Response Body into an oracle for revealing secret data.

In the mitigations section, they propose a technique called "Heal the BREACH" or HTB as a way of making the attack impractical. Basically, it would involve setting the gzip.Writer's Header.Name value to be a string of random length(modulo some upper bound, say 10 bytes). A demo implementation exists here.

[klauspost]

Sure. I presume you mean adding it to gzhttp.

We can add a RandomJitter(n int) option that will add 0 to n characters.

[klauspost]

BTW, The demo implementation has a bug that allows getting the response in less tries than the paper indicated.

Strings are 0 terminated, so it always adds a byte of overhead when set.

This means that the sizes will be:

(compressed-size) + 0 (0 padding)
(compressed-size) + 2 (1 padding)
(compressed-size) + 3
....
(compressed-size) + (n+1) (n padding)

Since there will never be an output of (compressed-size) + 1 it doesn't take "500 times more packages" to deduce (compressed-size).

In fact, just observing packages it would take only about n*2 to deduce the minimum and maximum values, so I am not sure how they get to the "500 times" number.

I have added it "as proposed", but I would much rather make it deterministic based on content - even that is much trickier.

[klauspost]

See #762 - which has content aware padding, which I believe to be better than the proposed.

You can however still use the HTB mitigation, just set the buffer size to a negative value.

Oh yeah, and added it as "Comment" instead of "Name".

[d-z-m]

BTW, The demo implementation has a bug that allows getting the response in less tries than the paper indicated.

Strings are 0 terminated, so it always adds a byte of overhead when set.

Ah, well spotted. Even though Go strings aren't null terminated, RFC 1952 specifies strings that are null terminated. The implementation in encoding/gzip is here.

just observing packages it would take only about n*2 to deduce the minimum and maximum values, so I am not sure how they get to the "500 times" number.

I believe this is just a consequence of the way they're modelling the problem. Because the oracle isn't perfect, they have a series of techniques to build confidence in the validity of the character under test. These include padding the test character various ways to try to filter out noise introduced by other HTML elements that may be getting compressed as well. Huffman coding also apparently introduces a fair amount of complexity into the attack that makes the pure n*2 number infeasible.

I have added it "as proposed", but I would much rather make it deterministic based on content - even that is much trickier.

Interesting idea. On first glance this certainly does seem to make the attack much more difficult. However, I have a bit of an issue with calling the crc32 output "random"(or even psuedorandom). It does not meet the definition. Would you be opposed to amending the description to describe the padding added in the "content-aware" mode to be "of variable length, based on the crc32 checksum of the content" or similar?

[d-z-m]

Thinking about this a little more...The content-aware version makes me a little squeamish, as it exposes the modular reduction of the crc32 checksum of the page to an attacker who is aware of what the unpadded length should be. But this is probably ok, because there are ~100m candidates for the crc32 mod 32. One thing to keep in mind is possible bias in crc32 which could prune the search space for an attacker, but probably not by an appreciable amount.

If an attacker knows the crc32 then they can try plugging in secret values offline (provided they're not too high entropy), and try and recreate the crc32, although given how prone crc32 is to collisions, it may not be useful.

For my part, I'd probably use the HTB version of your implementation, as I don't want to think too hard about mitigating this, and it closes the door to offline attacks. If BREACH attacks are obvious to an Intrusion Detection System/WAF then they're easily blockable, and that's good enough for me.

[klauspost]

Thinking about this a little more...The content-aware version makes me a little squeamish, as it exposes the modular reduction of the crc32 checksum of the page to an attacker who is aware of what the unpadded length should be. But this is probably ok, because there are ~100m candidates for the crc32 mod 32. One thing to keep in mind is possible bias in crc32 which could prune the search space for an attacker, but probably not by an appreciable amount.

Only CRC32 MOD n is used. So if n is 32, it has 31 outcomes. Also, remember the actual response is opaque to the attacker. They can inject a value, but by the nature of the attack they do not know the complete actual response.

But to eliminate that suspicion, I can use SHA256 instead. It will be a bit slower, but is commonly regarded cryptographically secure.

[d-z-m]

Only CRC32 MOD n is used. So if n is 32, it has 31 outcomes.

Sorry, my wording above was confusing. I only meant that there are ~100 M possible inputs that yield the same crc32 mod n output.

But to eliminate that suspicion, I can use SHA256 instead. It will be a bit slower, but is commonly regarded cryptographically secure.

How about BLAKE2? It is faster than SHA2, and posited to be random oracle indifferentiable.

[klauspost]

I don't want to add a dependency just for that. I would have used it otherwise.

The difference isn't that crazy:

pkg: crypto/sha256
cpu: AMD Ryzen 9 3950X 16-Core Processor
BenchmarkHash1K/New-32            538423              2185 ns/op         468.60 MB/s           0 B/op          0 allocs/op
BenchmarkHash1K/Sum224-32         564984              2173 ns/op         471.33 MB/s           0 B/op          0 allocs/op
BenchmarkHash1K/Sum256-32         567684              2166 ns/op         472.84 MB/s           0 B/op          0 allocs/op

pkg: golang.org/x/crypto/blake2b
cpu: AMD Ryzen 9 3950X 16-Core Processor
BenchmarkWrite1K-32      1278195               936.6 ns/op      1093.36 MB/s
BenchmarkSum1K-32        1267620               942.8 ns/op      1086.15 MB/s

[d-z-m]

Seems like a big difference to me XD. But fair enough, I understand not wanting dependencies.

Using the first 4 bytes of the sha256sum seems reasonable.