Factoring RSA export keys - FREAK (CVE-2015-0204)

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

This week's issue with OpenSSL export ciphersuites has been discussed in the press as "Freak" and "Smack". These are addressed by CVE-2015-0204, and updates for affected Red Hat products were released in January.

Historically, the United States and several other countries tried to control the export or use of strong cryptographic primitives. For example, any company that exported cryptographic products from the United States needed to comply with certain key size limits. For RSA encryption, the maximum allowed key size was 512 bits and for symmetric encryption (DES at that time) it was 40 bits.

The U.S. government eventually lifted this policy and allowed cryptographic primitives with bigger key sizes to be exported. However, these export ciphersuites did not really go away and remained in a lot of codebases (including OpenSSL), probably for backward compatibility purposes.

It was considered safe to keep these export ciphersuites lying around for multiple purposes.

1. Even if your webserver supports export ciphersuites, most modern browsers will not offer that as a part of initial handshake because they want to establish a session with strong cryptography.
2. Even if you use export cipher suites, you still need to factor the 512 bit RSA key or brute-force the 40-bit DES key. Though doable in today's cloud/GPU infrastructure, it is pointless to do this for a single session.

However, this results in a security flaw, which affects various cryptographic libraries, including OpenSSL. OpenSSL clients would accept RSA export-grade keys even when the client did not ask for export-grade RSA. This could further lead to an active man-in-the-middle attack, allowing decryption and alteration of the TLS session in the following way:

• An OpenSSL client contacts a TLS server and asks for a standard RSA key (non-export).
• A MITM intercepts this requests and asks the server for an export-grade RSA key.
• Once the server replies, the MITM attacker forwards this export-grade RSA key to the client. The client has a bug (as described above) that allows the export-grade key to be accepted.
• In the meantime, the MITM attacker factors this key and is able to decrypt all possible data exchange between the server and the client.

This issue was reported to OpenSSL in October 2014, fixed in public in OpenSSL in January 2015, and shipped in Red Hat Enterprise Linux 6 and 7 two week later via RHSA-2015-0066. This issue has also been addressed in Fedora 20 and Fedora 21.

Red Hat Product Security initially classified this as having low security impact, but after more details about the issue and the possible attack scenarios have become clear, we re-classified it as a moderate-impact security issue.

Additional information on mitigating this vulnerability can be found on the Red Hat Customer Portal.

[Updated 17th March 2014: the original article stated this issue was fixed in OpenSSL in October 2014, however the fix was not public until January 2015.  We have updated the article to clarify this].