# How can Cipher Block Chaining (CBC) in SSL be attacked?

I am trying to understand how CBC-mode in SSL/TLS can be attacked.

I have been looking around online but all examples and explanations are very hard to understand and follow. Can you give a simple explanation for how such attacks happen?

The recently demonstrated attack against SSL (BEAST) was an IV misuse attack and not really the same thing as what happened to XML Encryption. Nonetheless, here is what happened with SSL.

Basically they found two things:

1. A way to get the browser to encrypt data under the session key used by an existing SSL connection and
2. A mistake in the way SSL was written that allowed that ability to be leveraged to read messages.

Let's says you are using AES with CBC mode. Encryption for the first block of a message is basically $AES(K, IV \oplus m)$. The IV is typically sent along with the ciphertext. This is a simplification ignoring how longer messages are handled, see Wikipedia's CBC article for more details, but it works for this purpose.

The point of this is that multiple encryptions of the same thing don't result in the same cipher text because the IV is random and data XOR random = random, so you never actually encrypt the same message. Thus an attacker who can cause the browser to encrypt data can't simply guess at what the message was and verify that guess by causing the browser to encrypt the guess and checking if it matches the encrypted message they want to read.

Well the problem is, if I know the IV in advance, this no longer holds: If I want to guess that some previous message was "attack at dawn" (with IV $IV_1$) and I know the IV for the next message will be $IV_2$, then I merely need to cause the browser to encrypt a message $m$ such that $IV_1 \oplus \text{"attack at dawn"} = IV_2 \oplus m$, and check if the ciphertext blocks match.

SSL used the last 128 bits of the previous encrypted message as the IV. Because there was time between when this message was sent and the next, the attacker could make a guess.

This is a basic overview, there still some details of how you do this efficiently to get the session cookie sent with each HTTP request, but that's the gist of it.

This attack is not possible with TLS 1.1 and 1.2 (as they generate a new initialization vector for each message), and the OpenSSL library worked around this problem already in TLS 1.0 by sending an empty message (i.e. only padding and MAC) directly before each real message, so the ciphertext of this empty message is used as initialization vector for the real one (and this is not predictable without knowing the key). (Edit: it turns out this feature is disabled in OpenSSL because it breaks large numbers of servers who assume a zero byte read is an end of file. Instead, the deployed fix is "1/n-1 record splitting" where one byte is sent in a block and the rest of the message is in the next block)

• I edited your answer a bit to make it clear that you speak about the BEAST attack - I hope I interpreted this right. Feel free to edit again, or roll back my change. – Paŭlo Ebermann Oct 29 '11 at 17:29
• Wonderful explanations. It is key to know that IV1, IV2 can be obtained fairly easily in TLS 1.0, but this is made impossible in TLS 1.1 and 1.2. Without knowing two IVs, CBC attack can not be done. – linbianxiaocao Mar 24 '16 at 15:35
• Note that CBC padding oracles are also possible for TLS because it uses mac-then-encrypt instead of encrypt-then-mac. Implementations need to be programmed in such a way that they ignore padding oracles. See also: POODLE attack – Maarten Bodewes Mar 31 '18 at 13:07
• Nitpick: CBC suites in SSL and TLS1.0 use the last block of the previous record as IV (except for first record, which uses the PRF expansion); that can be 64 or 128 bits depending on (the data-cipher component of) the negotiated suite. – dave_thompson_085 Apr 1 '18 at 4:42

CBC isn't an attack, is a block cipher mode of operation. You're probably thinking of the "padding oracle" attack.

AES-CBC as implemented in TLS 1.2 is susceptible to Moxie Marlinspike's Cryptographic Doom Principle, which states:

If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

With the AES-CBC as implemented in TLS 1.2, an HMAC of the plaintext (and header information) is taken. Then, this HMAC is concatenated with the plaintext, padded to the necessary length, then encrypted with AES-CBC, and sent over the wire. See section 6.2.3.2 of RFC5246 for more information.

This is the Authenticate then encrypt case, as described in the blog post referenced above by Moxie: The sender computes a MAC of the plaintext, then encrypts both the plaintext and the MAC. Ek1(P || MACk2(P)). This is susceptible to Vaudenay's Attack, as described in the blog post.