How serious is this attack?
If the block size is small we could guess all of these blocks.
It turns out though the block size isn't that small.
The parameters we saw were using RC4.
RC4 is a symmetric encryption algorithm.
It at least loosely stands for "Ron's Code 4." That's not what it officially stands for.
But that's what most people think of it as, and this is Ron Rivest--the "R" in RSA
who invented the symmetric encryption algorithm that's known as RC4.
The block size typically used in TLS is 64 bits.
TLS could also be using AES with a block size of 128 bits.
That would mean the attack is only useful
if the attacker can guess those 64 bits in a useful way
and has a way to control the message.
That seems like it might not be much of a threat,
and this attack was actually known.
It was identified by Gregory Bard in 2004 and viewed as not too serious of a problem with TLS,
because it does give an attacker an advantage but these blocks are big enough
that ability to do this--and if you can only guess one more message,
if you can only control the server, you don't have too much power.
It assumes a quite powerful attacker
that has an ability to control the messages the server is going to send.
It turns out that there are very serious implications of this attack.
They depend on being able to inject JavaScript code,
so there are ways that an attacker might be able to control the responses.
Using JavaScript requests, if the attacker controls JavaScript on the page
that the victim is using TLS to request,
that JavaScript can make repeated requests to the root server.
Those are still going to be part of the encrypted session,
but the attacker can control what those requests are
and perhaps can design requests that the server will respond to in a particular way,
giving the attacker control over the first block in the next message.
The other thing the attacker could do is figure out a way
to know many of the bits.
Suppose the attacker knows 58 bits, and there's one byte.
But that byte contains one character of an authentication token
that could be part of a cookie, say.
It turns out that there is an attack that exploits this.
It has the rather clever acronym B.E.A.S.T.--Browser Exploit Against SSL/TLS.
This found ways to use this cryptographic weakness.
It turns out if you can inject JavaScript into the page,
you can control these requests enough to actually use this.
This was demonstrated quite recently in 2011,
showing a way that you could use this and this technique of controlling
many of the bits in the first block to break an authentication token for a PayPal cookie.
This is quite a powerful attacker.
If you only need to guess 8 bits at a time, you expect to only need 128 guesses for each byte.
