What's left of TLS

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.

Listing 1

Configuration Example

SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
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.

Listing 2

Practical Settings

SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
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.

The Author

Hanno Böck is a freelance journalist and volunteer developer with Gentoo Linux. He also works for web hosters schokokeks.org, which relies exclusively on free software for its services.

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • SSL/TLS best practices for websites
    SSL and TLS are very complex technologies. If you want to avoid wading through cryptography manuals to harden your HTTPS web server, read on for practical recommendations on establishing, securing, and optimizing your SSL/TLS configuration.
  • SHA-3 – The New Hash Standard

    NIST has chosen the Keccak algorithm as the new cryptographic hash standard, but in real life, many users are still waiting to move to its predecessor, SHA-2.

  • Security as Code
    Gauntlt is a sophisticated DevOps tool that can test the security of your continuous integration/continuous delivery pipeline.
  • SHA-3 – The new hash standard
    NIST has chosen the Keccak algorithm as the new cryptographic hash standard but, in real life, many users are still waiting to move to its predecessor SHA-2.
  • Throw Down the Gauntlet
    Gauntlt is a sophisticated DevOps tool that can test the security of your continuous integration/continuous delivery pipeline.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=