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. Table 4.6. Protocol Versions 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: 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: 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: 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: 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: 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: 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: 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 (or SSL ) 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 on to ensure that the connecting clients adhere to the order of ciphers you specified. For example: 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 (or SSL ) 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 yes to ensure that the connecting clients adhere to the order of ciphers you specified. For example: 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.conf configuration 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.conf configuration 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.conf configuration 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.conf configuration 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 TLS and DTLS . See Also Section A.2.4, "SSL/TLS" provides a concise description of the SSL and TLS protocols. 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.

Commands:
~]USD openssl ciphers -v 'ALL:COMPLEMENTOFALL'
~]USD openssl ciphers -v 'HIGH'
~]USD 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
~]USD gnutls-cli -l
~]USD gnutls-cli --priority SECURE128 -l
~]USD 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
~]# yum install mod_ssl
SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite HIGH:!aNULL:!MD5 SSLHonorCipherOrder on
ssl_protocols = !SSLv2 !SSLv3 ssl_cipher_list = HIGH:!aNULL:!MD5 ssl_prefer_server_ciphers = yes