Because of CRIME, as I understand, compression on SSL connections have to be turned off. In newer versions of apache this can be done with a newly introduced directive SSLCompression off, in older versions this is not possible (in Debian before version 2.2.16-6+squeeze10).

I think I have found a way to achieve this in older versions, but I am not sure why in some online tests, like the Qualsys SSL Test it indicates compression is still on. My test do show something different. Could anyone please review the configuration code and tell me, what I do not understand right?

Use the following directives from mod_headers inside a SSL virtual host block to switch off compression:

RequestHeader unset Accept-Encoding
Header unset Vary

This removes the header line from the client request indicating the response may be sent compressed to the client.

Testing this with curl and the --raw switch, I see that non-ssl connections are compressed and ssl connections are cleartext. Use...

curl --raw -k -H 'Accept-Encoding: gzip,deflate' http://host.example.tld

...to check.

Some online testing tool still tell me my solution does not work, while others say the contrary. Now I wonder wether my solution to turn off compression for ssl connection is working or not?


First, CRIME only applies if your website uses all of these three:

  1. SSL or TLS
  2. Compression
  3. Cookie Authenticated Sessions

It is only useful for hijacking active sessions, and is most useful if your server doesn't require session IP matching. While many websites do use this combination, it's not as common as many would think. Also, some statistics suggest that <7% of browsers on the Internet actually support the compressions that makes CRIME possible.

What Does NOT Work:
The Vary field just tells upstream proxies if they're allowed to cache a dynamic page. While it's important to consider for your caching strategy, not so much for this particular vulnerability.

Unsetting the Accept-Encoding field will only affect mod_deflate or mod_gzip; it doesn't affect compression by SSL/TLS. So your method will not work.

What Does Work:
There are two options for protecting your server. You can disable compression support in your SSL/TLS library, by recompiling it without compression; or you can patch your server to support the SSLCompression directive. Apache 2.4.x supports this directive natively. Apache 2.2.22 can be patched relatively easily.

Various Operation System Distributions are back-porting the patches now, check with your Distro provider for details (most Linux Distro use ancient versions of Apache that they've written custom back-ports of security patches for. So you'll pretty much be at your Distro's mercy if you're using their sanctioned packages).

How Sure Are You:
There's a very easy to use SSL "Problem" Scanner available from SSL Labs. It will detect if your server is CRIME vulnerable. You can semi-ignore BEAST warnings as all modern browsers have fixed the issue client side. It would depend on your particular set of circumstances however.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.