Mailing List Archive

On Saturday 10 October 2020 at 20:23:46, Tom Browder wrote:

> 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

Which warnings? Where?

> about using compression with https due to certain known threats.

What 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?

Can you point us at any document about what this "issue" is, so that we know
what "threat" you're concerned about?


Antony.

--
Was ist braun, liegt ins Gras, und raucht?
Ein Kaminchen...

Please reply to the list;
please *don't* CC me.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

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@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-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

On Sun, Nov 22, 2020 at 09:41 Yves Goergen <nospam.list@unclassified.de>
wrote:

> I've recently learned about these issues, too.


Thanks, Yves, I've delayed answering because I was collecting various
pieces of references and got lost trying to put it all together.

I hope all are well and wish you all a Merry Christmas.

-Tom

P.S. I am NOT using compression, nor have I ever used it.

On Sat, Oct 10, 2020 at 15:01 Antony Stone <
Antony.Stone@apache.open.source.it> wrote:
> On Saturday 10 October 2020 at 20:23:46, Tom Browder wrote:
...

>
> > 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
>
> Which warnings? Where?
...

>
> > about using compression with https due to certain known threats.
>
> What threats?
...

> Can you point us at any document about what this "issue" is, so that we
know
> what "threat" you're concerned about?

Well it started with the docs for 2.4 and mod_deflate. Therein is this,
quote: =====>

Compression and TLS

Some web applications are vulnerable to an information disclosure attack
when a TLS connection carries deflate compressed data. For more
information, review the details of the "BREACH" family of attacks.

<===== End quote.

I searched for the doc reference "BREACH" + "attack" and got several hits
such as: TLSv1.3 has a post-handshake problem

And an excerpt from it, quote: =====>

CRIME and TIME

CRIME (Compression Ratio Info-leak Made Easy) is a cross-layer protocol
attack that includes a compression side-channel attack against HTTPS. It
leverages information leaked by TLS compression on messages sent from the
client to the server. CRIME can recover targeted parts of the plaintext
given a MiTM access.

In March 2013 at the Black Hat (EU), Tal Be’ery presented an extension of
CRIME named TIME. It debuted two new enhancements: it used CRIME for
server-to-client messages and did not require a MiTM situation by
exploiting TCP window sizes. The first of these two modifications gave rise
to BREACH (see further down).

THE FIX: CRIME is ineffective against TLS 1.3 because TLS 1.3 disables
TLS-level compression.

To verify if a server is vulnerable to CRIME on port 443:

openssl s_client -connect domainname.com:443

In the output of this command, look for TLS compression; if enabled, the
server is vulnerable to CRIME.

<===== End quote.

When I last serious upgrades to my servers last July one problem with using
TLS 1.3 was that the Firefox browser couldn't use it as because of
post-handshake problems. So I'm currently running TLSv1.2.

Best,

-Tom

On 10 Dec 2020, at 07:38, Tom Browder <tom.browder@gmail.com> wrote:
> When I last serious upgrades to my servers last July one problem with using TLS 1.3 was that the Firefox browser couldn't use it as because of post-handshake problems. So I'm currently running TLSv1.2.

Firefox in general? Or some specific (or old) version? It has no issues connecting to TLS 1.4 for me. All you have to do for TLS 1.2 to be secure agains BREACH/CRIME is to disable the header compression, if you are unlucky enough to have an implementation that enabeld it by default. If you have recent-ish versions of openSSL I don't think you can enable compression without patching and rebuilding.

(I don't run Firefox myself, but I launch it every few months to make sure my stuff at least loads on it)

--
Say, give it up, give it up, television's taking its toll That's
enough, that's enough, gimme the remote control I've been nice,
I've been good, please don't do this to me Turn it off, turn it
off, I don't want to have to see


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

On 12 Dec 2020, at 06:59, @lbutlr <kremels@kreme.com> wrote:
> TLS 1.4

1.3

--
"Are you pondering what I'm pondering?"
"Well, I think so, Brain, but snort no, no, it's too stupid!"


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org