Protection against ssl crime attack

D

ditto

Verified User
Joined
Apr 27, 2009
Messages
2,577
You can test your server host name here: https://www.ssllabs.com/ssltest/index.html

I have already manually added fix for beast attack as desribed here http://www.directadmin.com/forum/showthread.php?t=41726

However my servers is vulnerable to the CRIME attack, more info here https://community.qualys.com/blogs/...ime-information-leakage-attack-against-ssltls

The third requirement for wide exploitation is an easy to use exploitation tool. Unlike BEAST, CRIME seems much easier to exploit; we've already seen a simple proof of concept, and so it's likely that we will see a complete tool soon, maybe as a fork of sslstrip.

Further, unlike BEAST, which requires a manual intervention to mitigate, CRIME will be easier to patch. I expect most vendors will simply disable TLS compression.
Click to expand...

And more info here: http://isecpartners.com/blog/2012/9/14/details-on-the-crime-attack.html

Server-Side Mitigation

In most cases you can rely on clients having been patched to disable compression. If you want to perform due diligence you can disable SSL Compression server-side also. You can test for SSL Compression using the SSL Labs service (look for “Compression”in the Miscellaneous section) or using iSEC Partners’ ssl scanning tool sslyze v0.5.

Apache 2.4 using mod_ssl

Apache 2.4.3 has support for the SSLCompression flag. This is a very new release of Apache - the feature itself was added in August, 2012. SSLCompression is on by default - to disable it specify “SSLCompression off”. http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcompression
Click to expand...

I am running centos 6.3, custombuild 1.2 and apache 2.4.3. I will ask that DirectAdmin add fix for this in custombuild for apache 2.4.x, or maybe also for apache 2.2.x

In the meantime, does anybody know how to correctly disable and set “SSLCompression off” in apache 2.4.x?

I also ask that DirectAdmin try to make a fix for this on port 2222, and do that for both crime attack and beast attack. As said I have already manually fixed beast attack, but only on Apache, however DirectAdmin control panel itself is not running Apache, so I have not been able to fix it for DirectAdmin control panel.

Edit: It is also discussed at webhostingtalk: cPanel Apache 2.2.22 and CRIME SSL attack http://www.webhostingtalk.com/showthread.php?t=1199408
 
Last edited:
In the meantime, does anybody know how to correctly disable and set “SSLCompression off” in apache 2.4.x?
Click to expand...

Hello,

What is wrong with that?

http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcompression

Just add that somewhere in:

Code: 
        SSLEngine on
        SSLCertificateFile |CERT|
        SSLCertificateKeyFile |KEY|



n

/usr/local/directadmin/data/templates/custom/virtual_host2_secure.conf
/usr/local/directadmin/data/templates/custom/virtual_host2_secure_sub.conf

and rewrite apache virtual hosts config.
 
Just to be clear for anyone using 2.4.3, you can disable it already, in the new version it will be disabled by default. For 2.2 the next version will have the option to disable it, it hasn't been said that it will be disabled by default there as well.

zEitEr said:
By the way who is at the most risky place with that SSL vulnerabilities? Server owner/administrator? Site owner? Site visitor?

Some interesting reading can be found here: http://isecpartners.com/blog/2012/9/14/details-on-the-crime-attack.html
Click to expand...

Whose risk is the highest I'd say depends on what envoirment you have and what an attacker is after. For a webshop I can imagine customers and their CC info, for site admins their login information and for server owners their login if that is possible (could be, e.g. whmcs).

However the risk is very low, if you see that link IE is not effected and the newest versions of chrome/ff/opera/safari neither and these are usually updated.
 
@Arieh,

Thanks. Am I right when thinking that the issue allows a hacker to decrypt SSL traffic and steal my private information?
 
It is not possible to actually decrypt the ssl. They can get a secure cookie by a form of bruteforce. As a background you need to understand that deflate compression uses a dictionary-like system: it saves up words in a list, then just point to that word instead of using the full word again. The header info contains the cookie=securecookiehere -- and if you put cookie= in the body which you can manipulate, you can see if that matches up with the actual cookie in the header -- by looking at the compression lengths.

In summery this is how I understand it
- It is a man in the middle attack, so access to lan/wan or somewhere on the route is needed (e.g open wifi)
- User is logged in into a secure website they're after
- They make the user go to that secure website on the background, when you visit another website over http (because in a http stream they can insert iframes/javascript) -- who then open requests to that secure website with different cookie strings
- They then look at the streams and see if a match comes up
- They use the cookie themselves to be authenticated as user

Not sure if I cleared up anything, you maybe have to read the article on the link and others if you want.
 
You must log in or register to reply here.
Back
Top