4.13. 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 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 7 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.
4.13.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 1.0 clients need to additionally implement record splitting (a workaround against the BEAST attack). TLS 1.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 4.6, “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 1.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 1.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 1.2 |
Recommended version. Supports the modern
AEAD cipher suites.
|
Some components in Red Hat Enterprise Linux are configured to use
TLS 1.0 even though they provide support for TLS 1.1 or even 1.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 4.8, “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.
Cipher Suites
Modern, more secure cipher suites should be preferred to old, insecure ones. Always disable the use of eNULL and aNULL cipher suites, which do not offer any encryption or authentication at all. If at all possible, ciphers suites based on
RC4 or HMAC-MD5, which have serious shortcomings, should also be disabled. The same applies to the so-called export cipher suites, which have been intentionally made weaker, and thus are easy to break.
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.
You should also give preference to
AEAD ciphers, such as AES-GCM, before CBC-mode ciphers as they are not vulnerable to padding oracle attacks. Additionally, in many cases, AES-GCM is faster than AES in CBC mode, especially when the hardware has cryptographic accelerators for AES.
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.
4.13.2. Using Implementations of TLS
Red Hat Enterprise Linux 7 is distributed with several full-featured implementations of
TLS. In this section, the configuration of OpenSSL and GnuTLS is described. See Section 4.13.3, “Configuring Specific Applications” for instructions on how to configure TLS support in individual applications.
The available
TLS implementations offer support for various cipher suites that define all the elements that come together when establishing and using TLS-secured communications.
Use the tools included with the different implementations to list and specify cipher suites that provide the best possible security for your use case while considering the recommendations outlined in Section 4.13.1, “Choosing Algorithms to Enable”. The resulting cipher suites can then be used to configure the way individual applications negotiate and secure connections.
Important
Be sure to check your settings following every update or upgrade of the
TLS implementation you use or the applications that utilize that implementation. New versions may introduce new cipher suites that you do not want to have enabled and that your current configuration does not disable.
4.13.2.1. Working with Cipher Suites in OpenSSL
OpenSSL is a toolkit and a cryptography library that support the
SSL and TLS protocols. On Red Hat Enterprise Linux 7, a configuration file is provided at /etc/pki/tls/openssl.cnf. The format of this configuration file is described in config(1). See also Section 4.7.9, “Configuring OpenSSL”.
To get a list of all cipher suites supported by your installation of OpenSSL, use the
openssl command with the ciphers subcommand as follows:
~]$ openssl ciphers -v 'ALL:COMPLEMENTOFALL'
Pass other parameters (referred to as cipher strings and keywords in OpenSSL documentation) to the
ciphers subcommand to narrow the output. Special keywords can be used to only list suites that satisfy a certain condition. For example, to only list suites that are defined as belonging to the HIGH group, use the following command:
~]$ openssl ciphers -v 'HIGH'
See the ciphers(1) manual page for a list of available keywords and cipher strings.
To obtain a list of cipher suites that satisfy the recommendations outlined in Section 4.13.1, “Choosing Algorithms to Enable”, use a command similar to the following:
~]$ openssl ciphers -v 'kEECDH+aECDSA+AES:kEECDH+AES+aRSA:kEDH+aRSA+AES' | column -t
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
The above command omits all insecure ciphers, gives preference to
ephemeral elliptic curve Diffie-Hellman key exchange and ECDSA ciphers, and omits RSA key exchange (thus ensuring perfect forward secrecy).
Note that this is a rather strict configuration, and it might be necessary to relax the conditions in real-world scenarios to allow for a compatibility with a broader range of clients.
4.13.2.2. Working with Cipher Suites in GnuTLS
GnuTLS is a communications library that implements the
SSL and TLS protocols and related technologies.
Note
The GnuTLS installation on Red Hat Enterprise Linux 7 offers optimal default configuration values that provide sufficient security for the majority of use cases. Unless you need to satisfy special security requirements, it is recommended to use the supplied defaults.
Use the
gnutls-cli command with the -l (or --list) option to list all supported cipher suites:
~]$ gnutls-cli -l
To narrow the list of cipher suites displayed by the
-l option, pass one or more parameters (referred to as priority strings and keywords in GnuTLS documentation) to the --priority option. See the GnuTLS documentation at http://www.gnutls.org/manual/gnutls.html#Priority-Strings for a list of all available priority strings. For example, issue the following command to get a list of cipher suites that offer at least 128 bits of security:
~]$ gnutls-cli --priority SECURE128 -l
To obtain a list of cipher suites that satisfy the recommendations outlined in Section 4.13.1, “Choosing Algorithms to Enable”, use a command similar to the following:
~]$ gnutls-cli --priority SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC -l
Cipher suites for SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 0xc0, 0x2c TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA384 0xc0, 0x24 TLS1.2
TLS_ECDHE_ECDSA_AES_256_CBC_SHA1 0xc0, 0x0a SSL3.0
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256 0xc0, 0x2b TLS1.2
TLS_ECDHE_ECDSA_AES_128_CBC_SHA256 0xc0, 0x23 TLS1.2
TLS_ECDHE_ECDSA_AES_128_CBC_SHA1 0xc0, 0x09 SSL3.0
TLS_ECDHE_RSA_AES_256_GCM_SHA384 0xc0, 0x30 TLS1.2
TLS_ECDHE_RSA_AES_256_CBC_SHA1 0xc0, 0x14 SSL3.0
TLS_ECDHE_RSA_AES_128_GCM_SHA256 0xc0, 0x2f TLS1.2
TLS_ECDHE_RSA_AES_128_CBC_SHA256 0xc0, 0x27 TLS1.2
TLS_ECDHE_RSA_AES_128_CBC_SHA1 0xc0, 0x13 SSL3.0
TLS_DHE_RSA_AES_256_CBC_SHA256 0x00, 0x6b TLS1.2
TLS_DHE_RSA_AES_256_CBC_SHA1 0x00, 0x39 SSL3.0
TLS_DHE_RSA_AES_128_GCM_SHA256 0x00, 0x9e TLS1.2
TLS_DHE_RSA_AES_128_CBC_SHA256 0x00, 0x67 TLS1.2
TLS_DHE_RSA_AES_128_CBC_SHA1 0x00, 0x33 SSL3.0
Certificate types: CTYPE-X.509
Protocols: VERS-TLS1.2
Compression: COMP-NULL
Elliptic curves: CURVE-SECP384R1, CURVE-SECP521R1, CURVE-SECP256R1
PK-signatures: SIGN-RSA-SHA384, SIGN-ECDSA-SHA384, SIGN-RSA-SHA512, SIGN-ECDSA-SHA512, SIGN-RSA-SHA256, SIGN-DSA-SHA256, SIGN-ECDSA-SHA256
The above command limits the output to ciphers with at least 128 bits of security while giving preference to the stronger ones. It also forbids
RSA key exchange and DSS authentication.
Note that this is a rather strict configuration, and it might be necessary to relax the conditions in real-world scenarios to allow for a compatibility with a broader range of clients.
4.13.3. Configuring Specific Applications
Different applications provide their own configuration mechanisms for
TLS. This section describes the TLS-related configuration files employed by the most commonly used server applications and offers examples of typical configurations.
Regardless of the configuration you choose to use, always make sure to mandate that your server application enforces server-side cipher order, so that the cipher suite to be used is determined by the order you configure.
4.13.3.1. Configuring the Apache HTTP Server
The Apache HTTP Server can use both OpenSSL and NSS libraries for its
TLS needs. Depending on your choice of the TLS library, you need to install either the mod_ssl or the mod_nss module (provided by eponymous packages). For example, to install the package that provides the OpenSSL mod_ssl module, issue the following command as root:
~]# yum install mod_ssl
The mod_ssl package installs the
/etc/httpd/conf.d/ssl.conf configuration file, which can be used to modify the TLS-related settings of the Apache HTTP Server. Similarly, the mod_nss package installs the /etc/httpd/conf.d/nss.conf configuration file.
Install the httpd-manual package to obtain complete documentation for the Apache HTTP Server, including
TLS configuration. The directives available in the /etc/httpd/conf.d/ssl.conf configuration file are described in detail in /usr/share/httpd/manual/mod/mod_ssl.html. Examples of various settings are in /usr/share/httpd/manual/ssl/ssl_howto.html.
When modifying the settings in the
/etc/httpd/conf.d/ssl.conf configuration file, be sure to consider the following three directives at the minimum:
-
SSLProtocol - Use this directive to specify the version of
TLS(orSSL) you want to allow. -
SSLCipherSuite - Use this directive to specify your preferred cipher suite or disable the ones you want to disallow.
-
SSLHonorCipherOrder - Uncomment and set this directive to
onto ensure that the connecting clients adhere to the order of ciphers you specified.
For example:
SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite HIGH:!aNULL:!MD5 SSLHonorCipherOrder on
Note that the above configuration is the bare minimum, and it can be hardened significantly by following the recommendations outlined in Section 4.13.1, “Choosing Algorithms to Enable”.
To configure and use the mod_nss module, modify the
/etc/httpd/conf.d/nss.conf configuration file. The mod_nss module is derived from mod_ssl, and as such it shares many features with it, not least the structure of the configuration file, and the directives that are available. Note that the mod_nss directives have a prefix of NSS instead of SSL. See https://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html for an overview of information about mod_nss, including a list of mod_ssl configuration directives that are not applicable to mod_nss.
4.13.3.2. Configuring the Dovecot Mail Server
To configure your installation of the Dovecot mail server to use
TLS, modify the /etc/dovecot/conf.d/10-ssl.conf configuration file. You can find an explanation of some of the basic configuration directives available in that file in /usr/share/doc/dovecot-2.2.10/wiki/SSL.DovecotConfiguration.txt (this help file is installed along with the standard installation of Dovecot).
When modifying the settings in the
/etc/dovecot/conf.d/10-ssl.conf configuration file, be sure to consider the following three directives at the minimum:
-
ssl_protocols - Use this directive to specify the version of
TLS(orSSL) you want to allow. -
ssl_cipher_list - Use this directive to specify your preferred cipher suites or disable the ones you want to disallow.
-
ssl_prefer_server_ciphers - Uncomment and set this directive to
yesto ensure that the connecting clients adhere to the order of ciphers you specified.
For example:
ssl_protocols = !SSLv2 !SSLv3 ssl_cipher_list = HIGH:!aNULL:!MD5 ssl_prefer_server_ciphers = yes
Note that the above configuration is the bare minimum, and it can be hardened significantly by following the recommendations outlined in Section 4.13.1, “Choosing Algorithms to Enable”.
4.13.4. Additional Information
For more information about TLS configuration and related topics, see the resources listed below.
Installed Documentation
- config(1) — Describes the format of the
/etc/ssl/openssl.confconfiguration file. - ciphers(1) — Includes a list of available OpenSSL keywords and cipher strings.
/usr/share/httpd/manual/mod/mod_ssl.html— Contains detailed descriptions of the directives available in the/etc/httpd/conf.d/ssl.confconfiguration file used by the mod_ssl module for the Apache HTTP Server./usr/share/httpd/manual/ssl/ssl_howto.html— Contains practical examples of real-world settings in the/etc/httpd/conf.d/ssl.confconfiguration file used by the mod_ssl module for the Apache HTTP Server./usr/share/doc/dovecot-2.2.10/wiki/SSL.DovecotConfiguration.txt— Explains some of the basic configuration directives available in the/etc/dovecot/conf.d/10-ssl.confconfiguration file used by the Dovecot mail server.
Online Documentation
- Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide — The SELinux User's and Administrator's Guide for Red Hat Enterprise Linux 7 describes the basic principles of SELinux and documents in detail how to configure and use SELinux with various services, such as the Apache HTTP Server.
- http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-00 — Recommendations for secure use of
TLSandDTLS.
See Also
- Section 4.7, “Using OpenSSL” describes, among other things, how to use OpenSSL to create and manage keys, generate certificates, and encrypt and decrypt files.
