Protection against the 'Browser Exploit Against SSL/TLS' (BEAST)

interfasys

interfasys

Verified User
Joined
Oct 31, 2003
Messages
2,100
Location
Switzerland
TLS protection is getting weaker and weaker and now that we have more details on how BEAST works, it could be time to make some changes to the way DA works.
CRAM-MD5 could be implemented in Exim and Dovecot to better protect our servers and we could make sure all apps using TLS use the rc4-sha mode instead of the CBC one when encrypting/decrypting data.
 
I just read Cloadflare blog post about the "Beast attack" at http://blog.cloudflare.com/taming-beast-better-ssl-now-available-across

When I check my server hostname at https://www.ssllabs.com/ssltest/index.html the result say

"BEAST attack Vulnerable INSECURE (more info)" wich link to this page: https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls

I am running CentOS 6.2 with newest DirectAdmin version. Is there any good how-to for servers running DirectAdmin and CentOS 6.x with solution for this?
 
Arieh,

Thanks, I've changed my httpd-ssl.conf file and httpd-vhosts.conf file to your values, and I'm getting a score of 85 now.

Do you know whether it would be better to change the cipher_list from exim, dovecot, proftpd?
Right now i'm using
dovecot: ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
exim: ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
proftpd: HIGH:MEDIUM:+TLSv1:-SSLv2:+SSLv3

thanks,
Stijn
 
It appears that OpenSSL fixes this beast issue by default, but apache and exim disable the fix for compatibility (SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS setting).

So we got apache covered with those settings, for Exim I found this: https://lists.exim.org/lurker/message/20110924.025611.322d31d8.en.html - he says at the end that RC4-SHA should be used. However I read that they key solution lies within RC4. By default we see RC4+RSA - I'm not sure if thats enough and that we maybe need to change it to RC4-SHA?

For dovecot I found this http://hg.dovecot.org/dovecot-2.0/rev/e3d46fd04105 - they enabled the openssl fix, and no big deal anyway they say (for dovecot)

protfpd also "Enable OpenSSL countermeasure against SSLv3/TLSv1 BEAST attacks." by default http://www.proftpd.org/docs/NEWS-1.3.4a

So in summery it looks like exim might need that RC4-SHA flag and the others are in the clear but some confirmation from someone who knows for sure would be nice.
 
Thanks! After reading this and your post at http://www.directadmin.com/forum/showthread.php?t=37378 I am under impression that the only file I need to edit is /etc/httpd/conf/extra/httpd-ssl.conf - is that correct, or do I have to edit httpd-vhosts.conf also? (because user Kiekeboe100 said he edited both files). I am preparing to make these changes now ...
 
At the end it will probably not matter, but I got it like in the thread 2 times only in httpd-ssl.conf. To be sure it works just test it with ssllabs.
 
Ok. I have now tested. It works great. Previous my rating was 61, after the changes it was 85. Nice!

I only changed the file /etc/httpd/conf/extra/httpd-ssl.conf

Also I did not add this line: "SSLInsecureRenegotiation off" - because the report already said that "Secure Renegotiation Supported, with client-initiated renegotiation disabled". I am running CentOS 6.2 and Apache 2.2.22, so the renegotiation thing must already be set this way by default.

By the way, is there any know compability problems I should expect after doing the changes? It looks like it work without trouble ...

Also, how did you get a rating of 88? here http://www.directadmin.com/forum/showthread.php?t=37378 - I only got 85. Hehe. :)
 
Hmm. I found something I don't like. After commenting out this line in httpd-ssl.conf:

Code: 
#SSLCipherSuite ALL:-ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP

And then after adding these lines to the bottom of httpd-ssl.conf:

Code: 
SSLProtocol -ALL +SSLv3 +TLSv1
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH

Then when I check the ssl cert in my web browser, it say this:

Code: 
TLS v1.0 [B]128 bit[/B] ARC4 (2048 bit RSA/SHA)

But before it was like this:

Code: 
TLS v1.0 [B]256 bit[/B] AES (1024 bit DHE_RSA/SHA)

I want it back to be 256 bit, I don't want only 128 bit. :(
 
Again, thank you Arieh! I have now implemented the changes, and are happy. However one thing that I am uncertain about:

I am running DirectAdmin panel on https, and in my browser it says:
Code: 
TLS v1.0 256 bit AES (2048 bit RSA/SHA)

All other pages exept DirectAdmin panel, it says:
Code: 
TLS v1.0 128 bit ARC4 (2048 bit RSA/SHA)

I understand that this is because DirectAdmin does not use Apache. However I wonder if I somehow should do the same change to DirectAdmin also? Or is it best to leave it like this?
 
Well there's this: http://www.directadmin.com/features.php?id=957

But it does make me wonder about SSLProtocol, as this seems to be the variant of SSLCipherSuite.

As soon as you try to specify a protocol it seems, it will not listen on ssl.

I also tried the ssl_cipher=SSLv3 as in the KB article, but that won't work either. Maybe John can tell how this works.

edit: spoke with a friend of mine, like this it will use RC4-SHA:

Code: 
ssl_cipher=RC4-SHA
 
Last edited:
The SSLInsecureRenegotiation directive is not available with this SSL library
Click to expand...
I guess I need to update Apache for mod_ssl to support SSLInsecureRenegotiation?

Had a score of 85% though
 
Ummmm i wouldnt put too much emphasis on this problem. Even the author states his security site hasnt been updated since 2009?

I am sorry to say that I have not updated the rating guide since 2009. As a result, it has become stale. I expect a quick update by the end of the year, to bring the scoring criteria with the current threats, and a major update in the next year.
Click to expand...
 
Where does it say that? Can't find it if I click around in the posted links.

But this exploit was of 2011 so all info and tools were of that time at least.
 
I see they recommend to use the SSLCompression off directive, but we (CB) have Apache 2.2 (by default) and it is only for 2.4...
 
Last edited:
Peter Laws said:
I see they recommend to use the SSLCompression off directive, but we (CB) have Apache 2.2 (by default) and it is only for 2.4...
Click to expand...

It seems to me that you are talking about the "CRIME" attack? I would guess you are ...

This is added to the upcomming next version 2.2.24, so you could just wait until then. Here is quote from changelog in svn http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/CHANGES

*) mod_ssl: Add new directive SSLCompression to disable TLS-level
compression. PR 53219. [Björn Jacke <bjoern j3e de>, Stefan Fritsch]
Click to expand...

And for those that is using Apache 2.4.x, I would also just wait, because SSLCompression will by default be off in Apache 2.4.4 http://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/CHANGES

*) mod_ssl: Change default for SSLCompression to off, as compression
causes security issues in most setups. (The so called "CRIME" attack).
[Stefan Fritsch]
Click to expand...
 
For httpd 2.2 it will be available in the next version (.24). If you're on CentOS you can put this in /etc/init.d/httpd

export OPENSSL_NO_DEFAULT_ZLIB=1

And then try the ssllabs tester or this simple tool if you don't want to wait 2 minutes the whole time.

For Debian I haven't found a simple solution, I believe the debian apache package has the fix backported but that's no use for a DA setup. Other possibility would be to recompile openssl without zlib but that's not a neat fix either. I would say going to apache 2.4 would be best.

For 2.4.3 (latest in cb) you can just set SSLCompression off at e.g. the very bottom of /etc/httpd/conf/extra/httpd-ssl.conf
 
You must log in or register to reply here.
Back
Top