Chapter 4. Planning and implementing TLS

The latest TLS version provides the best security. TLS 1.2 is the minimum version even when using the LEGACY cryptographic policy.

You can re-enable older protocol versions by opting out of cryptographic policies or providing a custom policy. The resulting configuration is not supported.

RHEL 10 supports TLS version 1.3. Not all features of this protocol are fully supported by RHEL 10 components. For example, Apache web server does not yet fully support the 0-RTT (Zero Round Trip Time) feature.

Prefer modern, secure cipher suites to old, insecure ones. Always disable eNULL and aNULL cipher suites. These offer no encryption or authentication.

Disable cipher suites based on RC4 or HMAC-MD5. These have serious shortcomings. Also disable export cipher suites. These have been intentionally weakened and are easy to break.

Cipher suites that offer less than 128 bits of security have a short useful life. Do not use them.

Algorithms that use 128 bits of security or more remain unbreakable for at least several years. Use these algorithms. Note that 3DES ciphers advertise 168 bits but actually offer 112 bits of security.

Always prefer cipher suites that support (perfect) forward secrecy (PFS). PFS ensures the confidentiality of encrypted data even when the server key is compromised.

This rules out the fast RSA key exchange. Use ECDHE or DHE instead. ECDHE is faster and the preferred choice.

Prefer AEAD ciphers such as AES-GCM over CBC-mode ciphers. AEAD ciphers are not vulnerable to padding oracle attacks.

AES-GCM is faster than AES in CBC mode in many cases. This is especially true when the hardware has cryptographic accelerators for AES.

ECDHE key exchange with ECDSA certificates is faster than pure RSA key exchange. You can install two pairs of certificates and keys on a server to support legacy clients. Use ECDSA keys for new clients and RSA keys for legacy ones.

When using RSA keys, prefer key lengths of at least 3072 bits signed by at least SHA-256. This is sufficiently large for true 128 bits of security.

The Apache HTTP Server is compatible with both OpenSSL and NSS libraries for handling TLS requirements. RHEL 10 includes packages for the mod_ssl functionality.

The mod_ssl package creates the /etc/httpd/conf.d/ssl.conf configuration file. You can use this file to modify the server’s TLS-related settings.

The httpd-manual package provides complete documentation for the Apache HTTP Server, including TLS configuration. The /usr/share/httpd/manual/mod/mod_ssl.html file describes directives available in /etc/httpd/conf.d/ssl.conf. The /usr/share/httpd/manual/ssl/ssl_howto.html file describes examples of various settings.

When modifying the /etc/httpd/conf.d/ssl.conf configuration file, consider these three directives:

To use only the TLS 1.2 and 1.3 protocols, add the following line to the configuration file:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

To enable TLS 1.3 support in Nginx, add the TLSv1.3 value to the ssl_protocols option in the server section of /etc/nginx/nginx.conf:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    …
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers
    …
}

To configure the Dovecot mail server to use TLS, modify the /etc/dovecot/conf.d/10-ssl.conf configuration file. The /usr/share/doc/dovecot/wiki/SSL.DovecotConfiguration.txt file explains basic configuration directives. The standard Dovecot installation installs this file.

When modifying /etc/dovecot/conf.d/10-ssl.conf, consider these three directives:

For example, the following line in /etc/dovecot/conf.d/10-ssl.conf allows only TLS 1.1 and later:

ssl_protocols = !SSLv2 !SSLv3 !TLSv1