In the fall 2018, Transport Layer Security 1.3 was published as RFC 8446 by the Internet Engineering Task Force (IETF). TLS 1.3 is a major update from TLS 1.2 that simplifies and increases the security for encrypted traffic as compared to previous TLS versions. Some of the significant changes to the protocol were removing old, insecure and legacy encryption methods and removing unneeded steps in the initial handshake to allow for faster negotiation. In this post I will dive deeper into these changes.

What Is TLS?

First, if you are not familiar with TLS, it is the protocol used to encrypt traffic for many internet technologies. It is sometimes still called “SSL” (Secure Socket Layer), as that was the protocol used before TLS. SSL was the subject of multiple ongoing security issues and was deprecated as of June 2015. Now, TLS is used to encrypt web traffic, voice traffic and many other protocols used on a daily basis.

1. Simplified Protocol and the Removal of Old Encryption Ciphers

One of the goals for TLS 1.3 was to simplify the protocol and remove old and unneeded encryption ciphers and protocol messages. Earlier versions of TLS followed the strategy of leaving older ciphers in the protocol and pushing the responsibility to the administrator to disable them when they were deprecated or when vulnerabilities were identified. Many administrators were not disabling the legacy ciphers, leaving many systems with insecure configurations.

In 1.3, the IETF working group removed the Static RSA handshake, CBC Mode ciphers, RC4 cipher, SHA and MD5 algorithms, migrating the protocol to authenticated encryption with associated data (AEAD) ciphers. A lot of the ciphers that were removed have been part of various high-profile vulnerabilities in TLS 1.2 and earlier protocols. A handful of the named vulnerabilities are POODLE, DROWN and HeartBleed. The outcome of these changes is a hardened protocol that is simpler for administrators and teams writing software implementations, leading to fewer bugs and vulnerabilities.

2. Faster Negotiation

Another significant change between TLS 1.2 and 1.3 is a streamlining of the initial negotiation. In TLS 1.2, there were seven main steps in the negotiation that are reduced to five in TLS 1.3. The removal of these steps in the handshake was accomplished with two changes.

First, the initial hello request from the client now contains part of the encryption key. This consolidated message allows the server to reply with its part of the encryption key and remaining parameters in one encrypted message.

Second, the removal of the ChangeCipherSpec message (unless required for middlebox compatibility) removes further unneeded negotiation and contributes to the streamlining of the negotiation. These reductions in handshake overhead save a whole round trip and are a significant time savings on higher latency connections like wireless or transoceanic connections.

SOURCE: CloudFlare blog

3. Protections Against Passive Interception

The modifications discussed so far have added protections against passive monitoring of TLS 1.3 encrypted traffic. The removal of Static RSA handshake and Diffie-Hellman cipher suites has enabled protections for past sessions against future compromise; this is known as Perfect Forward Secrecy (PFS). It is no longer possible to copy or capture the encryption keys from a server and use them to decrypt traffic. Each connection now has a unique encryption key. Additionally, the server’s certificate is now encrypted in initial negotiation, protecting it from passive collection.

These changes are a challenge for some organizations that have relied on passive TLS decryption as part of their security operations. There are alternative methods for enterprises to protect employees from threats. Some of the tools that are available for administrators are active SSL proxies, Advanced Endpoint Protection systems and Cisco Encrypted Traffic Analysis.

More TLS 1.3 Resources

In this post, I have discussed what I consider the significant changes and impacts of TLS 1.3. There are many more changes described in the RFC document that are worth reviewing. Along with the RFC itself, there are many articles and resources published about TLS 1.3, some of my favorites are:

Overall, I’m a big proponent of TLS 1.3 and believe that all these changes I have described increase the safety and privacy of traffic on the internet.

Learn more about CDW’s security solutions and services.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.