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

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> I've not been told the details of Duong and Rizzo's attack and haven't 
> seen "the BEAST" in action yet, so I'm not sure if that would be 
> sufficient to fix CBC in TLS 1.0. I am slightly annoyed at these guys 
> for dribbling out the information one hint at a time like this.

The "ekoparty conference" is 21-23 Sep., and usually if you get a
paper accepted for a conference, you're not supposed to publish
before the conference...


> 
> Last I checked, the TLS RFC stated explicitly that the protocol defended 
> explicitly against man-in-the-middle attacks. It did not say it defended 
> against "blockwise-adaptive chosen-plaintext" attacks.

It does defend against man-in-the-middle attacks.


> 
> But why split hairs over it? It breaks a basic security properties of 
> the system even if the application designer has done everything 
> according to the recommendations in the spec.

Wrong.  I do not believe that it breaks any of the security properties.
It does break some flawed assumptions.

SSL was NEVER designed with a promise that you could multiplex
data from an evil attack with data from a victim over the very same
SSL connection and be secure against adaptive chose plaintext
attacks trying to recover data from the victim.

>From the SSL design it is quite clear that for CBC encryption, the
encryption key is static for a single connection (=reused for every
cipher block), so mupliplexing data from evil and victim like it
is done in SSL-VPNs or allegedly here by "BEAST" by subverting the
browser security model, that is a clear abuse of the SSL protocol
beyond it's design limitations.

You see it in every episode of Star Trek -- whenever the captain decides
to operate the engines significantly beyond the design limits, the engine
suffers significant damages.  That's not "ficition", it applies similarily
to NASA spacecraft, to aircrafts, vehicles on the road and other products
of technical design.


>
> Since when did "trusted script only" in the application become a
> requirement for transport layer security?

Do NOT run trusted and untrusted data over the very same SSL connection,
because there are no properties in the SSL design to avoid this impairing
the resulting confidentiality.  SSL is no panacea or silver bullet
(never was) and using a technology beyond its design limits is
always a bad idea.


> 
> > Potential server-side mitigation of the problem:
> >
> >    - disable HTTP request pipelining (aka Connect: keep-alive)
> 
> Expensive.

Not for those braindead "secure checkout" or "secure payment" pages
in an otherwise completely unprotected online shop -- which includes
Paypal.


> 
> >    - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0
> >      is negotiated), and use RC4-128 instead.
> 
> Does TLS's use of RC4 still take the first bytes after initialization 
> with the key? Or does it discard the proper amount?

How significant is the RC4 initialization bias for a brief communication
with an SSL-secured checkout / payment ?

(The suggestion was meant to be a mitigation, not a solution)


-Martin