Recommendations for TLS/SSL Cipher Hardening

Transport Layer Security (TLS) and its predecessor, Secure Socket Layer (SSL) are widely used protocols designed secure the transfer of data between the client and the server through authentication and encryption and integrity.

Contrary to common assumptions TLS/SSL is a not only a widely used technology in websites and web applications (using the HTTP protocol), but TLS/SSL is also widely used by several other services and protocols including, but not limited to email servers (SMTP, POP and IMAP protocols), FTP servers, chat servers (XMPP protocol), virtual private networks (TLS/SSL VPNs), network appliances.

In order to secure data that is being transferred, TLS/SSL makes use of one or more cipher suites. A cipher suite is a combination of authentication, encryption and message authentication code (MAC) algorithms. All of which are used during the negotiation of security settings for a TLS/SSL connection as well as for the secure transfer of data.

Some of the following are examples of what algorithms a cipher suite may use.

Function Algorithm
Key Exchange RSA, Diffie-Hellman, ECDH, SRP, PSK
Authentication RSA, DSA, ECDSA
Bulk Ciphers RC4, 3DES, AES
Message Authentication HMAC-SHA256, HMAC-SHA1, HMAC-MD5

While implementing TLS is a step in the right direction, getting the implementation wrong can provide a false sense of security, and worst still, it can render websites and networks vulnerable to several kinds of attacks.

Most of the common configuration mistakes when implementing TLS lie in the choice of cipher suites. By using old or outdated cipher suites, especially those that suffer from different kinds of attacks, may allow an attackers to gain access or successfully tamper secret data while in transit. Below is a list of recommended configurations to make to your TLS/SSL implementations.

Disabling SSL 2.0 and SSL 3.0

SSL 2.0 was the first publicly released version of SSL in 1995. This version of SSL contained a number of security issues which lead to the introduction of SSL 3.0. SSL 3.0 was released in 1996 with a complete redesign of the protocol.

Because of the issues presented in SSL2.0, the protocol is unsafe to use and should be completely disabled.
Due to the POODLE (Padding Oracle On Downgraded Legacy. Encryption) vulnerability, SSL 3.0 is also unsafe to use and should be disabled in order to avoid the plaintext of secure connections to be calculated a network attacker. Furthermore, Elliptic Curve Cryptography (discussed later on in this article) cannot be used with SSL3.0.

Internet Explorer 6 is the only remaining browser that still makes use of SSL3.0. Therefore, unless there is still the specific need to support the legacy Internet Explorer 6 browser, SSL 3.0 should be disabled as explained later on. If on the other-hand the support for legacy browsers is required, it is highly recommended to support TLS_FALLBACK_SCSV. This mechanism prevents protocol downgrade attacks on the TLS protocol and thus prevents attackers from inducing browsers to use SSL 3.0.

Disabling TLS 1.0 Compression and Weak Ciphers

It is highly advised to disable TLS 1.0 compression to avoid CRIME attacks.

Furthermore, it is also crucial to disable weak ciphers. Weak ciphers such as DES and RC4 should be disabled. Using current technology, DES can be broken in a few hours while RC4 has been found to be weaker than was previously thought. While it may have been advised to use RC4 to mitigate BEAST attacks in the past, given the latest attacks on the RC4 cipher, Microsoft has issued an advisory again its use.

The Configuration

The following configuration is a recommended configuration that makes use of the most secure ciphers first and gradually fall back to less-preferred ciphers should the client not support them. The following configuration is assuming that OpenSSL is being used.


The table below breaks down the string above into what is preferred in order (best key exchange algorithm/strongest encryption first).

Preference Key Exchange Algorithm Encryption Algorithm
#1 Elliptic Curve Diffie–Hellman (ECDH) AES in Galois Counter Mode (AESGCM)
#2 Diffie–Hellman (DH) AES in Galois Counter Mode (AESGCM)
#3 Elliptic curve Diffie–Hellman (ECDH) AES-256 (AES256)
#4 Diffie–Hellman (DH) AES-256 (AES256)
#5 Elliptic Curve Diffie–Hellman (ECDH) AES-128 (AES128)
#6 Diffie–Hellman (DH) 128 or 256 bit AES (AES)
#7 Elliptic Curve Diffie–Hellman (ECDH) Triple DES (3DES)
#8 Diffie–Hellman (DH) Triple DES (3DES)
#9 RSA AES in Galois/Counter Mode (AESGCM)
#9 RSA Triple DES (3DES)

The string provides the best possible encryption in all browsers and TLS/SSL clients (AES in Galois Counter Mode is only supported in TLS 1.2); it disables cipher suites that do not require any authentication (!aNULL) as well as cipher suites that make use of the MD5 hashing algorithm (!MD5). Furthermore, the string also provides Perfect Forward Secrecy if both the server and the TLS/SSL client have support for it.

Note — More Information on ciphers supported by OpenSSL is available here.

Implementation on Apache HTTP Server (mod_ssl)

The following configuration block can be used in Apache HTTP Server 2.2+/2.4+ with mod_ssl. However, there is an exception of being able to turn off TLS/SSL Compression as this is only possible Apache HTTP Server 2.2.24/2.4.3+ using the SSLCompression directive.

SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCompression Off
Note — RedHat-based OSs (REHL, CentOS, Fedora…) users need to insert export OPENSSL_NO_DEFAULT_ZLIB=1 in /etc/sysconfig/httpd instead of applying SSLCompression Off since the directive has not yet been made available on these OSs.

Implementation on nginx

The following configuration block can be used in nginx. Disabling TLS compression on nginx will depend on the version of OpenSSL and nginx that the server is running. If the server is running OpenSSL 1.0 or later and nginx 1.1.6+ or 1.0.9+, TLS compression is turned off by default. If however, a version of OpenSSL older than 1.0 is being used, nginx 1.2.2+/1.3.2+ is required.

ssl_prefer_server_ciphers On;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Note — RedHat-based OSs (REHL, CentOS, Fedora…) users interested in making use of ECDH key exchange ciphers may need to compile nginx from source (or download nginx binaries from a separate package repository) since the compiled version of nginx on these OSs is an older one.
Share this post
  • Nice guide, may you have a look (and contribute) at
    “This project aims at creating a simple, copy & paste-able HOWTO for secure crypto settings of the most common services (webservers, mail, ssh, etc.). It is completely open sourced, every step in the creation of this guide is public, discussed on a public mailing list and any changes to the text are documented in a publicly readable version control system.”

  • Thanks for this – very good guide. Just one small typo stopped my Apache from restarting successfully: In the “Implementation on Apache HTTP Server (mod_ssl)” code example, the first line has a long dash, which should just be a minus symbol. i.e. “SSLProtocol ALL -SSLv2 –SSLv3” should be “SSLProtocol ALL -SSLv2 -SSLv3”.

  • Thanks for the article…

    ‘It is highly advised to disable TLS 1.0 compression to avoid CRIME attacks.’
    ‘ssl_protocols TLSv1…’

    Aren’t those two lines in conflict?

  • Thanks for this article. It helped us verify that we are on the right track as we fiddled up to this point while going through PCI compliance.

  • I wonder if this article needs an update? A lot has happened between the date the article was posted (OCTOBER 15, 2014) until now.

  • Hi Tamara Naudi, i’ve read the article but apparently, it does not show any recommended list of cipher suite to use. 🙁

  • Leave a Reply

    Your email address will not be published.