RSA-CRT Leak Report for November/December 2015

Florian Weimer

This article summaries the RSA-CRT leak developments during November and December, 2015.

Crawler source code

I released the source code of the TLS crawler. It is available here:

The code uses the C++ library developed for the otherwise entirely unrelated symboldb <https://github.com/fweimer/symboldb> project, and to reduce the number of merge conflicts, I preserved most of the sources.

The crawler software no longer uses the TLS implementation from OpenSSL, but a custom one. This avoids the overhead of the Diffie-Hellman handshake, which is not required to validate the ServerKeyExchange message and detect key leaks. It turned out that this increased performance somewhat, but not drastically so. Curiously, the thread-local error queue patch for OpenSSL <https://bugzilla.redhat.com/show_bug.cgi?id=1262775> is still needed for scaling beyond a few dozen threads. It turns out the DER ASN.1 parser in OpenSSL uses the error queue heavily, even for well-formed data. Therefore, the next step will be to replace the DER parser with custom code, and see if this makes a difference.

Crawler status

I found a suitable service provider to run the crawler in the cloud. This crawler instance has performed some eight billion TLS handshakes with forward secrecy, in the period from mid-November 2015 until end of December 2015. About 3,000 leak events for 200 distinct public keys were encountered. Towards the end of December, the crawler slowly went into saturation, in the sense that it was not picking up leaks for new public keys, and the interval between new leaks was becoming larger and larger.

The crawler periodically receives new TLS server IP addresses from Censys <https://www.censys.io/> crawls across the entire IPv4 address space (the 443-https-tls-full_ipv4 data set). My crawler currently currently visits some 25 million IP addresses regularly for which a ServerKeyExchange has been received before.

Vendor status

Multiple RSA-CRT leaks were observed from a security gateway manufactured by a vendor previously not known to be affected. The vendor was contacted, has acknowledged the issue and prepared a fix. An advisory (probably to customers only, not the general public) is in preparation.

The manufacturer of the VPN device mentioned in the previous report was able to reproduce the issue and apply the fix from their supplier. Fixed software is being released to customers.

The TLS-terminating load balancer from the previous report did not make a reappearance, neither this specific device, nor another model like it. I do not know if this is because it was due to a once-in-a-lifetime “cosmic ray” event, or if similarly affected devices are restarted so quickly that my crawler does not detect them while they are leaking private keys.

Hardening developments

Niels Möller added RSA-CRT hardening to Nettle <https://git.lysator.liu.se/nettle/nettle/commit/e0935a046effb0a692bafdc8d5e18f5d80dd4a3d>, the cryptographic library used by current GNUTLS. Backporting the related commits is recommended.

Adam Langley committed crypto/rsa: check CRT result <https://github.com/golang/go/commit/40ac3690efe420ff7665c6fe1eec0933c41d1413> to the Go standard library, hardening it against RSA-CRT leaks. The crawler has not encountered any RSA-CRT key leaks related to the use of Go, although CVE-2015-8618, an error in Go's math/big library <http://www.openwall.com/lists/oss-security/2015/12/21/6> (related Github issue: math/big: incorrect result from Exp on 386 architecture <https://github.com/golang/go/issues/13515>) looks like it could lead to RSA-CRT key leaks.

Revisions


Florian Weimer
Home Blog (DE) Blog (EN) Impressum RSS Feeds