The wait is finally over – IETF has published TLS 1.3
UPDATE: While the IETF had approved TLS 1.3, it still hadn’t published it. That changed last Friday when the IETF finally published it as RFC 8446. Hopefully the new standard will be adopted much more quickly than TLS 1.2 was. That standard turns 10 years old next month, yet the Payment Card Industry only recently deprecated TLS 1.0 and some older legacy systems still use TLS 1.1.
As Mozilla’s Eric Rescorla wrote:
TLS 1.3 is already widely deployed: both Firefox and Chrome have fielded “draft” versions. Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number). We expect to ship the final version in Firefox 63, scheduled for October 2018. Cloudflare, Google, and Facebook are running it on their servers today. Our telemetry shows that around 5% of Firefox connections are TLS 1.3. Cloudflare reports similar numbers, and Facebook reports that an astounding 50+% of their traffic is already TLS 1.3!
While some of the biggest sites on the internet have already updated their servers, the proliferation of the new standard will likely only be as fast as other sites add support server-side.
The following post originally ran on April 4th when the standard was first finalized as draft 28. The same version Firefox is adding support for. It has been updates to reflect any changes to the published standard.
TLS 1.3 was finalized in April
After four years, 28 drafts, tons of middleboxes, and some last-minute guest-appearances; the road to making TLS 1.3 a web standard was nothing less than a soap opera. But finally, the IETF (Internet Engineering Task Force) has given its approval to the new standard.
It was approved in the task force’s meeting in London last week (Spring ’18). Many weren’t expecting TLS 1.3 to get approved considering the last-minute “concerns” raised by the banking industry as well as some other groups. But, ignoring those calls, the IETF passed the 28th draft of TLS 1.3, anyway. [Update: The new standard was published as RFC 8446 on 8/10/18]
It is no surprise that the pro-security community is rejoicing at the moment. Why wouldn’t they? After all, TLS 1.3 brings a host of security and performance advancements.
TLS 1.3 Passed with Unprecedented Support
To get the new standard approved, it had to be passed by the Internet Engineering Steering Group (IESG), a wing of IETF. In the words of Adam Roach, a principal engineer at Mozilla, the level of support for 1.3 in the IESG was “unusually high.” Out of the thirteen members who voted, eight members voted in favor of it while five opted for ‘no objection.’
TLS 1.3 is designed in cooperation with the academic security community and has benefitted from an extraordinary level of review and analysis. This included formal verification of the security properties by multiple independent groups; the TLS 1.3 RFC cites 14 separate papers analyzing the security of various aspects of the protocol.
Beyond the review and analysis, 1.3 was also tested extensively to ensure the standard can be used for as long as possible. As the IETF reports:
TLS 1.3 was a primary focus of the IETF 98 Hackathon project that brought together people who work on web browsers, websites, and the Internet of Things. This collaboration helps demonstrate interoperability, catch documentation and implementation bugs, and ultimately ensure the specification provides a solid reference for others looking to implement TLS 1.3.
Here’s a quick video courtesy of the IETF:
What is TLS 1.3?
To understand TLS 1.3, you must first understand what TLS (Transport Layer Security) is.
While browsing on the internet, you may have noticed that the URLs of some sites start with HTTPS while others have HTTP in front of them. You may have even wondered about the difference between them. Well, as you can see superficially, ‘S’ is the difference here. This ‘S’ stands for secure. It means that your connection to the HTTPS site is secured and every bit of information transmitted between the client and the server gets encrypted.
So, how can you get your website secured?
To get a site secured, you need to install SSL/TLS certificates. These certificates, through various mechanisms, facilitate encryption of in-transit information, thereby thwarting any data theft or tampering. The encryption is carried out by cryptographic protocols. These protocols comprise of algorithms and ciphers that are responsible for data encryption.
TLS 1.3 is the fourth version of the TLS family. It brings a host of advancements when compared to TLS 1.2, the incumbent cryptographic protocol.
TLS 1.3: Security Improvements
Vulnerabilities such as POODLE and Heartbleed, and the recently discovered ROBOT attack have shown us how vulnerabilities left unfixed could affect millions of users around the world. TLS 1.3, ditches the insecurities present in TLS 1.2.
TLS 1.2, the latest TLS standard, consists of insecure protocols, ciphers, and algorithms. However, you don’t need to be concerned about it as there is very slim chance you will get attacked. But it doesn’t mean that it can’t be exploited. Attackers can capitalize on these insecure parts of TLS 1.2 and perform a downgrade attack. TLS 1.3 eliminates this possibility by phasing out these obsolete ciphers and protocols while bringing in secure replacements.
Here are some of the ciphers and algorithms discontinued in TLS 1.3:
- RC4 Steam Cipher
- RSA Key Transport
- SHA-1 Hash Function
- CBC Mode Ciphers
- MD5 Algorithm
- Various Diffie-Hellman groups
- EXPORT-strength ciphers
Improved SSL/TLS Handshake
The second major thing that sets TLS 1.3 apart from its predecessors is its upgraded version of the SSL/TLS handshake. Before a secure connection is established between the client and the server, a handshake process is carried out between both the parties. This handshake involves a series of back-and-forth communication steps between the client and the server to validate each other’s and negotiate the terms of the data transfer.
“In previous versions of TLS, the entire handshake was in the clear which leaked a lot of information, including both the client and server’s identities. In addition, many network middleboxes used this information to enforce network policies and failed if the information wasn’t where they expected it,” writes Rescorla. “This can lead to breakage when new protocol features are introduced. TLS 1.3 encrypts most of the handshake, which provides better privacy and also gives us more freedom to evolve the protocol in the future.”
It also streamlines the process, which means better performance. TLS 1.2 along with 1.1 and 1.0, facilitated the handshake by virtue of two round-trips of communication between the client and the server. In technical terms, this is called ‘2-RTT’ handshake.
These two round-trips result in much higher TTFB (time to first byte). It takes somewhere between 0.25 to 0.5 seconds to execute the handshake. Time of half a second might not seem like a big deal but keep in mind that this is just the handshake – a process before data transfer takes place. In areas such as stock trading where connection speed is of paramount importance, half a second could make a massive impact.
TLS 1.3, with its improvised handshake, takes an entire round-trip out of the equation. This way, only a single round-trip is needed to complete the SSL/TLS handshake. Correspondingly, the handshake time is reduced drastically.
However, this isn’t where the advancement stops. TLS 1.3 also enables 0-RTT handshakes between the clients and servers that have met before. It means that it’ll require zero round trips to get the handshake done. This results in significant latency improvement.
IETF says NO to TLS 1.3 backdoor
The banking industry led by BITS, the technology policy division of the financial services roundtable, appeared out of nowhere at the last-minute. They asked for “an option for negotiation of visibility in the datacenter.” In other words, they were asking for a backdoor.
This demand was laughed off by experts when the news came out, and the IETF was widely expected to ignore it. And that’s exactly what happened. As reported by The Register, “An effort to effectively insert a backdoor into the protocol was met with disdain and some anger by internet engineers.”
This was pretty much expected. Backdoor in the protocol that is the foundation of web security? Are you kidding me? There was no way the IETF would have allowed a backdoor in the TLS 1.3 and the vote count vouches for it. The IETF members voted unanimously against having a backdoor. I’m sure they would’ve voted with a big grin on their faces.
How do I enable TLS 1.3?
Google Chrome, the most vastly used browser on the planet, just rolled out support for TLS 1.3 (Draft 23) with the launch of Chrome 65. [Update: Firefox has added support, too] Although this is just the draft, you can still experience TLS 1.3 on the sites that have enabled support for TLS 1.3. Firefox too has enabled TLS 1.3 for its users. Let’s see how you can use TLS 1.3.
Enable TLS 1.3 in Chrome
- First, search for chrome://flags/ in the address bar and hit enter
- Now go to TLS 1.3 and select enable TLS 1.3 (draft 23)
- Relaunch your Chrome
- Go to https://istlsfastyet.com/
- Now press F12 and go to the Security tab
- Reload the website
- Click on the link listed under Main origin
There you have it. As you can see, your connection to the website is protected through TLS 1.3.
Enable TLS 1.3 in Firefox
- Search for about:config in the address bar and press enter
- In the search space, search for tls.version.max
- Now change the value from 3 to 4
- Restart your Firefox
- Go to https://istlsfastyet.com/
- Click on the padlock in the URL bar
- Now you should see a small pop-up citing the connection to be secure. Click on the > that you see and then click on More Information
- A window with certificate details will open up. See the technical details at the bottom of it, you’ll see TLS 1.3 being the security protocol.