Return to Answer

The recently demonstrated attack against SSL (BEAST) was an IV misuse attack and not really the same thing as what happened to XML Encryption. Non the less, 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 thats 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 SSL 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)

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)

The recently demonstrated attack against SSL (BEAST) was an IV misuse attack and not really the same thing as what happened to XML Encryption. Non the less, 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 thats 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 SSL 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)

The recently demonstrated attack against SSL (BEAST) was an IV misuse attack and not really the same thing as what happened to XML Encryption. Non the less, 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 thats 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 SSL 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)

The recently demonstrated attack against SSL (BEAST) was an IV misuse attack and not really the same thing as what happened to XML Encryption. Non the less, 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 thats 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 SSL 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).

The recently demonstrated attack against SSL (BEAST) was an IV misuse attack and not really the same thing as what happened to XML Encryption. Non the less, 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 thats 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 SSL 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)