It has been over eight years since the last encryption protocol update, but the final version of TLS 1.3 has now been published as of August 2018. 👏 The exciting part for the WordPress community and customers here at Kinsta is that TLS 1.3 includes a lot of security and performance improvements. With the HTTP/2 protocol update in late 2015, and now TLS 1.3 in 2018, encrypted connections are now more secure and faster than ever. Read more below about the changes with TLS 1.3 and how it can benefit you as a WordPress site owner.
What is TLS?
TLS stands for Transport Layer Security and is the successor to SSL (Secure Sockets Layer). TLS provides secure communication between web browsers and servers. The connection itself is secure because symmetric cryptography is used to encrypt the data transmitted. The keys are uniquely generated for each connection and are based on a shared secret negotiated at the beginning of the session, also known as a TLS handshake.
Many IP-based protocols, such as HTTPS, SMTP, POP3, FTP support TLS to encrypt data.
Web browsers utilize an SSL certificate which allows them to recognize that it belongs to a digitally signed certificate authority. Technically these are also known as TLS certificates, but most SSL providers stick with the term “SSL certificates” as this is generally more well known.
SSL/TLS certificates provide the magic behind what many people simply know as the HTTPS that they see in their browser’s address bar.
- TLS 1.3 vs TLS 1.2
- Speed Benefits of TLS 1.3
- Improved Security With TLS 1.3
- TLS 1.3 Browser Support
- TLS 1.3 Server Support
- Kinsta TLS 1.3 Support
TLS 1.3 vs TLS 1.2
The Internet Engineering Task Force (IETF) is the group that has been in charge of defining the TLS protocol, which has gone through many various iterations. The previous version of TLS, TLS 1.2, was defined in RFC 5246 and has been in use for the past eight years by the majority of all web browsers. On March 21st, 2018, TLS 1.3 has was finalized, after going through 28 drafts. And as of August 2018, the final version of TLS 1.3 is now published (RFC 8446).
Companies such as Cloudflare are already making TLS 1.3 available to their customers. Filippo Valsorda had a great talk (see presentation below) on the differences between TLS 1.2 and TLS 1.3. In short, the major benefits of TLS 1.3 vs that of TLS 1.2 is faster speeds and improved security.
Speed Benefits of TLS 1.3
TLS and encrypted connections have always added a slight overhead when it comes to web performance. HTTP/2 definitely helped with this problem, but TLS 1.3 helps speed up encrypted connections even more with features such as TLS false start and Zero Round Trip Time (0-RTT).
To put it simply, with TLS 1.2, two round-trips have been needed to complete the TLS handshake. With 1.3, it requires only one round-trip, which in turn cuts the encryption latency in half. This helps those encrypted connections feel just a little bit snappier than before.
Another advantage of is that in a sense, it remembers! On sites you have previously visited, you can now send data on the first message to the server. This is called a “zero round trip.” (0-RTT). And yes, this also results in improved load time times.
TLS 1.3 is much faster than 1.2…. RUM data (30days) showing median TLS handshake times #webperf #isTLSFastYet pic.twitter.com/Mc4RHwg8Vt
— Tim Vereecke (@TimVereecke) May 16, 2019
Improved Security With TLS 1.3
A big problem with TLS 1.2 is that it’s often not configured properly it leaves websites vulnerable to attacks. TLS 1.3 now removes obsolete and insecure features from TLS 1.2, including the following:
- Arbitrary Diffie-Hellman groups — CVE-2016-0701
- EXPORT-strength ciphers – Responsible for FREAK and LogJam
Because the protocol is in a sense more simplified, this makes it less likely for administrators and developers to misconfigure the protocol. Jessie Victors, a security consultant, specializing in privacy-enhancing systems and applied cryptography stated:
I am excited for the upcoming standard. I think we will see far fewer vulnerabilities and we will be able to trust TLS far more than we have in the past.
Google is also raising the bar, as they have started warning users in search console that they are moving to TLS version 1.2, as TLS 1 is no longer that safe. They are giving a final deadline of March 2018.
TLS 1.3 Browser Support
Chrome has been shipping a draft version of TLS 1.3 since Chrome 65. In Chrome 70 (released in October 2018), the final version of TLS 1.3 was enabled for outgoing connections.
A draft version of TLS 1.3 was enabled in Firefox 52 and above (including Quantum). They have been retaining an insecure fallback to TLS 1.2 until they knew more about server tolerance and the 1.3 handshake. Firefox 63 (released in October 2018) shipped with the final version fo TLS 1.3.
Microsoft Edge started supporting TLS 1.3 with version 76, and it’s enabled by default in Safari 12.1 on macOS 10.14.4.
With that being said some SSL test services on the Internet don’t support TLS 1.3 yet and neither do other browsers such as IE or Opera mobile.
It might be a while for the rest of the browsers to catch up. Most of the remaining ones are in development at the moment. Cloudflare has an excellent article on why TLS 1.3 isn’t in browsers yet.
However, as of September 11, 2018, TLS 1.3 surpassed TLS 1.0 as the second most used version at Cloudflare.
Guess what happened today? TLS 1.3 surpassed TLS 1.0 as the second-most common version of TLS seen by Cloudflare. #tls13 pic.twitter.com/ASzgNaUIy0
— Nick Sullivan (@grittygrease) September 11, 2018
TLS 1.3 Server Support
If you’re curious whether or not your server or host supports TLS 1.3 yet you can use the SSL Server Test tool. Simply scan your domain and scroll down to the “Protocol Features” section. It will say either yes or no.
Kinsta TLS 1.3 Support
In August 2019, we added TLS 1.3 support to all of our servers. 🔒You can now take full advantage of the web performance and security benefits of TLS 1.3.
Just like with HTTP/2, TLS 1.3 is another exciting protocol update that we can expect to benefit from for years to come. Not only will encrypted (HTTPS) connections become faster, but they will also be more secure. Here’s to moving the web forward! If you’re using legacy TLS versions, you might want to fix ERR_SSL_OBSOLETE_VERSION notifications in Chrome.
Safari supports it in version 11.1 on macOS High Sierra, but TLS 1.3 is disabled by default.
It can be enabled by running the following Terminal command:
sudo defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1
Thanks Jon! I’ve updated the post above with a note about being able to enable TLS 1.3 on macOS.
My computer marks error when oppening some websites, like mail ans stuff, saying its because of TSL 1.3. Why is this happening? It was safe minutes ago
Kaspersky would not allow me to access my Gmail account on Browsers with TLS 1.3 on my desktop with Windows 10. The errors that I was getting on Firefox and Chrome said that Gmail was not a secure connection. It had to be downgraded to TLS 1.2.
UPDATE: Safari supports it on macOS 10.14.4 and newer, as well as iOS 12.2 and newer.
Thanks Jon! We’ve updated the post above with information regarding TLS 1.3 and Safari support.
Can you send me the components and operating principle of TLS 1.3? I want to take a closer look at this version.
Performance of TLS 1.3 is clearly explained about taking away one round trip in the initial handshake and also zero round trip for returning clients. That’s all between the server and the client. The client can be Cloudflare or another CDN like Sucuri or at Kinsta KeyCDN or a direct web connection.
Cloudflare implemented free TLS origin CA certificates to enhance performance & security even more between the server and Cloudflare. Also at entreprise levels $200 or more accounts a trusted CA certificate can be entered to put the SSL/TLS encryption mode on Full (strict). According to Cloudflare and their white paper it’s even more secure and performing.
One side of the TLS/SSL handshake that has a major impact on the performance of TLS/SSL and that’s not discussed or considered anywhere in this document is the verification or validation of certificate made by the browser or establishment of trust. The keychain. If browser doesn’t have the Certificate Authority in it’s database it verifies by going up the keychain it can go up the keychain to establish trust on the certificate. With all the free certificates available now a hacker can have a website up and running with TLS/SSL.
Being that performance is somewhat of an obsession for me and it seem’s Kinsta also. To my understanding so far purchasing a high trust or short keychain certificate will reduce browser delays in verification of certificate trust. That’s why Symantec sells basic certificates for crazy high prices. Organisation validation certificates imply high trust for the browser and higher certificates.
We’ve all seen variations in time to first byte connection and SSL that are perplexing in waterfall charts. It’s simply to my understanding browser validation or establishment of trust of the supplied certificate and the additional lookups or crawling up the keychain that the browser does prior to establishing the TLS/SSL connection.
It brings the question of how much difference in performance or reduction of connection times that short keychain or high trust Certificate Authority purchased TLS certificates give?