Re: Rizzo claims implementation attach, should be interesting

Tim Dierks wrote:
> 
> Does anyone have any ideas what Rizzo may be announcing  <at>  ekoparty?
> 
> http://www.ekoparty.org/2011/juliano-rizzo.php
> 
> BEAST: Surprising crypto attack against HTTPS

The first details seem to be leaking:

http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-model-ssl-allows-theft-encrypted-cookies-091611

It seems to be a Man-in-the-Browser attack on SSLv3/TLSv1.0 confidentiality
of ciphers suites with a block cipher in CBC-mode, similar to the original
attack here:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf

The original SSL&TLS protocol was never designed to protect data that
is multiplexed onto a single TLS connection to be protected from each other,
because the traffic-keys are created once per connection.

SSL VPNs, which are an abuse of the SSL&TLS technology clearly beyond
its original design scope, are likely much more difficult to fix than
Web Browsers.  The explicit IVs introduced by TLSv1.1 for block ciphers
with CBC-mode might be an acceptable mitigation, but it is not a clean
solution (because it does not address the underlying design, where the
same symmetric crypto key is reused for data controlled by the attacker.

A Web-Browser with a reasonable design of security zones could try to
ensure that requests originating from different security domains
never re-use network sockets from other domains.  Resuming TLS sessions
from other domains is not a problem, because traffic encryption and
mac keys are regenerated for each connection, so you don't need more
TLS handshakes, only more sockets whose scope for reuse/multiplex
is limited.

TLS cipher suites with stream ciphers (like rc4-128) or with block ciphers
abused as stream ciphers (AES GCM or CCM, i.e. the AEAD cipher suites)
are probably not as much affected, because they do not exactly
"reuse" the exact same secret keys for data of the victim and data
of the attacker, I assume.

-Martin