Reference Guide

SSL/TLS Communications 11
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide
BEAST Exploit
There is a known vulnerability in SSLv3 and TLS v1.0 to do with how the
Initialization Vector (IV) is generated. For symmetric key algorithms in CBC mode,
the IV for the first record is generated using keys and secrets set during the SSL or
TLS handshake. All subsequent records are encrypted using the ciphertext block from
the previous record as the IV. With symmetric key encryption in CBC mode, plain text
encrypted with the same IV and key generates the same cipher text, which is why
having a variable IV is important.
The BEAST exploit uses this SSLv3 and TLS v1.0 vulnerability by potentially
allowing an attacker to observe the last ciphertext block, which is the IV, then replace
this with an IV of their choice, inject some of their own plain text data, and when this
new IV is used to encrypt the data, the attacker can guess the plain text data one byte
at a time.
For more information about this vulnerability, see
CVE-2011-3389.
How to Help Prevent the Attack
The best way to help prevent this attack is to use TLS v1.1 or higher. The vulnerability
to do with IV generation was fixed in TLS v1.1 (released in 2006) so implementations
using only TLS v1.1 or TLS v1.2 are secure against the BEAST exploit. However,
support for these higher level protocols is limited to a smaller number of applications,
so supporting only TLS v1.1 or TLS v1.2 might cause interoperability issues.
A second solution is to limit the negotiated cipher suites to exclude those that do not
require symmetric key algorithms in CBC mode. However, this substantially restricts
the number of cipher suites that can be negotiated. That is, only cipher suites with
NULL encryption or cipher suites with streaming encryption algorithms (the RC4
algorithm) could be negotiated.
How to Help Prevent the Attack in SSL-J
In SSL-J, the way to help prevent the attack is to introduce some unknown data into
the encryption scheme, prior to the attackers’ inserted plain text data. This is done as
follows:
1. The first plain text block to be encrypted is split into two blocks. The first block
contains the first byte of the data, with the second block containing the rest.
2. A MAC is generated from the one byte of data, the MAC key, and an increasing
counter. This MAC is included in the first block.
3. The one byte of data along with the MAC is encrypted and becomes the IV for the
next block. Because the IV is now essentially random data, it is impossible for an
attacker to predict it and replace it with one of their own.