이 콘텐츠는 선택한 언어로 제공되지 않습니다.
3.7. Hardening TLS Configuration
TLS (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
TLS implementations 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.
Protocol Versions
The latest version of
TLS provides the best security mechanism. Unless you have a compelling reason to include support for older versions of TLS (or even SSL), allow your systems to negotiate connections using only the latest version of TLS.
Do not allow negotiation using
SSL version 2 or 3. Both of those versions have serious security vulnerabilities. Only allow negotiation using TLS version 1.0 or higher. The current version of TLS, 1.2, should always be preferred.
Note
Please note that currently, the security of all versions of
TLS depends on the use of TLS extensions, specific ciphers (see below), and other workarounds. All TLS connection 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.0 clients need to additionally implement record splitting (a workaround against the BEAST attack). TLS v1.2 supports Authenticated Encryption with Associated Data (AEAD) mode ciphers like AES-GCM, AES-CCM, or 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.
| Protocol Version | Usage Recommendation |
|---|---|
SSL v2 |
Do not use. Has serious security vulnerabilities.
|
SSL v3 |
Do not use. Has serious security vulnerabilities.
|
TLS v1.0 |
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.
|
TLS v1.1 |
Use for interoperability purposes where needed. Has no known issues but relies on protocol fixes that are included in all the
TLS implementations in Red Hat Enterprise Linux. Does not support modern cipher suites.
|
TLS v1.2 |
Recommended version. Supports the modern
AEAD cipher suites.
|
Some components in Red Hat Enterprise Linux are configured to use
TLS v1.0 even though they provide support for TLS v1.1 or 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 TLS.
Important
SSL v3 is not recommended for use. However, if, despite the fact that it is considered insecure and unsuitable for general use, you absolutely must leave SSL v3 enabled, 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
3DES ciphers 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
RSA key exchange, but allows for the use of ECDHE and DHE. Of the two, ECDHE is the faster and therefore the preferred choice.
Note also that when using the
ECDHE key exchange with ECDSA certificates, the transaction is even faster than pure RSA key exchange. To provide support for legacy clients, you can install two pairs of certificates and keys on a server: one with ECDSA keys (for new clients) and one with RSA keys (for legacy ones).
Public Key Length
When using
RSA keys, 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.
Warning
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.
