Recommendations for TLS/SSL Cipher Hardening

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

TLS/SSL technology is commonly used in websites and web applications together with the HTTP protocol. It is also used by several other services and protocols, for example, email (SMTP, POP, and IMAP protocols), FTP, chat (XMPP protocol), virtual private networks (TLS/SSL VPNs), and network appliances.

To secure the transfer of data, TLS/SSL uses one or more cipher suites. A cipher suite is a combination of authentication, encryption, and message authentication code (MAC) algorithms. They are used during the negotiation of security settings for a TLS/SSL connection as well as for the transfer of data.

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

TLS is now a requirement in several regulatory standards. Major browsers mark sites as not secure in absence of TLS. It may therefore also be considered a requirement for serving websites and web applications. However, getting a correct TLS implementation may be difficult. Bad TLS configurations may provide a false sense of security and make websites and web applications vulnerable to attacks.

Many common TLS misconfigurations are caused by choosing the wrong cipher suites. Old or outdated cipher suites are often vulnerable to attacks. If you use them, the attacker may intercept or modify data in transit. Below is a list of recommendations for a secure SSL/TLS implementation.

Disabling SSL 2.0 and SSL 3.0

SSL 2.0 was the first public version of SSL. It was released in 1995. This version of SSL contained several security issues. In 1996, the protocol was completely redesigned and SSL 3.0 was released.

Because of the security issues, the SSL 2.0 protocol is unsafe and you should completely disable it. Due to the POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability, SSL 3.0 is also unsafe and you should also disable it. If it is enabled, an attacker may retrieve plain text content of secure connections. Furthermore, you cannot use elliptic-curve cryptography (see below) with SSL 3.0.

Internet Explorer 6 is the only browser that still uses SSL 3.0. Therefore, unless you still need to support the legacy Internet Explorer 6 browser, you should disable SSL 3.0 as outlined below.

Disabling TLS 1.0 and 1.1

Unless you need to support legacy browsers, you should also disable TLS 1.0 and TLS 1.1. The PCI DSS (Payment Card Industry Data Security Standard) specifies that TLS 1.0 may no longer be used as of June 30, 2018. It also strongly suggests that you disable TLS 1.1. These protocols may be affected by vulnerabilities such as FREAK, POODLE, BEAST, and CRIME. If you must still support TLS 1.0, disable TLS 1.0 compression to avoid CRIME attacks.

You should also disable weak ciphers such as DES and RC4. DES can be broken in a few hours and RC4 has been found to be weaker than previously thought. In the past, RC4 was advised as a way to mitigate BEAST attacks. However, due to the latest attacks on RC4, Microsoft has issued an advisory against it. The PCI DSS also prohibits the use of the RC4 bulk cipher.

If you disable TLS 1.0 and TLS 1.1, the following user agents and their older versions will likely be affected (specific user agent versions on different operating systems may vary).

  • Android 4.3
  • Chrome 29
  • Firefox 26
  • Internet Explorer 10
  • Java 6u45, 7u25
  • OpenSSL 0.9.8y
  • Safari 6.0

How to Configure TLS

Depending on your business use case (e.g. the need to support legacy browsers and regulatory requirements) you may need to use slightly different cipher suite configurations. You may use the Mozilla SSL Configuration Generator to obtain an optimal TLS configuration using different browser profiles (modern, intermediate, or old).

The following is a breakdown of the modern profile (oldest compatible clients: Firefox 27, Chrome 30, Internet Explorer 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0, and Java 8). The syntax for enabling/disabling TLS protocols and cipher suites will vary slightly depending on the web server.

Nginx

# Enable TLSv1.2, disable SSLv3.0, TLSv1.0 and TLSv1.1
ssl_protocols TLSv1.2;

# Enable modern TLS cipher suites
ssl_ciphers 
'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

# The order of cipher suites matters
ssl_prefer_server_ciphers on;

Apache HTTP Server

# Enable TLSv1.2, disable SSLv3.0, TLSv1.0 and TLSv1.1
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1

# Enable modern TLS cipher suites
SSLCipherSuite          
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

# The order of cipher suites matters
SSLHonorCipherOrder     on

# Disable TLS compression
SSLCompression          off

# Necessary for Perfect Forward Secrecy (PFS)
SSLSessionTickets       off

Preferred Cipher Suite Order

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

Order Key Exchange Algorithm Authentication Algorithm Bulk Encryption Algorithm Mac Algorithm
#1 Elliptic Curve Diffie–Hellman (ECDH) Elliptic Curve Digital Signature Algorithm (ECDSA) AES 256 in Galois Counter Mode (AES256-GCM) SHA384
#2 Elliptic Curve Diffie–Hellman (ECDH) RSA AES 256 in Galois Counter Mode (AES256-GCM) SHA384
#3 Elliptic curve Diffie–Hellman (ECDH) Elliptic Curve Digital Signature Algorithm (ECDSA) ChaCha20 (CHACHA20) POLY1305
#4 Elliptic curve Diffie–Hellman (ECDH) RSA ChaCha20 (CHACHA20) POLY1305
#5 Elliptic Curve Diffie–Hellman (ECDH) Elliptic Curve Digital Signature Algorithm (ECDSA) AES 128 in Galois Counter Mode (AES128-GCM) SHA256
#6 Elliptic curve Diffie–Hellman (ECDH) RSA AES 128 in Galois Counter Mode (AES128-GCM) SHA256
#7 Elliptic Curve Diffie–Hellman (ECDH) Elliptic Curve Digital Signature Algorithm (ECDSA) AES 256 (AES256) SHA384
#8 Elliptic curve Diffie–Hellman (ECDH) RSA AES 256 (AES256) SHA384
#9 Elliptic curve Diffie–Hellman (ECDH) Elliptic Curve Digital Signature Algorithm (ECDSA) AES 128 (AES128) SHA256
#10 Elliptic curve Diffie–Hellman (ECDH) RSA AES 128 (AES128) SHA256

This string provides the strongest encryption in modern browsers and TLS/SSL clients (AES in Galois/Counter Mode is only supported in TLS 1.2). Furthermore, this string also provides perfect forward secrecy (PFS) if both the server and the TLS/SSL client support it (on Apache HTTP Server you must set SSLSessionTickets to off).

How to Verify the Configuration

An easy way to test if your website or web application uses a vulnerable SSL/TLS configuration is to run an automated scan using the online Acunetix vulnerability scanner, which includes a network security scanner. At the same time, you can also test for web vulnerabilities. Take a demo and find out more about running scans against your website or web application.

Share this post
Ian Muscat

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.
  • Nice guide, may you have a look (and contribute) at
    https://bettercrypto.org/
    “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. 🙁

  • I know it has been a while since this article was published, but it is now best practice NOT to use 3DES.

  • For the Microsoft IIS, easiest way is running IISCrypto tool from Nartac Software which is a Free tool

  • RSA and AES algorithm is only good enough until the quantum era comes where we will be rendered ‘encryptionless’.

  • I have NGINX box and I want to use:
    ssl_protocols TLSv1.1 TLSv1.2;

    What would the ssl_ciphers be?

    Any help is greatly appreciated!

    • Hi Brian,

      As stated in the blog you ought to use the following ciphers:

      ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

  • Leave a Reply

    Your email address will not be published.