such results, and only counted the traces that expose real
state machine bugs.
Each bug found by our method corresponds to an unexpected transition in the state machine. For example, Figure 3
shows four bugs we found in various libraries. Extra transitions allowed by clients are depicted as dotted arrows on the
right, and those allowed by servers as dotted arrows on the left.
Not all such transitions lead to attacks, but in the rest of this
section we show how these four transitions can be exploited
by an attacker to break the core security guarantees of TLS.
3. 1. SKIP exchange (server impersonation)
Our first vulnerability enabled a network attacker to attack
TLS clients that used the Java, CyaSSL, or Mono libraries.
Our tests found that these client libraries were willing to
accept handshakes where the server skips the ServerCCS message, thereby disabling encryption for incoming
application data. While this is clearly an implementation
flaw, it cannot be exploited in isolation; it only becomes
an attack when it is combined with a second bug. We also
found that Java and CyaSSL clients allowed the server to
skip the ServerKeyExchange message in Diffie–Hellman
exchanges. Since this message normally contains a signature for server authentication, by skipping it, a network
attacker can impersonate any server.
Suppose a Java client C wants to connect to some trusted
server S (e.g., PayPal). A network attacker M can hijack the
TCP connection and impersonate S, without any actual interaction with S, by sending S’s certificate, skipping all messages, notably ServerKeyExchange and ServerCCS, and
directly sending ServerFinished. Hence, M bypasses the
authenticated key exchange: it can now send unencrypted
data to C, and C will interpret it as secure data from S.
Practically exploiting the attack required just a bit more
attention to implementation details. The Java and CyaSSL
client state machines are so liberal that they allow almost
all server messages to be skipped. When they receive the
ServerFinished message, they authenticate it using an
uninitialized master secret (since the key exchange was
never performed). The Java client uses an empty master
secret, a bytestring of length 0, which M can easily compute.
The CyaSSL client compares the received authenticator with
an uninitialized block of memory, so M can simply send a
bytestring of 12 zeroes, and this will work against any client
executed with fresh memory.
In effect, a network attacker can impersonate an arbitrary
TLS server S, such as PayPal, to any Java or CyaSSL client.
Even if the client carefully inspects the received certificate,
it will find it to be perfectly valid for S. Hence, the security
guarantees of TLS are completely broken. Furthermore,
all the (supposedly confidential and authenticated) traffic
between C and M is sent in the clear without any protection.
3. 2. SKIP verify (client impersonation)
Our tests showed that OpenSSL, CyaSSL, and Mono
allow a malicious client to skip the optional Client-
CertificateVerify message, even after sending a client
certificate to authenticate itself. Since the skipped message
normally carries the signature proving ownership of that
certificate, this bug leads to a client impersonation attack, as
Suppose a malicious client M connects to a Mono server S
that requires client authentication. M can then impersonate
any client C at S by running a regular handshake with S, except
that, when asked for a certificate, it provides C’s client certificate
instead, and then it skips the ClientCertificateVerify
message. The server accepts the connection, incorrectly
authenticating the client as C, allowing M to read and write
sensitive application data belonging to C.
The attack works against Mono as described above, but
requires more effort to succeed against other libraries:
against OpenSSL, it works only for static Diffie–Hellman certificates, which are rarely used in practice; against CyaSSL,
it requires the client to also skip the ClientCCS message
and then send zeroes in the ClientFinished message
(like in Section 3. 1).
As a result, any attacker can connect to (say) a banking
website that uses TLS client certificates to authenticate
users. If the website use Mono or CyaSSL, the attacker can
login as any user on this website, as long as it knows the
user’s public certificate. The attack also works if the website
uses OpenSSL and allows static Diffie–Hellman certificates.
3. 3. SKIP ephemeral (forward secrecy downgrade)
In some settings, a powerful adversary may be able to force
a server to reveal its private key (see, e.g., Ref. 27) and thus
impersonate the server in future connections. Still, we would
like to ensure that prior connections to the server (before the
private key was revealed) remain secret. This property, commonly called forward secrecy, is achieved by the DHE and
ECDHE ciphersuites in TLS, whereas RSA, DH, and ECDH
ciphersuites do not offer this property.
Forward secrecy is particularly important for web browsers that implement the TLS “False Start” feature. 20 These
browsers start sending encrypted application data to the
server before the handshake is complete. Since the server’s
chosen ciphersuite (and, in some cases, even the server’s
identity) has not been authenticated yet, this early application data need the additional protection of forward secrecy.
However, our tests found that NSS and OpenSSL clients
allow the server to skip the ServerKeyExchange message even in DHE and ECDHE handshakes, which require
this message. In such cases, these clients try to use the static
key provided in the server certificate as key exchange value,
thereby falling back to the corresponding DH and ECDH
ciphersuites, without forward secrecy.
Suppose a client based on NSS C (such as Firefox) connects
to a website S authenticated by an ECDSA certificate (such as
Google) using an ECDHE ciphersuite. A network attacker M
can suppress the ServerKeyExchange message from S to C.
The client then computes the session secrets using the static
elliptic curve key of the server certificate, but still believes it
is running ECDHE with forward secrecy, and immediately
start sending sensitive application data (such as cookies or
passwords) because of False Start. Although the connection
never completes (as the client and server detect the message
suppression at the end of the handshake), the attacker can
capture this False Start encrypted data. As a result, assuming