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

[Martin Rex <[e-mail]>]

Martin Rex wrote:
> 
> Marsh Ray wrote:
> > 
> > >    - 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?
> > 
> > I believe there was a mitigation put in place by OpenSSL: sending an 
> > empty (just padding) message before each app data message. The document 
> > at eprint.iacr.org/2006/136 suggests that this could be a server-side 
> > only change. I don't see how that would work since the session cookie 
> > recovery attack is clearly happening on the client->server channel.
> > 
> > I read somewhere that this mitigation was off by default in OpenSSL 
> > because it some software (an old MSIE IIRC).
> 
> Why using a EMPTY (just padding) SSL record?  That looks like an
> obvious untested border case.
> 
> How about using an initial SSL record with one byte of real data
> for SSLv3 and TLSv1.0 SSL with CBC cipher suites?
> 
> Since the (H)MAC is using a secret MAC key and directly following the
> data (the CBC padding is at the end), there will be significant
> unknown distortion in the resulting plaintext to make the BEAST
> attack impractical, I assume.  And it could be done immediately
> on the browser side, without having to wait for the Servers
> to implement TLSv1.1.

But this fragmentation should be done ONLY on protected application
data SSL records.  Fragmenting SSL records with handshake messages
(e.g. on TLS renegotiation) is likely to cause significant interop
problems in the installed base. (Yes, I'm aware that fragmenting
handshake records is allowed by the spec, but a significant
number of implementations will break if you do).

-Martin