Transport Layer Security (TLS) provides the foundation for encryption in-flight. The first version of TLS, 1.0, replaced Secure Sockets Layer (SSL) in 1999. The latest version, 1.3, was finalized as a proposed standard in RFC 8446 in December of 2018. With it, comes enhancements in both speed and security.
One of the biggest differences between TLS 1.2 and TLS 1.3 is that perfect forward secrecy (PFS) is no longer a decision made at the cipher level. TLS 1.3 by definition implements PFS. PFS uses a constantly rotating key so that even in the event of a private key compromise, communication cannot be decrypted by a third party. To do this, TLS 1.3 drops support for an unprecedented number of legacy ciphers and encryption options including RC4 ciphers, SHA1, and MD5. It also completely drops support for TLS renegotiation (which defines what happens when the client or server try to send data after the other side thinks the session is expired). This secondary negotiation mechanism was frequently abused over the years. TLS 1.3 does this by removing the need for renegotiation entirely by removing an entire round trip from the initial negotiation.
TLS 1.3 is a huge step forward. Very reasonably, you might be asking how to take advantage of this bleeding edge technology.
TLS 1.3 in NGINX
NGINX has had support for TLS 1.3 since version 1.14.0. NGINX relies on OpenSSL for certain cryptographic functions, and will have to have been built against OpenSSL 1.1.1 or later in order to take advantage of TLS 1.3.
In a text editor, simply open your nginx.conf file (usually located at /etc/nginx.conf or /etc/nginx/nginx.conf) and add TLSv1.3 to the ssl_protocols directive.
For example:
ssl_protocols TLSv1.2 TLSv1.3
TLS 1.3 in Apache on RPM based Linux Distributions
In Red Hat/ CentOS 7 and above, the httpd package 2.4.38 and above support TLS 1.3. It is compiled against OpenSSL 1.1.1a by default. In your httpd.conf file , simply add SSLProtocol TLSv1.3 to the SSLProtocol directive.
For example:
SSLProtocol all -SSLv3 -TLSv1, -TLSv1.1
TLS 1.3 in Apache on Debian Based Linux Distributions
Debian 10 (Codename Buster) will be released with TLS 1.3 support out of the box for Apache Webserver. Ubuntu 19.04 comes with a version of Apache in its repositories that supports TLS 1.3 out of the box. The configuration directive is the same as above.
TLS 1.3 in IIS on Windows Server
Even on Server 2019, IIS does not support TLS 1.3 at this time. Microsoft is often slow to support proposed standards of the IETF, even though current IETF guidance considers a proposed standard as a stable protocol. Consider using a reverse proxy to take advantage of the benefits TLS 1.3 provides.
TLS 1.3 Client-Side Support
TLS must be supported by both the client and the server for it to be used. Chrome has supported TLS 1.3 since version 63, and Firefox since 61. Internet Explorer does not support TLS 1.3, and has been referred to as a “compatibility solution” by Microsoft. Edge, Microsoft’s latest offering, also does not currently support TLS 1.3, but plans to in a future release.
How to check if you’re successfully using TLS 1.3
To verify your site supports TLS 1.3 after the configuration changes above, you can use the SSL Test by Qualys to scan your server at www.ssllabs.com/ssltest. The results for an optimally configured server look like the figure below.
What about Proxies?
When TLS 1.3 was released, many Administrators were concerned that TLS 1.3 would break the ability to proxy connections for compliance related reasons. It turns out that many vendor’s implementations were written to support TLS 1.2 (and will need to be rewritten to support TLS 1.3), but there is nothing inherent about TLS 1.3 that prevents vendors from doing so.
And Packet Captures?
Many times, Administrators need to take a packet capture in order to figure out why something on their network isn’t behaving in a way they might expect. The introduction of PFS across the board poses an interesting problem. When using PFS, an algorithm called Diffie-Helman is used to constantly rotate the symmetric key each side agrees to use for communication after the initial handshake. (Without PFS this key remains static, and Wireshark uses the server’s private key onto to decrypt the first part of the communication in order to derive the symmetric key). With PFS enabled, Wireshark would need access to something called the “master key” which is only stored in memory (never written to disk) on the server. Barring extracting this key from RAM and providing it to a program like Wireshark, another option is to fall back to TLS 1.2 only when taking a packet capture. This can be done by simply disabling TLS 1.3 in your client application (such as a web browser). Even though this is inconvenient, it means that PFS is doing its job!