Re: [TLS] Rizzo claims implementation attach, should be interesting

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> On 09/20/2011 08:42 PM, Martin Rex wrote:
> >
> > But that would also suggest that BEAST is not attacking the
> > Cookie from the Server response, but instead the cookie from a
> > client request.  (If the browser automatically inserts the cookie into
> > arbitrary requests issued by the attackers malware, then this would
> > mean that a serious Cross-Site-Request-Forgery problem in the browser
> > is a prerequisite for the BEAST attack to succeed.
> 
> 
> But such an attack would only need the cookie sent once 
> client-to-server. A GET request which sends the secret cookie would work 
> just fine.  If there happened to be additional request(s) over that 
> channel transmit the adaptive plaintext

That is a vital prerequisite.  The Javascript of the BEAST trojan
would have to be dribbling out SSL records based on the very same
TLS Connection status (and watch that encrypted network traffic
to learn the last Cipherblock in the SSL record that will be used
as IV to the next SSL record in SSLv3&TLSv1.0 in order to fabricate
the next guess for the plaintext (->adaptively chosen plaintext).

But in order for the attack to succeed so fast in guessing
(10 minutes for the PayPal cookie) I would expect that there needs
to be a small block size (3DES-EDE-CBC) plus a fairly low entropy
in that Cookie.   A sensible cookie would be base64-encoded and
contain at least 128-bit strong random (meaning up to 48 bits of
entropy per cipher block and 2-3 blocks to recover).  Much less guessing
if it uses an unsafe low-entropy cookie or a very inefficient encoding
(but more blocks to guess).


> (constructed from the ciphertext 
> block containing secret cookie data), would it actually be a requirement 
> that they re-send the cookie then?

No, one cookie is sufficient if the connection does not abort during
the attack.  But spreading the attack over multiple successive or
parallel requests (one for each cipher block, each request with its own
encryption keys and encrypted cookie) and combinding the results should work.

> 
> Even if there were CSRF restrictions on cookies, would they apply to GET 
> and POST equally?

Since the client needs to send a significant number of small SSL records
with stuff that will look like junk to the Server.  The server might be
more patiently with a (dribbling) POST than a GET in this respect.


-Martin