Business & Technology
TLS 1.3 was released in August 2018, and it has some important ramifications for securing your critical data. But before we dive into the finer details, if you’re like most people, your initial response is, “what is TLS, and why does 1.3 matter?” The quick answer is, TLS stands for Transport Layer Security, and it is one of the building blocks of security on the internet. All of those secure web pages that you see beginning with https:// are based around TLS.
“Wait a minute, you can’t fool me,” you say. “The "s" in https stands for SSL!” Well, that ringing sound you are now hearing is the year 1994 on the phone calling for you. It wants to remind you that SSL—which stands for Secure Sockets Layer—was originally developed by Netscape back in 1994. It went through several versions (1.0, 2.0, and 3.0) and then when TLS 1.0 was released in 1999, it actually replaced SSL 3.0. (And by the way, that "s" in https stands for “Secure,” not SSL.)
TLS has gone through a number of versions: 1.0 (1999), 1.1 (2006), and 1.2 (2008). Development for 1.3 was started in 2014, and it took 28 drafts before it was approved in August of 2018. During that process, TLS 1.3 had to be redesigned because too many middleware security boxes were unable to handle TLS 1.3 very well, often breaking the connection. But now, one of the major TLS toolkits—OpenSSL—now has their first version available (1.1.1) that supports TLS 1.3.
So, what are the big changes in TLS 1.3? They fall into two big buckets – and both kinds of changes are highly beneficial to enterprise security. Let’s examine both in more detail.
First and most important, it does a much better job of addressing weak security. Of course, many of the previous improvements to SSL and TLS made over the years have also been to improve security, but in order to maintain compatibility with previous versions a lot of legacy stuff was also left in. And it was these items that provided an attack vector that allowed cybercriminals to bypass newer security in favor of older attacks—which is exactly how Logjam, FREAK, Lucky13, BEAST, and POODLE managed to succeed.
Some of the ciphers in previous versions were also weak cryptographically, making them vulnerable to a variety of exploits (RC4, CBC, SHA1, MD5, etc). In fact, some of those ciphers were so weak that they also couldn’t prevent recorded traffic from being decrypted later if someone had access to the private key (RSA static key).
Of course, TLS 1.2 enabled you to prioritize your cipher preferences to make sure the newer ciphers were preferred over the older ones, but not many people did that. And the default ordering of ciphers left many people unknowingly vulnerable. TLS 1.3 has finally resolved this issue by replacing those less secure ciphers with more modern and secure solutions. By not allowing you to even enable these ciphers, TLS 1.3 makes you more secure.
The second big change involves speeding up the TLS handshake. TLS encryption and decryption traditionally take a while to perform (especially when compared to not encrypting anything at all) because it requires extra CPU time and additional latency to perform TLS operations. Even a normal TLS 1.2 handshake consists of around 5-7 packets sent back and forth between the client and server, which creates a lot of unnecessary overhead. Even worse, each one of those packets moving back and forth also includes a certain amount of latency.
One caveat is that in TLS 1.2 the certificate exchanged between the client and server is unencrypted, while in TLS 1.3, the certificate is encrypted. What does this mean to network security devices? Well, if you’re doing legitimate passive decryption—which means you need a copy of the private key of the TLS server—and you’re trying to do that over a TLS 1.3 connection, then it won’t work. Unfortunately, the desire to achieve perfect forward secrecy means that legitimate passive decryption is not possible for TLS 1.3. The risk of illegitimate passive decryption is simply too high to continue to allow this type of decryption to occur, even when it is a legitimate request.
For devices that are performing legitimate Man In The Middle (MITM) activities, even if TLS 1.3 is not supported by the device, the most important thing to remember is to not break your TLS 1.3 connection if you have to back down to TLS 1.2—and unfortunately, many network devices that do not support TLS 1.3 will take this route. Fortunately, built into the TLS 1.3 protocol is a way for the client to know if this downgrade has occurred. The reason this is important is that as TLS 1.3 becomes more used, and attacks or weaknesses in TLS 1.2 become better known, backing down to TLS 1.2 will no longer be an option. Network devices must support TLS 1.3 or else they will not be able to legitimately inspect TLS 1.3 encrypted traffic.
Many of these devices doing MITM can instead use the certificate information seen in a non-encrypted portion of the TLS 1.2 handshake to make a decision about if they should actually intercept the session or not. With TLS 1.3 in place, if a device wants to look at the certificate it must intercept the session and decrypt it to see that information. And to do that, the network security device must fully support TLS 1.3.
According to a recent Google Transparency Report, 95% of traffic on Chrome for Windows was encrypted. This means that if you’re not inspecting encrypted traffic, then 95% of the traffic will pass through your next-generation firewall (NGFW) uninspected, leaving a large attack vector open.
What’s more, Fortinet’s Global Threat Landscape Report for Q3 indicated that over 20% of the top 20 unique exploits detected were using TLS-encrypted traffic to hide malicious code and exfiltrate data. In order to properly secure TLS traffic against threats, you need solutions capable of actively conducting full TLS inspection—a process that involves decrypting the data, examining it for potential threats, and then re-encrypting it so it can then be securely transmitted to the appropriate receiver.
Of course, for these benefits to work, your security solution needs to fully support TLS 1.3. Otherwise, not only will you remain vulnerable to a number of legacy exploits, but the accelerating demands of the digital marketplace means that you will have a hard decision to make between establishing and inspecting encrypted traffic at yesterday’s speeds, or leaving some data and transactions unprotected.
The good news for Fortinet customers is FortiOS 6.2 fully supports TLS 1.3 for effective and high-performance MITM inspection. Fortinet has been providing SSL/TLS inspection for many years via MITM. The latest version of FortiOS 6.0 not only fully supports TLS 1.2 MITM, but it also does not break TLS 1.3 when it has to negotiate down to TLS 1.2. In addition, Fortinet solutions contain custom security processors which enable the industry’s highest-performance SSL/TLS inspection. The results of this can be seen in the 2018 NSS labs Enterprise firewall test results on HTTPS traffic interception.
As digital transformation continues to place new demands on organizations to deliver faster and richer information and applications, security has to transform itself in lockstep. Otherwise, it is likely to become a bottleneck to innovation and will either impact the success of an organization or expose it to greater risk. TLS 1.3 is one of those security innovations that make digital business possible, and you owe it to yourself to not only learn about its implications but also ensure that the security tools you are using can fully support its requirements and can leverage its new functionalities and advantages.
Visit Fortinet’s FortiGate Next-Generation Firewall homepage to learn more about this advanced security solution.