21.2 POODLE

POODLE stands for Padding Oracle On Downgraded Legacy Encryption and was discovered in 2014 by Möller, Duong, and Kotowicz [122]. The name shows that the attack combines two other attacks described in Chapter 19, Attacks on Cryptography, and in Chapter 20, Attacks on the TLS Handshake Protocol, namely the padding oracle attack and the protocol downgrade attack. By exploiting some characteristics of SSL 3.0, Möller et al. could turn these two into one of the most severe attacks on TLS.

Basically, POODLE is an attack on SSL3.0. Although at the time the attack was published, the underlying weakness was already fixed in TLS 1.2 by introducing authenticated encryption into the TLS Record protocol, the attack remained relevant because of the downgrade dance explained in the previous chapter.

21.2.1 Attacker model

At the heart of the problem lies the MAC-then-encrypt construction deployed by SSL 3.0 described in Chapter 15, Authenticated Encryption, and shown in Figure 21.1. Because the SSL 3.0 cipher suites use either the (insecure) RC4 stream cipher (see Section 4.5.2 in Chapter 4, Encryption and Decryption) or any block cipher in CBC mode (see Chapter 14, Block Ciphers and Their Modes of Operation), SSL 3.0 servers will in most cases negotiate a CBC-based cipher suite.

However, it turned out that in connection with the CBC mode of operation, the MAC-then-encrypt construction can be used by an active attacker, Mallory, to deduce parts of the TLS record plaintext. In particular, we are assuming that apart from being able to eavesdrop on and modify messages sent from client Bob to server Alice, Mallory can also see to it that Bob sends encrypted HTTP POST requests to Alice that have been specially crafted by Mallory. For this to happen, Mallory needs to make Bob’s browser execute some specific JavaScript code, which might happen after Bob has visited a malicious website controlled by Mallory.

21.2.2 The attack

In the MAC-then-encrypt construction, the MAC is applied to the plaintext only, but does not cover the padding bytes added to the plaintext before encryption. In particular, this holds true for the last padding byte, which in SSL3.0 is always equal to the number N of padded bytes. By making Bob’s browser send HTTPS requests of a certain length to Alice, Mallory can make sure that a complete 16-byte block is always padded, which means N = 15.

Assume client Bob sends the record

to server Alice, where C1,C2,…Cn are cipher blocks and IV is the initialization vector for the CBC mode. Mallory now replaces the last cipher block Cn with some interesting block Ci and sends the following modified record instead:

If Alice does not send an error message back, this means c could be successfully decrypted by her. From this, Mallory can deduce that the last plaintext block Pn must have the correct padding number N = 15 as its last byte. Now Pn is given by

Thus, by XORing the last byte of Cn−1, Mallory can compute the last byte of Fk−1(Ci). Finally, Mallory can compute the last byte of the interesting plaintext block Pi. This is because in CBC mode,

However, this will only work in 1 of 256 cases. In all other cases, Alice will strip an incorrect number of padding bytes from the plaintext and the MAC cannot be verified. Mallory must therefore ensure that Bob sends a large number of encrypted HTTP POST requests to Alice, all of which contain a resource path and some string parameter controlled by Mallory. These HTTP requests must also contain interesting data unknown to Mallory, for example, an authentication cookie. Because in SSL 3.0 the IV is the last cipherblock of the previous TLS record, all those POST requests will lead to different records, even if the requests are identical.

Mallory can decrypt other encrypted bytes in Ci by shifting them to the end of Ci. This is done by manipulating the HTTPS requests sent out by Bob using a technique called bytewise privilege (see [55]): by increasing the length of the requested resource path, Mallory can push the interesting bytes further toward the end of Ci. Since the overall length of the request must be constant, Mallory at the same time shortens the length of the string parameter in the requests.