I've recently learned about these issues, too.For those who aren't aware of it, the issue is called BREACH and was discovered several years ago. The problem is that encrypting makes content unreadable, but keeps the content length unchanged. That means the information of content length itself is not "encrypted". Compressing changes the content length depending on repetitions. With HTTP you always compress-then-encrypt. (Encrypted data would likely be uncompressible.) So if there's a secret in the plaintext content, like a CSRF token that's repeated in every page response, an attacker might try to have the website echo arbitrary input in the response together with that secret. If the arbitrary input happens to share a few characters with the secret, compression kicks in and the content length is reduced. You probably need a prefix or fixed pattern around the secret to find a start. Trying to find repetitions starting with only 1 character seems impossible. Once this has started, try the next character until you have the whole secret.
From what I understood, there is no general solution to this. There are a few workarounds like including a random-length uncompressible padding or try to pad the compressed content to certain length steps. None of that is a reliable measure.
I investigated this for my ASP.NET Core web apps and found that the CSRF token is included in a form field with double-quotes around it. No user input could ever possibly pass through with double-quotes unencoded, so it's impossible to exploit this in my apps (or most ASP.NET Core MVC). I therefore decided to enable compression.
If you can find a way that lets an attacker exploit this, you probably should not enable compression. It depends on the framework or tools you use. If you do it all yourself, you can format things in such a way as in ASP.NET.
Please let me know if you find out more. I'm not a security expert and my understanding of these things is limited.
-Yves -------- Ursprüngliche Nachricht -------- Von: Tom Browder <tom.browder@xxxxxxxxx> Gesendet: Samstag, 10. Oktober 2020, 20:23 MESZ Betreff: To Gzip or not? I've been looking at ways to speed up my web services using <https://webpagetest.org> for analysis. One thing I've been reading about is using mod_deflate to compress certain files but keep seeing the warnings about using compression with https due to certain known threats. In my searches so far I've not found anything saying that threat has been mitigated. Does anyone here use compression with TLS or have any current advice about the issue? Thanks. Cheers! -Tom --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|