Incomplete Security

Your Apache Configuration

On the Apache web server, you can set the supported TLS modes through the options SSLProtocol and SSLCipherSuite. A configuration that uses only TLS 1.2 and only GCM algorithms with Perfect Forward Secrecy is enabled, as shown in Listing 1. The problematic compression is disabled.

SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384
SSLCompression off

A more realistic approach for production operation is shown in Listing 2. All medium- and low-strength algorithms are switched off, as are algorithms that offer no authentication. Also, the now quite old SSL version  3 is disabled. TLS version 1.0 has long been supported by all browsers, so activation of the old SSL versions should no longer be necessary.

SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH
SSLCompression off

One restriction is that algorithms that perform a key exchange with elliptic curves (ECDHE) are only supported in Apache version 2.4 or newer, but only a few distributions offer this version out of the box. The options I mentioned still work; unsupported algorithms are then simply ignored.

If you want to avoid 1024-bit Diffie-Hellman, you can either install an experimental patch from Apache [5] or delete the DHE-RSA-AES256-GCM-SHA384 method from the configuration and only offer a key exchange via elliptic curves. Disabling the vulnerable compression is not an option in older versions of Apache. It was introduced for the 2.2 series in version 2.2.24.

For the GCM algorithms in TLS  1.2 to work, you need a version of OpenSSL newer than 1.0.1 – which is now available in most Linux distributions. Then, you can check the configuration page with the SSL test by Qualys [6]. You will see numerous comments if something is wrong with your configuration and a rating for the security of your configuration. However, considering the BEAST attack, I would advise against using the recommendations given on the site. The online test was still recommending the RC4 algorithm when this issue went to press.

The Bottom Line

TLS is getting on in years. The technology currently used in browsers and web servers is something no one would develop today. Recent attacks put a spotlight on its vulnerabilities. In practical terms, however, you do not really need to worry. The attacks are complicated and only possible in conjunction with circumstances that are fairly infrequent. Web application security is still typically endangered by far more mundane problems. Cross-site scripting vulnerabilities and SQL injection attacks, for example, which have nothing to do with cryptography, are a far more serious threat that cannot be prevented even with the best encryption.

However, this does not mean you should take the whole thing too lightly. The fact that the most important cryptographic protocol today is so vulnerable is certainly not a good thing, and more advanced exploits are very likely only a matter of time.

The solution to most of the problems discussed here has been around for a long time. It is a five-year-old standard called TLS version 1.2, which no one uses. The problems that dog TLS have long been known, which demonstrates one of the difficulties in developing secure network technologies: As long as there are no practical attacks, many programmers and system administrators see no reason to switch to newer standards and update their systems. They prefer to wait until they have clear evidence of an exploit and their systems are vulnerable in the field. This mindset does not make much sense, but it is, unfortunately, very widespread.