Why TLS 1.3 is a Huge Improvement

TLS 1.3 is still pretty darn new. It was defined in RFC 8446 as recently as August 2018. Major web browsers such as Mozilla Firefox and Google Chrome have supported TLS 1.3 in some extent or another since 2017, and as 2018 comes to a close all major web browsers should support the new technology completely. Keep your web browsers and web servers updated, folks! 

Okay, so let’s run through why TLS 1.3 is a huge improvement over previous TLS and SSL standards. 

TLS 1.3 doesn’t use RSA key exchanges. Let me tell you why that’s a good thing.  

Exchanging keys is absolutely necessary to the process of encrypting data in transit. Cyber attackers will sometimes try to grab decryption keys because that’s often easier than trying to crack a cipher. The server needs their keys, the intended endpoint client recipient needs their keys, and both parties need to make sure that malicious third parties can’t access them. That’s why I don’t leave the physical keys to my home outside in public spaces, especially not with my home address on them!  

RSA key exchanges are really vulnerable because they’re not forward secret. That means if ciphertext is acquired, if the attacker acquires its key at any point, even years later, they can then decrypt that ciphertext. That’s because during an RSA key exchange, the shared secret is generated by the ciphertext’s intended client recipient. The client then encrypts it to the public key and sends it to the server. 

TLS 1.3 uses Diffie-Hellman key exchanges exclusively. The tech is about a whole year older than RSA key exchanges (1976 versus 1977), but it’s certainly the better standard. Diffie-Hellman key exchanges are forward secret. With the Diffie-Hellman technique, both the client and server generate both private and public keys. Then both parties send each other their public keys. When the traded public keys are combined with the private keys, a pre-master secret is created. The pre-master secret is the same value for both the client and the server. In that system, a malicious outsider can’t do anything with a private key or a public key, the combination is required, and they must be combined in the right way in order to generate the pre-master secret. Very clever! 

I remember years ago, you’d only usually see the HTTPS protocol being used when highly sensitive data was being exchanged. In the 1990s, the lock icon would appear in my web browser’s UI when credit card information was inputted into an ecommerce site, and then the lock would go away for the rest of the website. Now websites and web apps are strongly encouraged to use HTTPS instead of plaintext HTTP for everything. And gradually, that’s what they’re doing. Many websites now use HTTPS exclusively. Recent versions of major web browsers will even warn users that HTTP webpages are not secure. That’s great! But encrypting all of that data can slow things down. 

Thankfully the way TLS 1.3 implements encryption, data can usually be transferred faster than through TLS 1.2. The cumulative effect of TLS 1.3’s more efficient approach will likely even have been noticed by users. 

TLS 1.3 is simply less latent than TLS 1.2. Negotiation in TLS is just so much simpler. Simplicity is usually efficiently. The ciphersuite entails all the main technical details that must be arranged between the client and the server in the encryption process.  

Look at how complex the TLS 1.3 ciphersuite is. It involves the hash function used for deriving keys (such as SHA1), the key exchange algorithm (ECDHE? RSA?), the cipher (RC4? AES?), the possible cipher mode, the MAC (message authentication code) function, and the type of certificates supported. You don’t need to understand all of that in detail to grasp that it involves a lot of different possible configurations.  

The TLS 1.3 negotiation process focuses on the cipher and hash combination, the signature algorithm, and the key exchange. That sounds easier, because it is. Simply put, the TLS 1.3 negotiation process is less work because there are fewer options. In this case, that makes TLS 1.3 both faster and more secure. 

That extra security is partly due to the less secure options of TLS 1.2 being removed. That entails not only dropping RSA key exchanges, but also vulnerable technologies such as the RC4 cipher and CBC-mode ciphers. 

RC4 ciphers have been found to be vulnerable to the single-byte bias attack. In a 2013 report published by the University of London: 

“We have found new attacks against TLS that allows an attacker to recover a limited amount of plaintext from a TLS connection when RC4 encryption is used. The attacks arise from statistical flaws in the keystream generated by the RC4 algorithm which become apparent in TLS ciphertexts when the same plaintext is repeatedly encrypted. 

We have carried out experiments to demonstrate the feasibility of the attacks. 

The most effective countermeasure against our attack is to stop using RC4 in TLS. There are other, less-effective countermeasures against our attacks and we have worked with a number of TLS software developers to prepare patches and security advisories.” 

CBC-mode ciphers are vulnerable to “Lucky 13” attacks. As written by University of London researchers: 

“We have found new attacks against TLS and DTLS that allow a Man-in-the-Middle attacker to recover plaintext from a TLS/DTLS connection when CBC-mode encryption is used. The attacks arise from a flaw in the TLS specification rather than as a bug in specific implementations. We have carried out experiments to demonstrate the feasibility of the attacks against the OpenSSL and GnuTLS implementations of TLS, and we have studied the source code of other implementations to determine whether they are likely to be vulnerable. There are effective countermeasures against our attacks and we have worked with a number of TLS and DTLS software developers to prepare patches and security advisories.” 

You don’t have to worry about that with TLS 1.3. 

More secure key exchanges, faster negotiations, and dropping insecure encryption implementation methods all make TLS 1.3 leaps and bounds better than TLS 1.2. Let’s upgrade to TLS 1.3 as much as possible, it’ll be well worth the effort for improved functionality and security. 

Related posts

• What Is an SSL/TLS X.509 Certificate? 
• Understanding the Difference between SSL and TLS 
• The Evolution of 256-Bit Encryption and Security Certificates 
• What Is Symmetric Encryption? 

 

Guest Blogger: Kim Crawley

It can be safely assumed that TLS 1.3 is an improvement over TLS 1.2 and TLS 1.1. Newer versions of something should be better, right? Without looking into the matter, one could assume that TLS 1.3 just uses stronger and newer ciphers which would take a lot more raw computing power in order to crack. That’s usually the way things go in the world of cryptographic implementation. But when I examined the new TLS standard closely, I was surprised that TLS 1.3 is superior in many other ways too.