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
SSLCompression off


SSLProtocol ALL -SSLv2
SSLHonorCipherOrder On
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?


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.

  • 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

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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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