Return to Security and Privacy

TLS 1.3

There is a new standard on the Internet for secure communications called the Transport Layer Security Protocol Version 1.3, or for short, TLS 1.3. What is this about? Well, back in the old days we had something called SSL which was developed by Netscape in 1995. This was a way to establish encrypted communication with a web site using a certificate, but the important thing is that SSL and TLS are the protocols, and you can use certificates with either of them. But in the ongoing arms race that is cryptography the older SSL started to show vulnerabilities, such as the POODLE protocol downgrade attack, that led to SSL being deprecated. SSL 2.0 was deprecated in 2011, and SSL 3.0 in 2015. The replacement for SSL is TLS, which continues the improvement necessary in any arms race.

This required 4 years of meetings and 28 drafts, but in the end the final draft was passed by the Internet Engineering Task Force (IETF) with nearly unanimous support.  But as you might infer from the 28 drafts, there were issues to work through before this could be adopted. since this protocol governs the handshake process between your browser and the remote web server, all browsers and web servers had to be modified to employ the new process. This did not always go smoothly, and a good example is the Middlebox Problem.

The Middlebox Problem

A middlebox is any piece of hardware that inserts itself between the browser and the remote web server. A good example is a firewall, which of necessity sits in the middle and inspects all traffic to protect the network from malicious traffic. At the very least, such hardware will need to receive updates to employ the new protocol, which will cost money and effort. In contrast, upgrading browsers was fairly simple and is already done. This caused a bit of bother for a school system that had 50,000 Chromebooks and found that many of them could no longer connect to the network after an upgrade to Chrome conflicted with the network security software from Symantec Blue Coat. This led Google to temporarily pause its rollout, even though they say Symantec was the one at fault here. But the biggest battle pitted IETF against the Financial Services Roundatable. The Roundtable suggested that a weakenening of the standard would be really convenient since it would save them from the bother and expense of modifying their systems. They wanted an option to decrypt any traffic. This did not sit well with the IETF:

“The bank industry is pushing the TLS working group to create a decryption option as part of the specification, and of course the tech sector is saying ‘That’s not going to happen,’ ” Janet Jones, a Microsoft senior security program manager, told CyberScoop. “Can you imagine us supporting something that gave an API with a decrypt button? We can’t do that.”

Unfortunately for the banks, they were not paying attention earlier in the process, and made their objection as the IETF was wrapping up their work. As Kenny Patterson put it:

Hi Andrew,

My view concerning your request: no.

Rationale: We’re trying to build a more secure internet.

Meta-level comment:

You’re a bit late to the party. We’re metaphorically speaking at the stage of emptying the ash trays and hunting for the not quite empty beer cans.

More exactly, we are at draft 15 and RSA key transport disappeared from the spec about a dozen drafts ago. I know the banking industry is usually a bit slow off the mark, but this takes the biscuit.



The tech industry regarded this proposal from the big banks as essentially building in a backdoor, and pointed out that there are ways to accomplish what the banks want to do without weakening the TLS 1.3 standard. For instance, anyone with traffic going through their network can use middleboxes to do “man-in-the-middle” decryption. This works by having the middlebox create two encrypted tunnels, one to the browser, the other to the remote web site, and then they can decrypt and inspect traffic all they want. So, in the end the IETF voted to not adopt what the banks wanted, and TLS 1.3 won’t have this particular back door.


TLS 1.3 improves the efficiency and speed of connections, thus reducing latency, by streamlining the handshake. In TLS 1.2 there is a handshake process that is fairly complex. It involves:

  1. The web browser (client) sends a message to the server and offers a list of encryption protocols it can support.
  2. The server then replies with the protocol it intends to use and sends an encryption key
  3. The client then uses that key to send back a random string, and they then create two keys: a master key and a weaker session key
  4. The client then says which protocol it will use for the weaker session key. Because this key is weaker, it is faster and less resource-intensive.
  5. The server acknowledges the session key and protocol
  6. They finally start exchanging information, which was the whole point.

TLS 1.3 creates much simpler handshake:

  1. The client says hello, and says which protocols it intends to use.
  2. The server says “Cool! Here’s my key”
  3. The client says “Awesome! Here’s the session key”

So as you can clearly see the handshake is markedly simpler to accomplish.

Improved Security

Of course the main point is improving the security. One of the first things to take note of is that TLS 1.3 removes support for many older encryption protocols that have known vulnerabilities. And it improves the resistance to downgrade attacks. A downgrade attack happens whenever one of the parties in the handshake claims to not have any good protocols available and asks to use a weaker, more vulnerable protocol. This first surfaced with SSL 3.0, and the move to TLS reduced that threat by improving resistance, but the bad guys are always looking for opportunities, so periodically you need to upgrade your defenses. TLS 1.3 does this not only by eliminating support for many of those weaker protocols, but also by detecting and flagging attempts to downgrade to TLS 1.2.

Another major change is the move away from RSA for the handshake (see above reference to RSA Key Transport) to Ephemeral Diffie-Hellman (DHE). The reason is that the server’s RSA key tends to be fixed, for at least a significant period of time, which means that any compromise of that key could lead to decryption of previously stored communications. In the new protocol, the RSA key is only used for authentication. The actual encryption keys are generated anew each session using Diffie-Hellman.  This is an example of Forward Secrecy, which we discussed here.

Improved security is not perfect security, however. The nature of the cryptographic arms race is such that every improvement in defense is met by an improvement in offense. And it is still possible to have a “man-in-the-middle” attack if you are not careful about managing your authentication.  TLS 1.3 attempts to reduce this vulnerability by hashing session parameters, but even as TLS 1.3 was adopted a new possible attack was discovered.

Another potential issue concerns 0-RTT Resumption. This essentially allows the client and server to remember the connection and resume it. As you might expect, this introduces a vulnerability while attempting to make things easier for users.


This will not happen overnight. While browsers have easily moved to the new protocol, it is a different matter for servers. for example, the 0-RTT Resumption process requires changes that are not compatible with older servers. And the move to Ephemeral Diffie-Hellman also poses problems for data centers. Network monitoring tools such as Intrusion Detection Systems that passively monitor TLS connections cannot, at present, work with ephemeral ciphersuites. This was one of the issues behind the objections made by the big banks.

Listen to the audio version of this post on Hacker Public Radio!

 Save as PDF