IETF Makes Transport Layer Security Version 1.3 Official
TLS 1.3 is now the industry standard for secure Internet connections via HTTPS.
The Internet Engineering Task Force (IETF) made version 1.3 of Transport Layer Security official on August 10. This is now the industry standard for secure Internet connections via HTTPS. After heated discussions for the last two years, TLS 1.3 is now finally supported in both the Chrome and Firefox browsers, and in Facebook.
The length of the discussion time for the changes made to the decades-old TLS 1.2 was most likely due to all the members involved trying to avoid problems that would haunt them at a later date. The Heartbleed attack, for example, was a problem in TLS 1.2 that arose from the design choices that went into its creation.
The crypto schemes used in TLS were drawn from what was good in the 90s, but we have learned much since then.
Financial and banking stakeholders are accustomed to being able to monitor TLS 1.2 communications as an anti-fraud measure. The structure of the changes in 1.3 would put an end to that visibility. The financial side advocated for a backdoor to be put into the protocol so that its members could continue such monitoring. In the end, they were outvoted.
Another area of contention was 0-RTT Resumption. This allows two parties that have previously established a TLS handshake to resume a session using older, previously established keys. If attackers got this information in some way they could spoof a connection. However, it was eventually agreed that any attacker would need physical access to a target in order to pull it off. This condition was thought sufficient to assure security, though only the future will truly tell if this conclusion is justified.
Connections will still fall back to TLS 1.2 if one end is not TLS 1.3-capable. But if an attacker attempts to force this kind of fallback, TLS 1.3 will detect it so that appropriate responses can be made.
What advantages will TLS 1.3 give the average user?
First, the kind of encryption to be used in the session is no longer a mishmash of encryption schemes that are potentially crackable due to sketchy implementation. There are only a few crypto choices allowed. The server provides an encryption key, the client provides a session key and, boom, the two go on to converse.
This scenario also means that a client can't trick a server into using an older, less secure means of encryption, which was possible under TLS 1.2. Since the overhead of handshaking needed to establish a connection goes way down, even on initial contact, the time to first display of content is reduced. Therefore, the overall latency of the system (and especially mobile systems) is greatly reduced.
Because there have been multiple intermediate versions of TLS 1.3; IE, Microsoft Edge, Opera and Safari do not yet fully support the protocol. That is sure to change rapidly now that it has been finalized.
HTTPS needed this upgrade to happen. It will only encourage a wider use of secured connections and provide security for the average user.
Related posts:
— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.
Read more about:
Security NowAbout the Author
You May Also Like
A Cyber Pros' Guide to Navigating Emerging Privacy Regulation
Dec 10, 2024Identifying the Cybersecurity Metrics that Actually Matter
Dec 11, 2024The Current State of AI Adoption in Cybersecurity, Including its Opportunities
Dec 12, 2024Cybersecurity Day: How to Automate Security Analytics with AI and ML
Dec 17, 2024The Dirt on ROT Data
Dec 18, 2024