This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 39 lines
!!! Overview
[{$pagename}] 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.
[{$pagename}] is an attack from Duong and Rizzo, and, again, it is a remake of an older attack (from Philip Rogaway in 2002).
The [Exploit] was fixed in [TLS 1.1] and later, but at the time of discovery there was effectively no browser support for [TLS 1.1] and newer [TLS] versions.
!! How it Works
TheĀŽ [{$pagename}] 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 [TLS] [protocol] versions.
To get the idea, consider [CBC]. In this mode of operation, each [block] of data is first [Bitwise XOR]ed with the result of the encryption of the previous [block]; and that's the result of the [Bitwise 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.
[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.
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.
Note: BEAST is an attack on the client, but, by selecting an [RC4] [Cipher Suite], the server can protect a careless [Protocol Client].
!! [How To] Beat the [{$pagename}]
__Do not use__ [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 [Initialization Vector] is used.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [BEAST|https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work/20847#20847|target='_blank'] - based on information obtained 2015-03-15