SBN

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, 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

Apart from being a requirement in several regulatory standards, with major browsers marking sites as “not secure” in absence of TLS, it may also be considered a requirement for serving websites and web applications. Getting TLS implementations right however, may prove to be a little less straightforward than expected. Worst still, bad TLS configurations may provide a false sense of security, while rendering websites and web applications vulnerable to an array of attacks.

Many common TLS misconfigurations lie in the poor choice of cipher suites. Old or outdated cipher suites, especially those that suffer from different kinds of attacks, may allow an attackers to successfully intercept or tamper with 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 retrieved an 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 outlined later on.

Disabling TLS 1.0 and 1.1

Unless there is a need to support legacy browsers, TLS 1.0 and 1.1 should also be disabled. PCI DSS specifies that TLS 1.0 may no longer be used as of the 30th of June 2018, and also strongly suggests disabling TLS 1.1; since these protocols may be affected by vulnerabilities such as FREAK, POODLE, BEAST and CRIME.

Unless there is a need to support legacy browsers, TLS 1.0 and 1.1 should also be disabled. PCI DSS specifies that TLS 1.0 may no longer be used as of the 30th of June 2018, and also strongly suggests disabling TLS. If it is a business requirement to still support TLS 1.0, 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. 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. It is also worth noting that the use of the RC4 bulk cipher is also prohibited by PCI DSS.

The following user agents (and their older versions) will likely be affected by disabling TLS 1.0 and 1.1 (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

Configuration

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

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)

Depending on the web server in question (e.g. Apache HTTP Server, Nginx…), the syntax of enabling/disabling TLS protocols and supported TLS cipher suites will vary slightly.

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

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

The 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, the string also provides Perfect Forward Secrecy if both the server and the TLS/SSL client have support for it (SSLSessionTickets must be set to off for this to work in Apache HTTP Server).

*** This is a Security Bloggers Network syndicated blog from Web Security Blog – Acunetix authored by Ian Muscat. Read the original post at: http://feedproxy.google.com/~r/acunetixwebapplicationsecurityblog/~3/pdZAemdM4qM/