| Summary: | mod_ssl should allow to disable ssl compression | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Björn Jacke <bjoern> |
| Component: | mod_ssl | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | apache_bugzilla, calestyo, herrold, reed, slezhuk |
| Priority: | P2 | Keywords: | FixedInTrunk |
| Version: | 2.2.22 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
patch to add SSLCompession On/Off parameter
patch to disable ssl compression |
||
|
Description
Björn Jacke
2012-05-11 21:52:22 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.
Created attachment 28804 [details]
patch to disable ssl compression
this version of the patch now works with openssl 0.9.8 and newer
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). Backported to 2.4.x in r1369585. Will be part of 2.4.3. Released with 2.4.3. Leaving open for possible back port to 2.2. (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! proposed for 2.2.x 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. Backported to 2.2.x in r1395231. To appear in 2.2.24. 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? (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... 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. The default has been changed to "off" in r1400700 (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? 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. (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. 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? 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? fixed in 2.4.4 and 2.2.24 Hello All, I'm using httpd-2.2.22-win32-x86-openssl-0.9.8t. I want to disable the Compression algorithms to resolve the SSL/TLS Compression Algorithm Information Leakage Vulnerability. Please guide me. Thanks Muthu muthamilan@yahoo.com/muthamilan@gmail.com You can't reopen a fixed report because it does not fit your version. This is implemented in 2.2.24, just use that version or better, the latest 2.2 (currently 2.2.29). Hello Yann, I'm new to this fourm. Sorry I wrongly changed the status. As per your update, I have to upgrade my Apache version to disable SSL compression. please guide me Thanks, Muthu Hello Yann, I'm new to this fourm. Sorry I wrongly changed the status. As per your update, I have to upgrade my Apache version to disable SSL compression. please guide me Thanks, Muthu Hello Yann, I'm new to this fourm. Sorry I wrongly changed the status. As per your update, I have to upgrade my Apache version to disable SSL compression. please guide me Thanks, Muthu Bugzilla is for reporting bugs, not for support. Please use the users mailing-list (users@httpd.apache.org) and/or read http://httpd.apache.org/docs/2.2/install.html. (In reply to Christoph Anton Mitterer from comment #18) > 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? Hi, I'm using ddlutils 1.0 and tomcat jdbc pool 1.0.7.1 and I getting an error due to a connection is closed and the pool is not aware of that. Basically the issue is that ddlutils has a resultset iterator and when it finishes it closes the connection by getting it from the * resultSet.preparedStatement.connection* and the connection returned is not the proxy that the pool has created. So the issue happens when another client retrieves a connection from the pool because the pool returns a connection that was actually closed. Why tomcat jdbc pool is not creating proxies for preparedStatements and resultSets like commons-dbcp? Is there any other way to address this issue? Thanks Antonio - https://kmidata.es/ >
> I'm using ddlutils 1.0 and tomcat jdbc pool 1.0.7.1 and I getting an error
> due to a connection is closed and the pool is not aware of that.
off-topic for this closed httpd bug.
|