momius - Fotolia
TLS 1.3 update is finalized with encryption upgrade
The IETF approves the TLS 1.3 encryption protocol upgrade after four years and 28 versions; improvements include better security and performance, as well as middlebox support.
After four years and 28 different versions, the Internet Engineering Task Force approved the update to the Transport...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
Layer Security protocol for internet encryption and authentication. The new standard, which includes security and performance improvements, will be published as a proposed standard internet protocol RFC later this year.
TLS 1.3 is the new version of the most commonly used encryption protocol on the internet. The upgrade reflects significant changes to the protocol that are designed to protect against attacks on TLS, especially those that exploit deprecated cryptographic algorithms like MD-5 and SHA-1; it should also help reduce protocol attacks that trick TLS implementations into using older, less secure versions that are relatively easy to defeat.
Another longtime obstacle to the approval of the TLS 1.3 encryption protocol was caused by enterprise network security appliances known as middleboxes, many of which were failing to work as expected with the upgraded protocol in testing.
Middleboxes serve as legitimate "man-in-the-middle" devices that allow businesses to do stateful inspection of encrypted network traffic in order to comply with industry regulations or to detect and defend against attempts to access data without authorization. Middleboxes also figure prominently in the content delivery network (CDN) business, where companies distribute trust to CDN devices which negotiate end-to-end encryption streams between clients and proxy servers.
The TLS 1.3 upgrade faced challenges with the way many middleboxes negotiated TLS connections with clients and servers. Those issues have been addressed in the new specification for middleboxes; the new TLS protocol specification specifies that implementations will be more compliant if they make "the TLS 1.3 handshake look more like a TLS 1.2 handshake." While the protocol was revised to accommodate middleboxes, the specification states that those noncompliant middlebox implementations of the TLS 1.3 encryption protocol are still incompatible, and must be revised.
Strong support for TLS encryption protocol upgrade
Given the length of time and number of drafts, support for the update to the TLS 1.3 encryption protocol from both individuals involved in the process and from the internet community at large, was notable. In its announcement of acceptance of the TLS 1.3 encryption draft, the Internet Engineering Steering Group (IESG) of the IETF noted "strong consensus" in the working group for the updates to the TLS encryption protocol.
The IESG voting was particularly strong: Eight members of the steering committee voted "Yes" while five voted "no objection," as Adam Roach, a principal engineer at Mozilla and longtime IETF contributor noted on Twitter:
Don’t confuse “no” with “no objection”. Most documents pass with one (or maybe two) “yes” votes, and everyone else balloting “no objection”. TLS 1.3 is utterly remarkable in that it got eight (!!!) yes ballots. The level of support in the IESG was unusually high.— Adam Roach (@adambroach) March 21, 2018
Industry support in terms of the number and breadth of implementations is also high. In order to be considered a Proposed Standard by the IETF, a protocol must have at least two independent and interoperable implementations; in its announcement the IESG noted that the new TLS encryption protocol has more than 10 interoperable implementations of the protocol written in different languages and from different sources. "The major web browser vendors and TLS libraries vendors have draft implementations or have indicated they will support the protocol in the future.
"In addition to having extensive review in the TLS working group, the protocol has received unprecedented security review by the academic community," the IESG wrote. "Several TRON (TLS Ready or Not) conferences were held with academic community to give them a chance to present their findings for TLS. This has resulted in improvements to the protocol. There was also much consideration and discussion around any contentious points, resolved through polls and working group last calls."
TLS 1.3 encryption removes vulnerabilities
One of the most important changes to TLS 1.3 is the removal of legacy cryptographic algorithms, such as the SHA-1 and MD5 hashing algorithms and other algorithms or protocols which have been proved to be insecure. The removal of static RSA and Diffie-Hellman cipher suites means that all public-key-based key exchange mechanisms are now able to provide forward secrecy.
Also addressed is the use of mechanisms to negotiate algorithms and key exchange with older versions of TLS. These mechanisms, either in themselves or through insecure implementations, have in the past made possible serious attacks against TLS.
Most recently, a 19-year-old vulnerability in TLS was reported last year. Dubbed the "Return of Bleichenbacher's Oracle Threat," the ROBOT attack described an approach to decrypting a targeted session one bit at a time by sending many variations of ciphertext to the server, which then either responds to indicate that the server was unable to decrypt the ciphertext or returns a different error message relating to the length of the packet (meaning the ciphertext was decrypted).
The Heartbleed vulnerability, uncovered in 2014, exploited a vulnerability in the OpenSSL implementation of the Heartbeat TLS protocol extension, which helps with performance by specifying a mechanism for keeping inactive connections open without having to renegotiate the connections.
The Padding Oracle On Downgraded Legacy Encryption, or POODLE, flaw in SSL 3.0 was also discovered in 2014, and it enabled attackers to force the use of the legacy RC4 encryption algorithm. The SSL protocol, first used in the original Netscape web browsers and servers, was updated and renamed Transport Layer Security when it was adopted by the IETF for web encryption and authentication.