Information about a new vulnerability in the TLS protocol, codenamed "Raccoon attack" Y which allows, in rare circumstances, to determine a key preliminary primary which can be used to decrypt TLS connections, including HTTPS when intercepting transit traffic (MITM).
From the information that was released, It is mentioned that the attack is very difficult to implement in practice and is more theoretical in nature. An attack requires a specific TLS server configuration and the ability to very accurately measure the processing time of operations by the server.
The problem is present directly in the specification TLS and only affects connections that use encryption based on the key exchange protocol D.H.
ECDH ciphers do not manifest the problem and they remain safe. Only the TLS protocols up to and including version 1.2 are vulnerable and the TLS 1.3 protocol is not affected and the vulnerability manifests itself in TLS implementations that reuse the DH secret key on different TLS connections.
In OpenSSL 1.0.2e and earlier versions, the key DH is reused on all server connections, unless the SSL_OP_SINGLE_DH_USE option is explicitly set.
Whereas since OpenSSL 1.0.2f, the DH key is reused only when using static DH ciphers. In OpenSSL 1.1.1, the vulnerability does not manifest itself, as this branch does not use the primary DH 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"), on the basis of which the public keys (ga mod pygbmod p).
After receiving the public keys, each party computes a common primary key (gab mod p), which is used to generate session keys.
El ataque Raccoon allows you to determine the primary key through parsing of the information through side channels, assuming that the TLS specifications up to version 1.2 require that all leading zero bytes of the primary key be discarded before calculations with your participation.
The inclusion of the truncated primary key is passed to the hash function based session key generation function with different delays when processing different data.
Accurately timing key operations performed by the server allows an attacker to identify clues that provide a way to judge whether the primary key starts at zero or not. For example, an attacker can intercept the public key (ga) sent by the client, forward it to the server, and determine if the resulting primary key starts with zero.
By herself, defining a byte of the key gives nothing, but intercepting the value «ga»Transmitted by the client during the negotiation of the connection, the attacker can form a set of other related values with «ga»And send them to the server in separate connection negotiation sessions.
By forming and sending the values «gri*ga«, The attacker can, by analyzing changes in server response delays, determine the values that lead to the receipt of primary keys starting from zero. With these values determined, the attacker can compose a set of equations to solve the hidden number problem and calculate the original primary key.
The OpenSSL vulnerability was rated low severity, and the solution was to move the problematic "TLS_DH_ *" ciphers in version 1.0.2w to the "weak ciphers" category which was disabled by default. The Mozilla developers did the same by disabling the DH and DHE cipher suites in the NSS library used in Firefox.
Separately, there are additional issues in the TLS stack of F5 BIG-IP devices that make the attack more realistic.
In particular, deviations were found in the behavior of devices with a zero byte at the beginning of the primary key, which can be used instead of measuring the exact latency in calculations.
Source: https://raccoon-attack.com/