Implementations of the Transport Layer Security (TLS) protocol must handle a
variety of protocol versions and extensions, authentication
modes and key exchange methods, where each combination may prescribe
a different message sequence between the client and the server.
We address the problem of designing a robust composite
state machine that can correctly multiplex between these
different protocol modes.
We systematically tested popular open-source TLS implementations for
state machine bugs and discover several new critical security vulnerabilities
that have lain hidden in these libraries for years.
We call these collection of vulnerabilities SMACK: State Machine Attacks on TLS.
This page presents exploits and disclosure information related to these
attacks. For a technical overview of the TLS state machine and our
protocol fuzzing methodology, please refer to our upcoming research paper
at IEEE Security & Privacy 2015 and the following materials:
To jump straight to FREAK, go here.
If you wish to contact us, please send an email to contact at dot com.
All the attacks on this page assume a network adversary (i.e. a man-in-the-middle) to tamper with TLS handshake messages. The typical scenario to mount such attacks is by tampering with the Domain Name System (DNS), for example via DNS rebinding or domain name seizure.
Fig. 1: TLS State machine in JSSE
Different cipher suites in TLS use different message sequences.
For instance, in ephemeral Diffie-Hellman cipher suites (including ECDHE),
server authentication relies on the Server Key Exchange message,
whereas this message is completely skipped in the RSA key exchange.
As another example, in non-ephemeral (non forward-secret) variants of Diffie-Hellman cipher
suites, clients use the DH keys embedded in server certificates instead of
freshly generated keys provided in the Server Key Exchange.
We find that several TLS implementations incorrectly allow some messages
to be skipped even though they are required for the selected cipher suite.
The explanation for these attacks is very simple: libraries attempt to reuse
as much code as possible between the different cipher suites. However, the
consequences of these vulnerabilities can be severe.
For instance, Fig. 1 shows the TLS state machine implemented in JSSE
(the Java implementation of TLS shipped with the JDK). Black arrows represent
the state machine according to the protocol specification. Green arrows
represent incorrect transitions in the server state machine; red arrows
represent incorrect transitions in the client state machine.
This figure shows that JSSE clients allow the peer to skip all
messages related to key exchange and authentication. In particular,
a network attacker can send the certificate of any arbitrary website,
and skip the rest of the protocol messages. A vulnerable JSSE client
is then willing to accept the certificate and start exchanging
unencrypted application data. In other words, the JSSE implementation
of TLS has been providing virtually no security guarantee (no
authentication, no integrity, no confidentiality) for the past several
years.
Our attacks show that a malicious server can simply skip TLS altogether: it can pretend to be any server and exchange plaintext data with the client. Still Java clients are used routinely to access sensitive HTTPS APIs such as Google, Paypal, and Amazon Web Services through popular Java SDKs.
You are vulnerable if you use client software that uses one of the above TLS libraries to connect to HTTPS (or IMAPS/SMTPS) servers over an insecure network (such as public Wi-Fi). If your client uses, for example, the latest version of OpenSSL, you are probably not affected by this attack.
We provide an online server to test your client for the specific SKIP-TLS attack against JSSE. Point your HTTPS client to https://ht.vc:6443 - in Java e.g. (new URL("https://ht.vc:6443")).openConnection(). If the connection doesn't trigger an exception, you are vulnerable (please note, you may get an exception if our test server is down).
Fig. 2: FREAK exploit on Safari
Among the various state machine problems we found, one is particularly interesting because
it leads to a server impersonation exploits against several mainstream browsers (including Safari
and OpenSSL-based browsers on Android).
This attack targets a class of deliberately weak export cipher suites.
As the name implies, this class of algorithms were
introduced under the pressure of US
governments agencies to ensure that they would be able to decrypt all foreign encrypted
communication, while stronger algorithms were banned from export (as
they were classified as weapons of war).
Support for these weak algorithms has remained in many implementations
such as OpenSSL, even though they are typically disabled by default;
however, we discovered that several implementations incorrectly allow
the message sequence of export ciphersuites to be used even if a non-export
ciphersuite was negotiated.
Thus, if a server is willing to negotiate an export ciphersuite, a man-in-the-middle
may trick a browser (which normally doesn't allow it) to use a weak export
key. By design, export RSA moduli must be less than 512 bits long; hence, they
can be factored in less than 12 hours for $100 on Amazon EC2.
Ironically, many US government agencies (including the NSA and FBI), as well as a
number of popular websites (IBM, or Symantec)
enable export ciphersuites on their server - by factoring ther 512-bit RSA modulus,
an attacker can impersonate them to vulnerable clients.
Other than websites, HTTPS servers that enable export ciphersuites include those that host popular third-party JavaScript, such as the Facebook JavaScript SDK (loaded in most sites that use Facebook's Like or Login button). By impersonating such vulnerable script servers, an attacker can inject arbitrary JavaScript into any number of innocent third-party websites to steal user data (such as passwords) entered on these sites. We demo how an attacker can perform widespread XSS attacks after factoring the 512-bit RSA modulus for connect.facebook.net (the site that serves Facebook's JavaScript SDK).
We notified a number of vulnerable servers individually, as well as Akamai who host a large number of vulnerable websites. Many sites, including Facebook and FBI, promptly turned off export ciphersuites. Akamai is rolling out a site-wide update to disable these ciphersuites. An updated list of insecure sites is maintained by the ZMap team at FREAKAttack.com
Vulnerable TLS client libraries include
Web browsers that use the above TLS libraries are vulnerable, including:
You are vulnerable if you use a buggy web browser (see above) to connect, over an insecure network, to an HTTPS website that allows export ciphersuites. If you use Chrome 41 or Firefox to connect to a site that only offers strong ciphers, you are probably not affected.
Try to access https://www.smacktls.com/freak from your browser. If it succeeds, you are vulnerable.
