Overview#BEAST is Protocol Client side (ie typically a Browser) Exploit Against TLS 1.0 or earlier and is an applet breaks the "same-origin" policy built into browsers by taking advantage of a flaw in the Oracle/Java software framework.
BEAST is an attack from Duong and Rizzo, and, again, it is a remake of an older attack (from Philip Rogaway in 2002).
How it Works#The BEAST attack is an Exploit targeted at the Cipher Block Chaining CBC encryption against the Predictable Initialization Vector (IV) construction as used in TLS 1.0.as implemented in TLS 1.0 and earlier protocol versions.
To get the idea, consider CBC. In this mode of operation, each block of data is first XORed with the result of the encryption of the previous block; and that's the result of the XOR which is encrypted.
This is done in order to "randomize" the blocks and to avoid the leaks which are found with ECB mode. Since the first block does not have a "previous" block, there must be an Initialization Vector, which plays the role of previous block for the first block.
If an attacker can control part of the data which is to be encrypted, and also can predict the IV which will be used, then he can turn the encryption machine into yet another decryption oracle and use it to recover some other encrypted data (that the attacker does not choose).
However, in SSLv3 and TLS 1.0, the attacker can predict the IV for a record: it is the last block of the previous record ! So the attacker must be able to send some data in the stream, in order to "push" the target data, at a point where the implementation built and sent the previous record (typically when 16 kB worth of data have been accumulated), but did not begin to build the next one.
For SSLv3 and TLS 1.0, a workaround is to send zero-length records: that is, records with a payload of length zero -- but with a Message Authentication Code and padding and encryption, and the Message Authentication Code is computed from a Private Key and over the sequence number, so this plays the role of a random number generator.
Unfortunately, IE 6.0 chokes on zero-length records. Other strategies involve a 1/n-1 split (a n bytes record is sent as two records, one with a single byte of payload, the other with the remaining n-1).
Another workaround is to force the use of a non-CBC Cipher Suite when possible -- the server selects an RC4-based Cipher Suite if there is one in the list of cipher suites sent by the client, even if the client would have preferred a CBC-based cipher suite. This tool can tell you if a given server apparently acts like that.SSLv3 or TLS 1.0.
TLS 1.1 and subsequent versions are protected against this issue because in TLS 1.1 and subsequent versions, a per-record random IV is used.