A number of TLS software implementations contain vulnerabilities that allow hackers with minimal computational expense to learn RSA keys.
Florian Weimer, a researcher with Red Hat, last week published a paper called “Factoring RSA Keys With TLS Perfect Forward Secrecy” that demonstrated vulnerabilities in a number of devices, including a popular Citrix load balancer and others from Hillstone Networks, Nortel, Viprinet and others.
The TLS implementations in these products, Weimer said, lack proper hardening to defend against what is known as the Lenstra attack against the Chinese Remainder Theorem, also known as RSA-CRT.
“If a fault happened during the computation of a signature (using the RSA-CRT optimization), an attacker might be able to recover the private key from the signature (an “RSA-CRT key leak”). At the time, use of cryptography on the Internet was uncommon, and even ten years later, most TLS (or HTTPS) connections were immune to this problem by design because they did not use RSA signatures,” Weimer wrote of the Lenstra attacks. “This changed gradually, when forward secrecy for TLS was recommended and introduced by many web sites.”
Lenstra is described as a side-channel attack, and Weimer said that the RSA algorithm itself is safe against this attack and that the weakness is strictly in the various implementations that are not hardened.
“We saw several RSA-CRT key leaks, where we should not have observed any at all,” he wrote, adding that implementations in OpenSSL and NSS were hardened, for example, and that Oracle patched OpenJDK in CVE-2015-0478 after working with Weimer. All browser PKI certs where leaks were observed, have been replaced and revoked, he added.
Hackers can use this offline attack relatively inexpensively compared to other cryptographic attacks, he wrote. Grabbing a private crypto key, however, is extremely dangerous to the data and communication the TLS encryption is supposed to be protecting. An attacker, Weimer said, would already have to be on the network via a man-in-the-middle attack or server compromise to pull off this type of secondary attack and ultimately impersonate the server in question.
“Either the client making the TLS handshake can see this leak, or a passive observer capturing network traffic,” Weimer wrote. “The key leak also enables decryption of connections which do not use forward secrecy, without the need for a man-in-the-middle attack.”
Attacks, meanwhile, are difficult to spot since they’re conducted offline. An intrusion detection system, Weimer said, could spot a key leak if it is configured to check all TLS handshakes.
“For the key leaks we have observed, we do not think there is a way for remote attackers to produce key leaks at will, in the sense that an attacker could manipulate the server over the network in such a way that the probability of a key leak in a particular TLS handshake increases,” Weimer said. “The only thing the attacker can do is to capture as many handshakes as possible, perhaps by initiating many such handshakes themselves.”
Forward secrecy is being implemented in many critical systems. With forward secrecy, a new crypto key is generated for every session, meaning that if a hacker is able to intercept many sessions, he would not be able to crack them all someday if he figured out one key—just one session. Disabling forward secrecy, he said, is not a wise strategy.
“Disabling forward secrecy would enable passive observers of past key leaks to decrypt future TLS sessions, from passively captured network traffic, without having to redirect client connections,” Weimer wrote. “This means that disabling forward secrecy generally makes things worse. (Disabling forward secrecy and replacing the server certificate with a new one would work, though.)”
