Researchers Discover a New Form of Downgrade Attack that Exploits TLS 1.3 Encryption


Author :Justin Brunnette

Category: IT News

A team of researchers from various universities found the new TLS version is vulnerable to forced downgrade and allowing interception and data breaches over internet communication.


The new version of the TLS protocol, TLS 1.3, was released in August of 2018 which was considered to be secure. TLS protocols in general are cryptographic protocols which provide security for internet communication.


TLS boils down to two parts, a TSL record protocol and a TSL handshake protocol. The record protocol protects data using keys created in the handshake protocol. The handshake protocol authenticates and performs a key exchange which creates or resumes a secure sessions.


It is during this handshake process that an attacker exploits. The downgrade attack essentially intercepts the handshake and change the data to look like both the client and the server are sending request to use a earlier version of the protocol. For the sake of compatibility for older systems, TLS clients and servers usually support older versions of the protocol which use weaker algorithms.


When the TLS 1.3 was released, it included two protection measures against downgrade attacks. First It required that both the client and the server send a “finished” messaged that contains all the MAC of the previous handshakes during a session, which allows both the server and the client to make sure that the data has not been tampered with.


Second, it embeds code into the “ServerHello.random” message to indicate that is used when older protocols are in use.


If a TLS 1.3 capable server receives a message from the client that they can only accept TLS 1.2 or lower, it will send a message back in the “ServerHello.random” with the appended code “DOWNGRD.” If a client is TLS 1.3 capable, it will ask the server to use TLS 1.3. But if it receives a message that it only support TLS 1.2, it will check the “ServerHello.random” to see if it contains the code “DOWNGRD.”  If the “ServerHello.random” does contain the code, then it will conclude that there is someone in the middle and will shut down the communication.


Even if a hacker removes “DOWNGRD” from “ServerHello.random”, it will still not be able to gain access since the “ServerHello.random” is used during the first key exchange process.


This form of downgrade attack is known as a Bleichenbacher oracle attack, named after the Swiss cryptographer who first discovered it back in 1998. In the previous versions of the TLS, the Bleichenbacher attack variations continued to be a problem because the authors of TLS, rather than replacing the RSA algorithm, added countermeasures to make it harder and harder to guess the RSA decryption key.


Although the countermeasures where defined in the TLS standard (RFC 5246), hardware and software manufacturers failed to follow the standard to the T. Improper implementation of the countermeasures lead to vulnerable servers, firewalls, VPNs, and code libraries.


Earlier this month, a team consisting of researchers from around the world, found another way to break the RSA algorithm used in the latest TLS 1.3. They stated, “The attack leverages a side-channel leak via cache access timings of these implementations in order to break the RSA key exchanges of TLS implementations.”


In their investigation, they tested nine different TSL implementations and found the following to be vulnerable: OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL, and GnuTLS. Of the nine, only two, BearSSL and Google’s BoringSSL was found to be safe. The bugs have been logged in the CVE: CVE-2018-12404, CVE-2018-19608, CVE-2018-16868, CVE-2018-16869, and CVE-2018-16870.

Original Ariticle: