Skip to main content
banner image
venafi logo

Why TLS 1.3 is a Huge Improvement

Why TLS 1.3 is a Huge Improvement

TLS 1.3 TLS 1.1 TLS 1.2
March 19, 2019 | 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.

Learn more about TLS and other machine identities. Download our Dummies Guide. 
 

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. 


Learn more about machine identity protection. Explore now.  
 

Related posts

 

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection
Industry Research

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection

Machine Identity Protection for Dummies
eBook

Machine Identity Protection for Dummies

About the author

Guest Blogger: Kim Crawley
Guest Blogger: Kim Crawley

Kim Crawley writes about all areas of cybersecurity, with a particular interest in malware and social engineering. In addition to Venafi, she also contributes to Tripwire, AlienVault, and Cylance’s blogs. She has previously worked for Sophos and Infosecurity Magazine.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat