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

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.

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)

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