WHICH SSL/TLS PROTOCOL VERSIONS AND CIPHER SUITES

SHOULD I USE?
Our customers develop and deploy products that rely SSL/TLS to protect the
confidentiality and integrity of Web, VPN, e-mail, and other traffic. We are often asked
how to configure SSL/TLS libraries on servers to avoid any known security
vulnerabilities, specifically, regarding which protocol versions and cipher suites should be
enabled. In this post we list new features introduced in and vulnerabilities resolved by
each new version of SSL/TLS, and describe how to select the most secure cipher suites
while maintaining backward compatibility. Certain SSL/TLS versions and cipher suites
were recommended or enabled by default in the past for backward compatibility and
even security reasons; here, we hope to clarify current best practices.

Two configuration parameters are critical when hardening an SSL/TLS-based service:

the allowed SSL/TLS versions, and the allowed cipher suites. These parameters should
be set according to best practices, but these are not always clear; plus, in the constantly
evolving world of security, yesterdays best recommendation for resolving one security
issue can become todays vulnerable configuration. In this post, we briefly review the
history of the different versions of SSL and TLS, describe the most secure and modern
cipher suites available, and provide our recommendations for both configuration settings.
Don't forget to configure and update load balancers, reverse proxies, embedded devices,
appliances, or other SSL/TLS servers as well as traditional servers. For example, due to
a padding implementation bug, unpatched F5 and A10 devices are vulnerable to
POODLE even when TLS is used [1].

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 widelydeployed 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 TLSs 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 backwardcompatibility 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.

Future

TLS 1.3 is, as of this writing, currently under development and makes more substantial
changes to the protocol than previous revisions; in fact, it is the most significant revision
to the protocol since SSL 3.0. In a reversal from previous practice, many weak or
backward-compatibility features, such as RC4, compression, and static RSA
authentication, are proposed to be dropped from TLS 1.3. As TLS 1.3 is deployed,
administrators should implement support when possible. In particular, as clients and
servers migrate to TLS 1.3, many workarounds and hardening steps will no longer be
necessary.