3.7. Hardening TLS Configuration
Transport Layer Security) is a cryptographic protocol used to secure network communications. When hardening system security settings by configuring preferred key-exchange protocols, authentication methods, and encryption algorithms, it is necessary to bear in mind that the broader the range of supported clients, the lower the resulting security. Conversely, strict security settings lead to a limited compatibility with clients, which can result in some users being locked out of the system. Be sure to target the strictest available configuration and only relax it when it is required for compatibility reasons.
Note that the default settings provided by libraries included in Red Hat Enterprise Linux are secure enough for most deployments. The
TLSimplementations use secure algorithms where possible while not preventing connections from or to legacy clients or servers. Apply the hardened settings described in this section in environments with strict security requirements where legacy clients or servers that do not support secure algorithms or protocols are not expected or allowed to connect.
3.7.1. Choosing Algorithms to Enable
There are several components that need to be selected and configured. Each of the following directly influences the robustness of the resulting configuration (and, consequently, the level of support in clients) or the computational demands that the solution has on the system.
The latest version of
TLSprovides the best security mechanism. Unless you have a compelling reason to include support for older versions of
SSL), allow your systems to negotiate connections using only the latest version of
Do not allow negotiation using
SSLversion 2 or 3. Both of those versions have serious security vulnerabilities. Only allow negotiation using
TLSversion 1.0 or higher. The current version of
TLS, 1.2, should always be preferred.
Please note that currently, the security of all versions of
TLSdepends on the use of
TLSextensions, specific ciphers (see below), and other workarounds. All
TLSconnection peers need to implement secure renegotiation indication (RFC 5746), must not support compression, and must implement mitigating measures for timing attacks against
CBC-mode ciphers (the Lucky Thirteen attack).
TLS v1.0clients need to additionally implement record splitting (a workaround against the BEAST attack).
TLS v1.2supports Authenticated Encryption with Associated Data (AEAD) mode ciphers like
Camellia-GCM, which have no known issues. All the mentioned mitigations are implemented in cryptographic libraries included in Red Hat Enterprise Linux.
See Table 3.1, “Protocol Versions” for a quick overview of protocol versions and recommended usage.
Table 3.1. Protocol Versions
|Protocol Version||Usage Recommendation|
Do not use. Has serious security vulnerabilities.
Do not use. Has serious security vulnerabilities.
Use for interoperability purposes where needed. Has known issues that cannot be mitigated in a way that guarantees interoperability, and thus mitigations are not enabled by default. Does not support modern cipher suites.
Use for interoperability purposes where needed. Has no known issues but relies on protocol fixes that are included in all the
Recommended version. Supports the modern
Some components in Red Hat Enterprise Linux are configured to use
TLS v1.0even though they provide support for
TLS v1.1or even
v1.2. This is motivated by an attempt to achieve the highest level of interoperability with external services that may not support the latest versions of
TLS. Depending on your interoperability requirements, enable the highest available version of
SSL v3is not recommended for use. However, if, despite the fact that it is considered insecure and unsuitable for general use, you absolutely must leave
SSL v3enabled, see Section 3.6, “Using stunnel” for instructions on how to use stunnel to securely encrypt communications even when using services that do not support encryption or are only capable of using obsolete and insecure modes of encryption.
While not immediately insecure, cipher suites that offer less than 128 bits of security should not be considered for their short useful life. Algorithms that use 128 bit of security or more can be expected to be unbreakable for at least several years, and are thus strongly recommended. Note that while
3DESciphers advertise the use of 168 bits, they actually offer 112 bits of security.
Always give preference to cipher suites that support (perfect) forward secrecy (PFS), which ensures the confidentiality of encrypted data even in case the server key is compromised. This rules out the fast
RSAkey exchange, but allows for the use of
DHE. Of the two,
ECDHEis the faster and therefore the preferred choice.
Note also that when using the
ECDHEkey exchange with
ECDSAcertificates, the transaction is even faster than pure
RSAkey exchange. To provide support for legacy clients, you can install two pairs of certificates and keys on a server: one with
ECDSAkeys (for new clients) and one with
RSAkeys (for legacy ones).
Public Key Length
RSAkeys, always prefer key lengths of at least 3072 bits signed by at least SHA-256, which is sufficiently large for true 128 bits of security.
Keep in mind that the security of your system is only as strong as the weakest link in the chain. For example, a strong cipher alone does not guarantee good security. The keys and the certificates are just as important, as well as the hash functions and keys used by the Certification Authority (CA) to sign your keys.