A researcher has discovered certain implementations of the Transport Layer Security (TLS) protocol used to encrypt web traffic can leak RSA keys.
It seems efforts to make the internet more secure and private have introduced new weaknesses that could undermine encrypted web communications.
In light of the NSA surveillance activities capturing large volumes of encrypted communications from web companies, those firms have in recent years been implementing “perfect forward secrecy” (PFS) in TLS, the protocol denoted in browsers by “HTTPS” that signal to the user a connection is encrypted.
PFS helps address the event an attacker captures HTTPS encrypted sessions and later acquires the key to decrypt them, say under a warrant. Instead of relying on a single key for multiple sessions, with PFS a new key is generated for every encrypted session, making it more costly for an attacker decrypt.
But a side-effect of the increased use of PFS is that it’s exposed an additional weakness in TLS that an attacker with little computing power could use to recover a server’s private RSA key.
Florian Weimer from Red Hat’s product security team outlined the weakness in a paper on Wednesday after discovering network hardware from multiple vendors in the wild that leaked “RSA-CRT” keys when subjected to a certain attack and that some free software TLS implementations didn’t include hardening against this type of attack.
“The actual key recovery attack can be described in very simple terms: establish a TLS session, negotiate forward secrecy, and watch out for a miscomputed signature. If a signature mismatch is detected, attempt Lenstra’s attack to recover the RSA private key,” Weimer noted the paper he’s called “Factoring RSA Keys With TLS Perfect Forward Secrecy”.
The attack, as Weimer explained in a blog post, was described by Dutch mathematician Arjen Lenstra in a 1996 paper detailing a “side channel attack” against the Chinese Remainder Theorem (CRT) — a method used to speed up calculations of the RSA algorithm, known as “RSA-CRT”. It doesn’t exploit RSA directly, but rather “unexpected implementation behaviour”.
Though it’s an old attack it hasn’t been particularly important due to PFS and more generally encryption wasn’t the norm at that time of Lenstra’s finding.
“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. This changed gradually, when forward secrecy for TLS was recommended and introduced by many web sites,” Weimer noted.
“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”),” he added.
Once the private key has been leaked, an attacker could “cryptographically impersonate the server, after redirecting network traffic, conducting a man-in-the-middle attack. Either the client making the TLS handshake can see this leak, or a passive observer capturing network traffic,” wrote Weimer, describing the impact.
“The key leak also enables decryption of connections which do not use forward secrecy, without the need for a man-in-the-middle attack. However, forward secrecy must be enabled in the server for this kind of key leak to happen in the first place, and with such a server configuration, most clients will use forward secrecy, so an active attack will be required for configurations which can theoretically lead to RSA-CRT key leaks,” he added.
“RSA-CRT key leak” incidentally is the name Weimer’s given the bug, bucking the recent trend of branded open source bugs like Heartbleed.
The good news is that RSA-CRT optimisation in TLS implementations with appropriate hardening is still considered secure, Weimer noted. These include the widely used OpenSSL and Mozilla NSS libraries while Oracle’s OpenJDK was patched in April. Unlike previous open source bugs that have affected RedHat products, this one does not.
“All browser PKI certificates for which we observed key leaks have been replaced and revoked,” Weimer added.
However, during a global internet probe for the bug, Weimer found several pieces of hardware in the wild that leaked keys under Lenstra’s attack. These included a Citrix Netscaler device, and devices from Hillstone Networks mostly located in China, as well as devices made by Viprinet, QNO Technology, ZyXEL, BEJY, and Fortinet.
Weimer notes in the paper that a potential root cause of the issue is a custom version OpenSSL from US semiconductor maker Cavium, which supplies hardware to several of the vendors.
“Citrix, Hillstone Networks, and ZyXEL confirmed that they use Cavium as a hardware supplier,” said Weimer.
Cavium told Weimer in a statement that it had issued patches for several pieces of hardware using an old version of its cryptographic SDK.
“Cavium has issued a patch and notified all customers (CVE-2015-5738) that are using older SDK 2.x Cavium Cryptographic Software under Linux on older OCTEON II CN6xxx Hardware with details of the vulnerability. OCTEON II running Simple Exec (SE-S) applications and OCTEON III CN7xxx processors are not affected.”
Finally, for those wondering what course of action to take, Weimer does not recommend disabling forward secrecy.
“If you expect that a key leak might happen in the future, it could well have happened already. 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. This means that disabling forward secrecy generally makes things worse,” he said.