Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are on Ubuntu 12.04 and apache 2.2.2 version. We had PCI scan done on our site and 2 vulnerabilities came out that we can not get under control. First one is BEAST attack and other one SSL RC4 Cipher Suites Supported.

So far I have tried following that looks promising. I tried with few more changes after searching for help, but those changes in turn started breaking browsers and were discarded.

SSLProtocol -SSLv2 -TLSv1 +SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-RC4-SHA:ECDHE-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:RC4-SHA:!MD5:!aNULL:!EDH
SSLCompression off

or

SSLProtocol ALL -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS
SSLCompression off

Based on scan results on ssllabs, I am able to get only one of the vulnerability mitigated. What changes I need to do so that both vulnerabilities are addressed and does support current version of browsers?

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

Well, the mitigation for BEAST (aside from exclusively using TLS 1.1/1.2, which your server can't do right now) is to use RC4.

So, it's probably impossible to configure your server in such a way that it won't be flagged as vulnerable. If you absolutely must get rid of these vulnerabilities, you'll probably need to replace the OS package's OpenSSL installation with a third party package of a newer version, or compiled from source.

share|improve this answer
    
I'd probably front the server(s)/cluster with a reverse proxy that can support later versions of TLS –  Tom O'Connor Sep 25 '13 at 20:24
    
@TomO'Connor That's a very good idea! –  Shane Madden Sep 25 '13 at 20:37
    
Will using ngnix help me? Apache is just front end that serves homepage using wordpress. Actual application is on tomcat served using AJP connectors. I tried researching, but there is lot of contradicting information. I would rather not build/install as responsibility of maintaining it for further updates shifts to our team than OS package management system. –  user871199 Sep 26 '13 at 17:29
    
@user871199 Probably no help from switching to nginx, as it uses OpenSSL as well (and the version of that is your problem). One option would be to ditch OpenSSL and switch to GNUTLS. Another would be to upgrade to a newer version of Ubuntu, which would come with a version of OpenSSL that supported newer TLS. –  Shane Madden Sep 26 '13 at 18:40
add comment

These days the BEAST attack is generally mitigated through 1/n-1 record splitting, since RC4 is considered too weak to use today. Check your distribution's security advisories for an updated OpenSSL that implements 1/n-1 record splitting, resolving CVE-2011-3389. (Note that Ubuntu seems to already have it.)

Of course, using a server capable of TLS 1.2 is the preferred solution.

share|improve this answer
    
Looks like Ubuntu calls it not vulnerable because of the 0/n splitting from back in 0.9.6d.. but since that breaks stuff, I wonder if it's enabled by default in Apache? –  Shane Madden Sep 25 '13 at 19:36
    
I don't think 0/n is enabled by default out of the box, though Ubuntu might be enabling it. –  Michael Hampton Sep 25 '13 at 19:37
    
Not sure if they do, actually.. from the chat log on their CVE summary page: removing SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS will break compatibility with certain SSL implementations, which is why it's included in SSL_OP_ALL in the first place. Since the BEAST attack is only practical in web browsers where you can run arbitrary code, and current web browsers are already fixed, modifying other software in the archive to enable the work around will break compatibility with no added security benefit. –  Shane Madden Sep 25 '13 at 19:40
    
They assume, of course, that everyone updates their browsers and applies all their security patches. This is, of course, a ridiculous assumption. –  Michael Hampton Sep 25 '13 at 19:41
    
Yeah, seriously. Actually, I'm struggling to find any distros using 1/n-1 in their OpenSSL.. seems like that's mostly just been implemented client side? –  Shane Madden Sep 25 '13 at 19:49
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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