Bug 53219 - mod_ssl should allow to disable ssl compression
mod_ssl should allow to disable ssl compression
Status: RESOLVED FIXED
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl
2.2.22
All All
: P2 enhancement with 4 votes (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: FixedInTrunk
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2012-05-11 21:52 UTC by Björn Jacke
Modified: 2014-02-17 13:43 UTC (History)
5 users (show)



Attachments
patch to add SSLCompession On/Off parameter (3.01 KB, patch)
2012-05-15 20:36 UTC, Björn Jacke
Details | Diff
patch to disable ssl compression (3.36 KB, patch)
2012-05-18 18:22 UTC, Björn Jacke
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Jacke 2012-05-11 21:52:22 UTC
downloading large ammount of data via ssl this is not too cpu consuming on recent CPUs but with browsers that support ssl compression you can see very CPU intensive apache processes due to ssl compression being done. instread of 2% cpu time (encryption only) 50% cpu time (compression+encrytion) will be taken by one apache process in a test.

There is no way to disable ssl compression in mod_ssl even though openssl has "SSL_OP_NO_COMPRESSION" which can be enabled via SSL_CTX_set_options since 1.0.0. For scalability reasons it would be required that ssl compression can be turned off in mod_ssl. I would even suggest to turn it off by default because mod_deflate is doing a much better job and can be better tuned by file types etc.
Comment 1 Björn Jacke 2012-05-15 20:36:31 UTC
Created attachment 28782 [details]
patch to add SSLCompession On/Off parameter

I've created a patch which adds the parameter SSLCompession which can be set to On or Off. By default it uses the default of the SSL library. This patch is against 2.2 but it also applies to 2.4 with some offsets.
Comment 2 Björn Jacke 2012-05-18 18:22:41 UTC
Created attachment 28804 [details]
patch to disable ssl compression

this version of the patch now works with openssl 0.9.8 and newer
Comment 3 Stefan Fritsch 2012-06-01 19:39:31 UTC
Committed to trunk as r1345319 with some tweak to abort with an error when trying to configure compression in virtual-host scope with openssl 0.9.8 (which can only enable/disable compression globally).
Comment 4 Rainer Jung 2012-08-05 18:21:46 UTC
Backported to 2.4.x in r1369585.
Will be part of 2.4.3.
Comment 5 Rainer Jung 2012-08-21 15:58:18 UTC
Released with 2.4.3.
Leaving open for possible back port to 2.2.
Comment 6 Reed Loden 2012-09-13 18:25:25 UTC
(In reply to comment #5)
> Leaving open for possible back port to 2.2.

Considering the potential of abuse of SSL/TLS compression by the new CRIME attack (https://threatpost.com/en_us/blogs/crime-attack-uses-compression-ratio-tls-requests-side-channel-hijack-secure-sessions-091312), can this back port request be prioritized and completed so folks can easily disable SSL/TLS compression if needed? Thanks!
Comment 7 Eric Covener 2012-09-14 10:59:24 UTC
proposed for 2.2.x
Comment 8 Christopher Schultz 2012-10-04 16:22:13 UTC
I'd love to see this in 2.2.x as well, since many Linux distros still aren't supporting 2.4.x, and protection against CRIME is certainly a nice thing to have.
Comment 9 Kaspar Brand 2012-10-07 06:59:41 UTC
Backported to 2.2.x in r1395231. To appear in 2.2.24.
Comment 10 Christoph Anton Mitterer 2012-10-08 00:55:18 UTC
Hi.

It's good to see this backported...

However,... I'm a bit concerned...

As far as I understood,... _ALL_ versions of SSL/TLS are vulnerable to the CRIME attack, right?

So why is compression not forcefully disabled? Not with respect to speed (as originally intended by Björn) but to security.

If newer versions of TLS should fix the attack.... one could allow them to select whether compression should be used or not.

Ideas?
Comment 11 Christopher Schultz 2012-10-10 14:31:52 UTC
(In reply to comment #9)
> Backported to 2.2.x in r1395231. To appear in 2.2.24.

Great! Now, to get Debian to actually put this patch into a release channel...
Comment 12 Christoph Anton Mitterer 2012-10-10 20:06:51 UTC
I've already opened http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689936 .



Nevertheless, as I've mentioned in comment 10, Apache should handle this more by itself.
Comment 13 Björn Jacke 2012-10-10 20:10:11 UTC
also see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674142
Comment 14 Stefan Fritsch 2012-10-21 19:35:19 UTC
The default has been changed to "off" in r1400700
Comment 15 Reed Loden 2012-10-21 21:53:09 UTC
(In reply to comment #14)
> The default has been changed to "off" in r1400700

That's only on trunk, right? What about the default for 2.2.x and 2.4.x?
Comment 16 Christoph Anton Mitterer 2012-10-25 00:25:32 UTC
Hi Stefan.

1) Are you going to backport this into the Debian versions?

2) As long as there is no protocol level fix (or something like this), wouldn't it be better to generally and forcibly switch that off in the affected versions?
I mean if someone would really want it in spite of the attack,... he should probably be able to patch the code accordingly.
Otherwise people may just think that compression sounds like a good thing and "accidentally" enable it (which leads me to: (3)).

3) As far as I can see, the documentation of this directive does not refer to the CRIME attack.
Unless (2) was done (and thus people can't accidentally enable it) I'd strongly recommend adding information that switching compression on allows the CRIME attack and which versions of SSL/TLS/etc. are affected (unless all are).


Cheers,
Chris.
Comment 17 Stefan Fritsch 2012-10-27 20:50:31 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > The default has been changed to "off" in r1400700
> 
> That's only on trunk, right? What about the default for 2.2.x and 2.4.x?

They will be changed, too. But due to the voting on backports, it will take a bit. For 2.4.x, the change has been committed as r1400962 and will be in 2.4.4.


(In reply to comment #16)
> 1) Are you going to backport this into the Debian versions?

Yes.

> 2) As long as there is no protocol level fix (or something like this),
> wouldn't it be better to generally and forcibly switch that off in the
> affected versions?
> I mean if someone would really want it in spite of the attack,... he should
> probably be able to patch the code accordingly.
> Otherwise people may just think that compression sounds like a good thing
> and "accidentally" enable it (which leads me to: (3)).
> 
> 3) As far as I can see, the documentation of this directive does not refer
> to the CRIME attack.
> Unless (2) was done (and thus people can't accidentally enable it) I'd
> strongly recommend adding information that switching compression on allows
> the CRIME attack and which versions of SSL/TLS/etc. are affected (unless all
> are).

The documentation now states "Enabling compression causes security issues in most setups (the so called CRIME attack)." I think that is sufficient.
Comment 18 Christoph Anton Mitterer 2012-11-02 03:03:53 UTC
Thanks.

btw: Does anyone know whether SSL/TLS is going to be fixed? I mean in a way that CRIME is not working while still being able to use TLS compression?
Comment 19 William A. Rowe Jr. 2012-12-17 22:05:09 UTC
Stephan, I didn't catch the r1400962 backport in STATUS, and it didn't appear
to be committed yet to 2.2.  Could you add to 2.2 STATUS so we can +1 the
change before a 2.2.24?
Comment 20 Stefan Fritsch 2013-03-03 16:47:39 UTC
fixed in 2.4.4 and 2.2.24