Vulnerability in TLS allowing key discovery for connections based on DH ciphers

Disclosed information about the new vulnerabilities (CVE-2020-1968) in the TLS protocol, codenamed
Raccoon and allowing, under rare circumstances, to determine a preliminary primary key (pre-master), which can be used to decrypt TLS connections, including HTTPS, when intercepting transit traffic (MITM). It is noted that the attack is very difficult for practical implementation and is more of a theoretical nature. The attack requires a specific configuration of the TLS server and the ability to very accurately measure the processing time of operations by the server.

The problem is present directly in the TLS specification and only affects connections using ciphers based on the DH key exchange protocol (Diffie-Hellman, TLS_DH_*"). With ECDH ciphers, the problem does not appear and they remain secure. Vulnerable are only TLS protocols up to version 1.2 inclusive, TLS 1.3 protocol is not affected by the problem. The vulnerability manifests itself in TLS implementations that reuse the DH secret key in different TLS connections (this behavior is observed on approximately 4.4% of servers from the Alexa Top 1M rating).

In OpenSSL 1.0.2e and earlier, the DH primary key is reused in all server connections unless the SSL_OP_SINGLE_DH_USE option is explicitly set. Starting with OpenSSL 1.0.2f, the DH primary key is only reused when using static DH ciphers ("DH-*", e.g. "DH-RSA-AES256-SHA"). In OpenSSL 1.1.1, the vulnerability does not manifest itself, since this branch does not use the DH primary key and does not use static DH ciphers.

When using the DH key exchange method, both sides of the connection generate random private keys (hereinafter key "a" and key "b"), based on which public keys (ga mod p and gb mod p) are calculated and sent. After receiving the public keys, each party calculates a common primary key (gab mod p), which is used to form session keys. The Raccoon attack allows you to determine the primary key through the analysis of information through third-party channels, starting from the fact that in the TLS specifications up to version 1.2 it is prescribed to discard all leading zero bytes of the primary key before calculations with its participation.

Including the truncated primary key is passed to the session key generation function, based on hash functions with different delays when processing different data. Precise timing of key operations performed by the server allows the attacker to determine hints (oracle) that make it possible to judge whether the primary key starts from zero or not. For example, an attacker can intercept the public key (ga) sent by the client, resend it to the server, and determine
whether the resulting primary key starts at zero.

By itself, the definition of one byte of the key does not give anything, but by intercepting the “ga” value transmitted by the client when negotiating the connection, the attacker can form a set of other values ​​\uXNUMXb\uXNUMXbrelated to “ga” and send them to the server in separate connection negotiation sessions. By generating and sending the "gri*ga" values, the attacker can, through analysis of the change in delays in the server response, determine the values ​​that lead to the receipt of primary keys starting from zero. Having determined such values, the attacker can make a set of equations for solutions hidden number problems and compute the original primary key.

Vulnerabilities in OpenSSL assigned low severity level, and the fix was to move the problematic "TLS_DH_*" ciphers to the "weak-ssl-ciphers" cipher category disabled by default in release 1.0.2w. Mozilla developers did the same, turned off in the NSS library used by Firefox, the cipher suites DH and DHE. Starting with Firefox 78 problematic ciphers are disabled. In Chrome, support for DH was dropped back in 2016. The BearSSL, BoringSSL, Botan, Mbed TLS, and s2n libraries are not affected because they do not support DH ciphers or static DH cipher variants.

Separately, additional problems are noted (CVE-2020-5929) in the TLS stack of F5 BIG-IP devices, making the attack more realistic. In particular, deviations in the behavior of devices were identified in the presence of a null byte at the beginning of the primary key, which can be used instead of measuring the exact delay time in calculations.

Source: opennet.ru