You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Tom Browder <to...@gmail.com> on 2020/10/10 18:23:46 UTC
[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
Re: [users@httpd] To Gzip or not?
Posted by "@lbutlr" <kr...@kreme.com>.
On 12 Dec 2020, at 06:59, @lbutlr <kr...@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
Re: [users@httpd] To Gzip or not?
Posted by "@lbutlr" <kr...@kreme.com>.
On 10 Dec 2020, at 07:38, Tom Browder <to...@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
Re: [users@httpd] To Gzip or not?
Posted by Tom Browder <to...@gmail.com>.
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
Re: [users@httpd] To Gzip or not? [EXT]
Posted by Daniel Ferradal <df...@apache.org>.
Can you please STOP breaking threads by adding the [EXT] thing to the
title, it is getting quite annoying.
El sáb., 10 oct. 2020 a las 23:14, James Smith (<js...@sanger.ac.uk>) escribió:
>
> There are two sorts of compression - TLS and HTTP.
>
> It is recommended not to compress the TLS traffic (as CRIME can then be used to guess cookies etc) - compresses the whole response.
> But compressing HTTP traffic is OK - unless there is some secret stored in the body of the HTML page {it only compresses the HTML of the page}
>
>
> -----Original Message-----
> From: Antony Stone <An...@apache.open.source.it>
> Sent: 10 October 2020 21:01
> To: users@httpd.apache.org
> Subject: Re: [users@httpd] To Gzip or not? [EXT]
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__webpagetest.org&d
> > =DwICbA&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4o
> > DX0XM7vQ&m=wVQFv3p3IiMCFYbxf3xWL1HmlN3ZkoCLaTAM8DZEBss&s=tshPsEQ7bksjr
> > YsoZ14lId3gKNLPIe14r5lCkak7ujU&e= 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
>
>
>
> --
> The Wellcome Sanger Institute is operated by Genome Research
> Limited, a charity registered in England with number 1021457 and a
> company registered in England with number 2742969, whose registered
> office is 215 Euston Road, London, NW1 2BE.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
--
Daniel
--
Daniel Ferradal
HTTPD Project
#httpd help at Freenode
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] To Gzip or not? [EXT]
Posted by James Smith <js...@sanger.ac.uk>.
There are two sorts of compression - TLS and HTTP.
It is recommended not to compress the TLS traffic (as CRIME can then be used to guess cookies etc) - compresses the whole response.
But compressing HTTP traffic is OK - unless there is some secret stored in the body of the HTML page {it only compresses the HTML of the page}
-----Original Message-----
From: Antony Stone <An...@apache.open.source.it>
Sent: 10 October 2020 21:01
To: users@httpd.apache.org
Subject: Re: [users@httpd] To Gzip or not? [EXT]
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://urldefense.proofpoint.com/v2/url?u=https-3A__webpagetest.org&d
> =DwICbA&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4o
> DX0XM7vQ&m=wVQFv3p3IiMCFYbxf3xWL1HmlN3ZkoCLaTAM8DZEBss&s=tshPsEQ7bksjr
> YsoZ14lId3gKNLPIe14r5lCkak7ujU&e= 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
--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] To Gzip or not?
Posted by Antony Stone <An...@apache.open.source.it>.
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
Re: [users@httpd] To Gzip or not?
Posted by Tom Browder <to...@gmail.com>.
On Sun, Nov 22, 2020 at 09:41 Yves Goergen <no...@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.
Re: [users@httpd] To Gzip or not?
Posted by Yves Goergen <no...@unclassified.de>.
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 <to...@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