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.brow...@gmail.com>
Gesendet: Samstag, 10. Oktober 2020, 20:23 MESZ
Betreff: [users@httpd] 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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
