Ssl – How to simulate SSL client failing handshake

1.) is recommended because of this, so #1 is a good idea anyway.

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.