Alert 3SHAKE VHC SMACK Logjam SLOTH
Introduction Threat Model SKIP FREAK

SMACK: State Machine AttaCKs

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.

Threat Model

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.

SKIP-TLS: Message Skipping Attacks on TLS

TLS state machine implemented in JSSE
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.

SKIP-TLS: Disclosure Information

SKIP-TLS: Am I Vulnerable?

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).

FREAK: Factoring RSA Export Keys

FREAK exploit on Safari
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).

FREAK: Online References

FREAK: Disclosure Information

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:

Other client applications (such as email) that use the above TLS libraries may also be affected. Mobile apps that bundle their own TLS libraries are also vulnerable, as shown here.

FREAK: Am I Vulnerable?

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.