A vulnerability in TLS that allows the identification of keys for connections based on DH cipher.

Revealed information about the new a vulnerability (CVE-2020-1968) in the TLS protocol, codenamed
Raccoon and allowing, under rare circumstances, to determine the pre-master secret, which can be used to decrypt TLS connections, including HTTPS, when intercepting transit traffic (MITM). It is noted that the attack is very complex to implement in practice and is more theoretical in nature. To carry out the attack, a specific configuration of the TLS server is required, along with the ability to measure the server's processing time for operations very precisely.

The problem is present directly in the TLS specification and affects only connections using DH-based key exchange ciphers (Diffie-Hellman, TLS_DH_*). There is no issue with ECDH ciphers, which remain secure. Only TLS protocols up to and including version 1.2 are vulnerable; TLS 1.3 is not susceptible to this problem. The vulnerability manifests in TLS implementations that reuse the DH secret key across different TLS connections (such behavior is observed on approximately 4.4% of servers from the Alexa Top 1M ranking).

In OpenSSL 1.0.2e and earlier releases, the DH primary key is reused across all server connections unless the SSL_OP_SINGLE_DH_USE option is explicitly set. Starting from OpenSSL 1.0.2f, the DH primary key is reused only when static DH ciphers ('DH-*', for example 'DH-RSA-AES256-SHA') are used. The vulnerability does not manifest in OpenSSL 1.1.1, as this branch does not use the DH primary key and static DH ciphers are not applied.

When using the DH key exchange method, both parties of the connection generate random private keys (referred to as key 'a' and key 'b'), based on which public keys (ga mod p and gb mod p) are calculated and sent. Upon receiving the public keys, each party computes the shared primary key (gab mod p), which is used to form session keys. The Raccoon attack allows for the determination of the primary key through the analysis of information over side channels, based on the fact that TLS specifications up to version 1.2 require all leading zero bytes of the primary key to be discarded before performing calculations involving it.

This includes a truncated primary key being passed to a session key generation function based on hash functions with differing delays when processing different data. Accurate measurement of the time the server takes to perform operations with the key allows an attacker to identify hints (oracle) that indicate whether the primary key starts with zero or not. For example, an attacker could intercept the public key (ga) sent by the client, resend it to the server, and determine
whether the resulting primary key starts with zero.

Determining a single byte of the key alone provides little information, but by intercepting the value of 'ga' sent by the client during the connection negotiation, the attacker can create a set of other values related to 'ga' and send them to the server in separate connection negotiation sessions. By forming and sending values like 'gri*ga', the attacker can, through analysis of response delay changes from the server, identify values that lead to primary keys starting with zero. Once such values are identified, the attacker can form a set of equations for solutions the hidden number problem and compute the original primary key.

In OpenSSL vulnerabilities has been assigned are classified as low risk, with the fix involving moving problematic ciphers 'TLS_DH_*' in release 1.0.2w to a disabled-by-default category of ciphers with insufficient protection ('weak-ssl-ciphers'). Similarly, Mozilla's developers disabled the DH and DHE cipher suites in the NSS library used in Firefox. Starting from Firefox 78, the problematic ciphers have been disabled. In Chrome, support for DH was discontinued back in 2016. The BearSSL, BoringSSL, Botan, Mbed TLS, and s2n libraries are not affected by this issue as they do not support DH ciphers or static variants of DH ciphers.

Additionally, there are extra issues noted (CVE-2020-5929) in the F5 BIG-IP device TLS stack that make the attack more realistic. In particular, discrepancies in device behavior with a zero byte at the beginning of the primary key have been identified, which can be used instead of measuring the exact time delay during computations.

Source: opennet.ru