connection, hence impersonating S at C.
FREAK: Factoring 512-bit RSA keys. The main challenge
that remains for the attacker is to factor the 512-bit modulus
to recover the ephemeral private key during the handshake.
First, we observe that 512-bit factorization is now solvable
in hours. Second, we note that since computing ephemeral
RSA keys on-the-fly can be quite expensive, many implementations of RSA_EXPORT (including OpenSSL) allow servers
to precompute, cache, and reuse these public keys for the
lifetime of the server (typically measured in days). Hence,
the attacker does not need to break the key during the handshake; it can download the key, break it offline, then exploit
the attack above for days.
After the disclosure of the vulnerability described above,
we collaborated with other researchers to explore its real-world impact. The ZMap team15 used internet-wide scans
to estimate that more than 25% of HTTPS servers still supported RSA_EXPORT, a surprisingly high number. We
downloaded the 512-bit ephemeral keys offered by many
prominent sites and Nadia Heninger used CADO-NFSb on
Amazon EC2 cloud instances to factor these keys within
hours. We then built a proof-of-concept attack demo that
showed how a man-in-the-middle could impersonate any
vulnerable website to a client that exhibited the RSA_
EXPORT downgrade vulnerability. The attack was dubbed
FREAK—factoring RSA_EXPORT keys.
We independently tested other TLS implementations for
their vulnerability to FREAK. Microsoft SChannel and IBM
JSSE also allowed RSA_EXPORT downgrades. Earlier versions of BoringSSL and LibreSSL had inherited the vulnerability from OpenSSL, but they had been recently patched
independently of our discovery. In summary, at the time of its
disclosure, our server impersonation attack was effective on
any client that used OpenSSL, SChannel, Secure Transport,
IBM JSSE, or older versions of BoringSSL and LibreSSL. The
resulting list of vulnerable clients included most mobile web
browsers (Safari, Android Browser, Chrome, BlackBerry,
Opera) and a majority of desktop browsers (Chrome,
Internet Explorer, Safari, Opera).
3. 5. Summary and responsible disclosure
We systematically tested eight TLS libraries including mi TLS,
found serious state machine flaws in six of them, and were
able to mount ten practical attacks, including eight impersonation attacks that break the core security guarantees of TLS.
Almost all implementations allowed some handshake
messages to be skipped even if they were required for
the current key exchange. We believe that this misbehavior results from a naive composition of handshake state
machines. Notably, several implementations allowed CCS
messages to be skipped. Considering our attacks as well as
the recent Early CCS attack on OpenSSL,c we note that the
handling of CCS messages in TLS state machines is particularly error-prone and deserves close attention. Many implementations (OpenSSL, Java, Mono) also allowed messages
to be repeated.
it eventually obtains the server’s private key, the attacker will
be able to decrypt this data, thereby breaking forward secrecy.
3. 4. HOP to RSA_EXPORT (server impersonation)
In compliance with US export regulations before 2000, SSL
and TLS 1.0 include several ciphersuites that deliberately
use weak keys and are marked as eligible for export. For
example, several RSA_EXPORT ciphersuites require that
servers send a ServerKeyExchange message with an
ephemeral RSA public key (modulus and exponent) whose
modulus does not exceed 512 bits. RSA keys of this size were
first factorized in 19999 and with advancements in hardware
are now considered broken. In 2000, export regulations
were relaxed, and in TLS 1. 1 these ciphersuites were explicitly deprecated. Consequently, mainstream web browsers
no longer offer or accept export ciphersuites. However, TLS
libraries still include legacy code to handle these ciphersuites, and some servers continue to support them. We show
that this legacy code causes a downgrade attack from RSA to
Our tests showed that OpenSSL, Secure Transport, and
Mono accepted ServerKeyExchange messages even during regular RSA handshakes, in which such messages should
never be sent. Upon receiving this message, the client would
fallback to RSA_EXPORT by accepting the (signed) 512-bit
RSA key in the message and using it instead of the full-size
public key in the server certificate. This flaw leads to a man-in-the-middle attack, called FREAK, depicted in Figure 4.
Suppose a client C wants to connect to a server S using RSA,
but the server S still supports some RSA_EXPORT ciphersuites. M intercepts C’s RSA handshake to S and responds
to C with S’s certificate. In parallel, M connects to S using
RSA_EXPORT and ensures that the client and server nonces
on the two connections are the same. Now, M forwards S’s
ServerKeyExchange to C and, due to the state machine
flaw, C accepts this message and overwrites the server’s
public key with the weaker 512-bit RSA key in this message.
Assuming M can factor this key (to obtain the private exponent), it can compute the connection keys and complete the
Figure 4. FREAK attack: a man-in-the-middle downgrades a connection
from RSA to RSA_EXPORT. Then, by factoring the server’s 512-bit
export-grade RSA key, the attacker can hijack the connection, while
the client continues to think it has a secure connection to the server.
Client C MitM Server S
ServerHello(sr, RSA_EXPOR T) ServerHello(sr, RSA )
ServerKeyExchange(signskS (cr sr p512))
Client Key Exchange(rsap 512 (pms ))
) = kdf(pms, cr sr)
) = kdf(pms, cr sr)
ServerFinished (macms (log′C))
authenck1 ( Data )
authenc k2 ( Data’ )
Client Hellocr , [ RSA EXPOR T ]