Which SSL/TLS Protocol Versions and Cipher Suites Should I Use?

SSL/TLS Protocol Versions

SSL/TLS libraries and applications using them allow the administrator to restrict the versions of SSL/TLS allowed, usually as part of the security hardening configuration. Five versions of SSL/TLS are widely supported in library code: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2. All of these versions are affected by at least one security issue requiring a workaround or special configuration to avoid, and the two earliest contain severe flaws that cannot be worked around without breaking compatibility. We briefly describe the history of the different versions of SSL/TLS and show how each can or cannot be securely used today when correctly configured.

Protocol	Action
SSL 2.0	Disable
SSL 3.0	Disable
TLS 1.0	Disable when possible
TLS 1.1	Enable
TLS 1.2	Enable

Recommended configuration for each version of SSL/TLS.

SSL 2.0 was released in 1995. It contains a number of cryptanalytic design flaws which cannot be worked around without breaking the protocol and could lead to the exposure or modification of confidential data. SSL 2.0 should never be used on the modern Internet. When encountered today, SSL 2.0 is usually enabled as a result of an accident or weak default configuration.

Result: Disable SSL 2.0 without regard to backward compatibility.

SSL 3.0 was released in 1996 as a full re-design. Google's POODLE attack leverages browser scripting capabilities and the broken padding implementation in SSL 3.0 to launch man-in-the-middle attacks, which could lead to the exposure or modification of confidential data [2]. Two workarounds could allow SSL 3.0 to remain in use while resolving POODLE:

1. Disable all CBC mode cipher suites when communicating with an SSL 3.0 client; stream ciphers do not use padding and are therefore not vulnerable. Unfortunately, the only non-CBC cipher widely supported, RC4, is susceptible to additional security issues of its own.
2. A new pseudo-cipher suite recently added to TLS, TLS_FALLBACK_SCSV, helps to detect downgrade attacks to resist an attacker's attempts to force a victim to downgrade to SSL 3.0 [3]. As of this writing (early 2015), TLS_FALLBACK_SCSV is not yet universally supported, and the clients that do support it are likely to support TLS 1.0 anyway.

For the reasons stated, we recommend disabling SSL 3.0 rather than relying on either of these workarounds.

Up until 2014 many public servers continued to support SSL 3.0 for backward compatibility, despite its supersession by TLS fifteen years beforehand. This trade-off is now unacceptable in light of the irreparable POODLE vulnerability. Disabling SSL 3.0 ensures that software cannot misconfigured to use it, and that attackers cannot force a client and server to downgrade to it.

Result: Disable SSL 3.0 without regard to backward compatibility.

TLS 1.0 was released in 1999 as a revision to SSL 3.0. Among the modifications to the protocol was a new padding scheme, and as a result TLS 1.0 is not vulnerable to the POODLE attack when TLS padding is in use.

However, TLS 1.0 is vulnerable to the BEAST attack, which leverages browser scripting capabilities and weaknesses in the use of initialization vectors employed when encrypting with a block cipher in CBC mode [4]. BEAST can be worked around without breaking the TLS 1.0 protocol in one of two ways:

1. Disable all CBC mode cipher suites; stream ciphers are not vulnerable. Unfortunately, the only non-CBC cipher widely supported, RC4, is susceptible to additional security issues of its own.
2. Modify TLS client and server libraries to add a "tweak" to the way in which the software communicates, called "insert empty fragments".

If TLS 1.0 must be supported, then we recommend ensuring that both the client and server follow the "insert empty fragments" workaround, rather than switching to RC4.

Many servers continue to support TLS 1.0 for backward compatibility, as some widely-deployed software does not support later versions of TLS (e.g., Windows XP, Windows Server 2003, OpenSSL 0.9.8), while other software, including Mozilla Firefox, did not implement TLS 1.1 until many years after its introduction in 2006. TLS 1.0 users who wish to use workarounds rather than discontinue support must be diligent in ensuring their TLS libraries are up to date and properly configured. We recommend that users instead upgrade unless a specific backward compatibility issue precludes disabling TLS 1.0.

Result: Disable TLS 1.0; re-enable if backward compatibility issues arise.

TLS 1.1 was released in 2006 as a revision to TLS 1.0. Among the modifications to the protocol is a new IV generation scheme; thus, TLS 1.1 is not susceptible to BEAST.

While attacks have been successfully launched against specific TLS 1.1 features, such as compression (CRIME) and renegotiation, workarounds exist that do not break protocol compatibility. Note: these issues affect TLS 1.2 as well.

TLS 1.1 users should be diligent in ensuring their TLS libraries are up to date and properly configured to enable security workarounds according to current best practices (e.g., disabling compression, and enabling the RFC 5746 renegotiation workaround).

Result: Enable TLS 1.1.

TLS 1.2 was released in 2008 as a revision to TLS 1.1. As of this writing, it is unnecessary to upgrade from TLS 1.1 to 1.2 in response to any known, exploitable vulnerabilities, but TLS 1.2 introduces useful features such as higher-performance GCM cipher suites and a SHA-256 based pseudorandom function. GCM cipher suites also use provide authenticated encryption, replacing TLS’s traditional Encrypt-then-Authenticate scheme.

TLS 1.2 users should be diligent in ensuring their TLS libraries are up to date and properly configured to enable security workarounds according to current best practices (e.g., disabling compression, and enabling the RFC 5746 renegotiation workaround).

Result: Enable TLS 1.2.

Cipher Suites

The SSL/TLS protocols were designed to be extensible and modular, allowing the server/client authentication, key exchange, encryption, and message integrity (MAC) protocols to be changed without replacing the entire protocol. The most recent cipher suites use RSA, ECDH, or ECDSA for authentication, ECDHE for key exchange, AES for encryption, and GCM for integrity, but a large number of older and backward-compatibility cipher suites also exist. We split the cipher suites into three categories: those that should always be enabled for the best security possible, those that can be enabled if desired for compability, and those that should always be disabled due to security weaknesses.

Recommended Cipher Suites

Administrators should be sure to enable the following cipher suites.

ECDH/DH AES cipher suites. These newer cipher suites use Elliptic-Curve Diffie Hellman (ECDH) and Diffie-Hellman (DH) for key exchange. Unlike older cipher suites that use static RSA based on the server's public key for this purpose, passively-captured ECDH/DH traffic cannot be decrypted, even if the server's private key is compromised later. This feature is known as forward secrecy.

AES cipher suites. Plain AES cipher suites are used by clients that do not support ECDH/DH cipher suites, or have them disabled.

A quick way to specify only AES-based cipher suites while requiring RSA, ECDH, or ECDSA certificates for server authentication, when using OpenSSL, is: AES+aRSA:AES+aECDH:AES+aECDSA. Modern x86 processors support hardware-accelerated AES and AES/GCM encryption. This capability allows AES cipher suites to provide both high performance and robust security.

Optional or Uncommon Cipher Suites

SSL/TLS libraries commonly support many other ciphers and authentication schemes, such as the Camellia, Triple-DES, and SEED cipher suites; and the Kerberos, preshared key, and DSS authentication schemes. While as of this writing, there are currently no known attacks against these algorithms, they can generally be disabled without any compatibility consequences. Disabling unnecessary features in security-critical libraries also helps to reduce the attack surface.

Weak or Broken Cipher Suites

The following types of cipher suites are weak or broken and should always be disabled.

Null cipher. The NULL cipher (eNULL) does not perform any encryption and should only be used for testing or debugging.

Export grade ciphers. These obsolete cipher suites were used when US export restrictions limited cryptographic strength to 40 bits (later 56). Most of the relevant restrictions were lifted in 2000, so these are unnecessary for all current software and are too weak against brute-force attacks.

Anonymous ciphers. While SSL/TLS almost always uses certificates to prove a server's identity, this is not required when using an anonymous cipher suite (usually disabled by default at the application layer, e.g., mod_ssl or IIS).

MD5-based cipher suites. Many older cipher suites used a MAC algorithm based on MD5 to detect modifications to the encrypted data. The MD5 algorithm has been shown to be weak and susceptible to collisions; also, some MD5 cipher suites make use of ciphers with known weaknesses, such as RC2, and these are automatically disabled by avoiding MD5.

RC4 cipher suites. The RC4 cipher's key scheduling algorithm is weak in that early bytes of output can be correlated with the key. This weakness was used in certain attacks against Wired Equivalent Privacy (WEP), the first encryption standard for 802.11 Wi-Fi networks, with catastrophic results. While SSL/TLS is not vulnerable to or exploitable by the same techniques as WEP, the underlying weakness in RC4 nonetheless exists, and security researchers at Microsoft and other companies now recommend that it be disabled [5].

This advice may be surprising to many IT professionals, as one of the immediate recommendations to the BEAST vulnerability just a few years ago was to disable all ciphers except RC4. However, current best practices state that RC4 itself should be disabled.