How to Mitigate CRIME attack in Apache

Perhaps you've seen the new CRIME attack on Compression in TLS connections.

The exploit uses a sidechannel attack (a piece of JavaScript running on the victim's machine) to repeatedly query a server and compare the time it takes each request to complete to eventually learn what the contents of an HTTP cookie is (while examining the encrypted packets on the wire using main-in-the-middle). Proof of concepts have been shown against Github, Dropbox and Stripe.

If you're running Apache you'll probably want to mitigate the attack, so here's how.

Mitigation in Apache 2.4.3+

Just add the line 'SSLCompression off' to your SSL configuration and restart Apache.

Mitigation in Apache 2.2 and Apache <= 2.4.2

Unfortunately older versions of Apache don't have an option to disable SSL compression (it's still being backported as of this writing). There are three options you have, one will work, the other two maybe not.

The first option is to recompile OpenSSL without zlib support; this will prevent the DEFLATE compression method from being used by the SSL module. This is a pain, but is guaranteed. You should still be able to use mod_deflate to compress HTML, however.

The second option you have is to patch Apache 2.2.22 (and possibly earlier versions) to include an SSLCompression option like in Apache 2.4.3. I just created this patch based on the 2.4.3 patch, but have not tested it. The code was pretty much verbatim the same however, so it should work. The patch is here.

The third option may not actually prevent the attack, but it's an idea I had. The configuration looks like this:

    SSLOptions +StrictRequire
    <Location />
    SSLRequire (  %{SSL_COMPRESS_METHOD} ne "DEFLATE" )
    </Location>

This will force any request to fail in "<Location />" if the request used SSL compression. The browser may still send a cookie with ssl compression, however, so the server may still cache the request and might have a similar side-chain attack vector to the original exploit. Use with caution and verify for yourself if the exploit is still viable.

Resources:

https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcompression
https://issues.apache.org/bugzilla/show_bug.cgi?id=53219