Making sense of SSL/TLS vulnerabilities

Update (29/11/2013): After a discussion with Kenny Paterson, the conclusion below has been reworked to show more clearly that the choice of the encryption mechanism in the SSL Record Protocol should depend on whether client-side or server-side mitigation techniques can be relied on.

SSL/TLS is arguably the most widely-used protocol to secure communications on the Internet nowadays. It is used, for instance, to protect the sensitive traffic of e-banking and e-commerce web applications. It is also becoming more and more popular as the basis for Virtual Private Networks (VPNs).

During recent months and years, several weaknesses have been discovered in the SSL/TLS protocol. Some attacks target the way data is encrypted by SSL/TLS, namely BEAST, Lucky 13, and the RC4 attack. Other attacks, like CRIME and BREACH, are based on exploiting the way data is compressed.

Here, we focus on attacks targeting the way data is encrypted in SSL/TLS, because these attacks seem to have caused conflicting opinions about which SSL/TLS ciphersuites are most appropriate to mitigate them.

Back in March, Matthew Green recommended abandoning RC4 immediately. In September SSL Labs at Qualys deprecated RC4 in its SSL/TLS Deployment Best Practices guide. On the other hand, at the recent ECC 2013 conference in Leuven, Emilia Kasper defended Google’s use of RC4 as primary cipher. Google’s Adam Langley seems to reinforce that position in a recent blog post.

So: should we use CBC-mode encryption, RC4, or something else? Let’s first take a step back and briefly look at how SSL/TLS works, before diving into the actual attacks.


SSL/TLS is not a single protocol, but rather a set of protocols. In this discussion, we are only concerned with two protocols, namely the SSL Handshake Protocol and the SSL Record Protocol.

The SSL Handshake Protocol is essentially an authenticated key establishment (AKE) protocol: its purpose is to authenticate the client and server, and establish a common secret between them.  It provides several key exchange methods, the most important ones being:

  • RSA: in this case the client generates a secret and provides it to the server, encrypted under the latter’s public key
  • Diffie-Hellman: in this case the client and server exchange their respective Diffie-Hellman public keys, and calculate a shared secret

The SSL Record Protocol subsequently uses the shared secret to protect the confidentiality and integrity of bulk data exchanged between the client and server, and to guarantee the freshness of the data using counters. It provides three ways to protect data:

  1. Using a MAC followed by encryption with a block cipher (e.g. AES) in CBC-mode
  2. Using a MAC followed by encryption with the stream cipher RC4
  3. Using a block cipher in a mode that provides authenticated encryption, such as GCM and CCM (available since TLS 1.2)

SSL/TLS cipher suites

SSL/TLS cipher suites consist of two parts. The first part determines the mechanism used to exchange the secret key (usually based on RSA or Diffie-Hellman), as well as the mechanism used to authenticate the client and/or server. The second part determines the algorithms used to MAC and encrypt bulk data.

The full list of cipher suites  is available in IANA’s TLS Cipher Suite Registry. As an example, the cipher suite “TLS_DHE_RSA_WITH_AES_128_CBC_SHA256” means the following:

  • DHE: use Ephemeral Diffie-Hellman to agree on the shared secret
  • RSA: use RSA digital signatures to authenticate the Diffie-Hellman key agreement
  • AES-128 CBC: use AES in CBC-mode to encrypt the data
  • SHA256: use HMAC-SHA26 to authenticate the data

Recent attacks against SSL/TLS

The most recent attacks have all focused on the SSL Record Protocol, and more specifically on two ways to protect data:

  1. Encryption with a block cipher in CBC-mode
  2. Encryption with the RC4 stream cipher

Let’s take a more detailed look at three attacks, namely the BEAST attack, Lucky 13 and the RC4 attack. The first two target CBC-mode encryption, while the latter focuses on RC4 encryption.

Browser Exploit Against SSL/TLS (BEAST)

The BEAST attack, reported by Julianno Rizzo and Thai Duong at the ekoparty conference in September 2011, is in fact an implementation of an attack discovered by Gregory Bard in 2004. The attack applies to all versions of SSL and also TLS 1.0.

As mentioned above, one of the options in the SSL Record Protocol is using CBC-mode encryption. CBC-mode encryption, like most modes of operation, requires an Initialization Vector (IV). According to good practices in cryptography, every message should be encrypted with a fresh, random IV.

However, in SSL and TLS 1.0, this is not the case. Although the first IV is a (pseudo) random string which is generated by the SSL Handshake Protocol, subsequent IVs are chosen in a deterministic, predictable way. More specifically the IV of a message is taken to be the final ciphertext block of the immediately-preceding message, and is therefore known to the adversary.

The BEAST attack allows a man-in-the-middle to decrypt session cookies, simply by injecting Javascript into the victim’s web browser.

There are basically four ways to mitigate the BEAST attack:

  1. Upgrade to TLS 1.1 or 1.2
  2. Use 1/n-1 record splitting. This means that encrypted SSL/TLS records are split into two parts: the first with only a single byte of application data and the second with the remaining application data. This is a client-side mitigation technique. The major browser vendors already implemented this back in January 2012.
  3. Use AES in a mode providing authenticated encryption
  4. Use RC4 instead of CBC encryption

Lucky 13

As mentioned above, the SSL Record Protocol aims to protect both the integrity and confidentiality of a message. In general there are three ways to combine integrity and confidentiality protection:

  1. Encrypt-then-MAC (the approach of IPsec)
  2. MAC-then-Encrypt
  3. Authenticated encryption

The SSL Record Protocol uses the MAC-then-Encrypt approach (and authenticated encryption as from TLS 1.2, but let’s forget about that for now). It starts by fragmenting the plaintext data, optionally compressing every fragment, and then calculating a MAC over the (compressed) fragment. Subsequently the fragment is padded to a multiple of the block cipher’s block size using a padding mechanism that is similar, but not identical to PKCS #7 padding. The padded message is encrypted using the block cipher in CBC-mode.

Unfortunately the MAC-then-Encrypt approach is vulnerable to so-called padding oracle attacks. Since the padding is not protected by a MAC, an adversary could intercept a ciphertext, alter it, and submit it to the SSL/TLS server for decryption. If the server returns different error messages (e.g. “incorrect padding” instead of “incorrect MAC”) for different altered ciphertexts, the adversary receives information that can be used to successfully decrypt the ciphertext.

The designers of SSL/TLS were aware of this problem many years ago, and therefore SSL/TLS servers do not return error messages indicating that the padding was wrong. However, there is still a difference in the amount of time it takes to decrypt ciphertexts, depending on whether or not the padding is correct.

In February, researchers from Royal Holloway reported a plaintext recovery attack against CBC-mode encryption, based on exploiting those timing differences. The adversary requires the target plaintext to be repeatedly sent in the same position in the plaintext stream in 2^13 ~ 8000 TLS sessions per byte of plaintext. Additionally the adversary has to be located on the same LAN as the machine being attacked in order to reliably measure timing differences.

There are basically three ways to mitigate the Lucky 13 attack:

  1. Use an SSL/TLS server-side implementation with constant-time CBC decryption. Adam Langley made a 500-line implementation for this in OpenSSL.
  2. Use AES in a mode providing authenticated encryption
  3. Use RC4 instead of CBC encryption. But as we discuss next, RC4 has its own problems.

The RC4 attack

RC4 is a stream cipher, meaning that it transforms a (short) cryptographic key into a (long) keystream of pseudorandom bytes. In order to encrypt a plaintext, the plaintext is XORed with the keystream.

In order for this to work, it is important that the keystream bytes are sufficiently random. Unfortunately several years ago, researchers already discovered statistical biases in the RC4 keystream, but they were never considered to be harmful enough in order to be exploitable.

Then, in March of this year, researchers from Royal Holloway, the University of Chicago at Illinois and the Eindhoven University of Technology reported additional biases in the first 256 bytes of the RC4-128 keystream, which can be exploited to perform a plaintext recovery attack. The attacker can be located anywhere on the path between the client and the server.

In order to be successful, the attacker needs to obtain the same plaintext encrypted under many different keys, on the order of 2^33 to 2^34 for reliable recovery of 16 bytes anywhere in the plaintext. For instance, in order to recover a cookie, the attacker would have to make the victim’s browser send about 1 to 10 billion copies of the same cookie, encrypted under different keys.

While the attack is feasible and reduces the security level of RC4 well below the strength one would expect from a 128-bit key length, the attack is not really practical at the moment. The only way to avoid it consists of abandoning RC4.

Conclusion: RC4 or CBC encryption?

The best option clearly is to move to TLS 1.2 and use an authenticated encryption mode such as GCM and CCM. So far no attacks are known against those modes. Today all major browser vendors support TLS 1.2, so this is the best way forward.

However, it will take some time for users to upgrade browsers to a version that supports TLS 1.2. Therefore, the question today is whether to use RC4 or CBC-mode encryption in the SSL Record Protocol.

In my opinion the answer to this question depends on whether you have control over the SSL/TLS client, SSL/TLS server or both. Let’s try to clarify that.

First, if you only control the SSL/TLS server, you may want to rely only on server-side techniques to mitigate the above-mentioned attacks. In order to counter the Lucky 13 attack, you can implement an SSL/TLS library with constant-time CBC decryption. The only server-side technique to address BEAST consists of using RC4, which exposes you to the RC4 attack. So you have to choose: either you accept the BEAST attack, or the RC4 attack. Since the RC4 attack is the more difficult one, I would settle with RC4 in this case.

Second, if you only control the SSL/TLS client, you can mitigate the BEAST attack using 1/n-1 record splitting. So that leaves you with the choice of accepting either the Lucky 13 or RC4 attack. Since the RC4 attack is much less feasible than the Lucky 13 attack, I would go for RC4 again.

Finally, if you control both the SSL/TLS client and server, the situation is different. In this case you can deploy 1/n-1 record splitting to avoid the BEAST attack, and constant-time decryption at the server-side to avoid the Lucky 13 attack. In this case, the best choice is to go for CBC-mode encryption, so that the RC4 attack is thwarted as well.

Bottom-line: it’s quite complicated today. The good news: it should all be much simpler in the future with TLS 1.2.

Afbeelding | Dit bericht werd geplaatst in Uncategorized. Bookmark de permalink .

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen. logo

Je reageert onder je account. Log uit / Bijwerken )


Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s