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

[Marsh Ray <[e-mail]>]

On 09/20/2011 09:45 AM, Martin Rex wrote:
>
> But really, the underlying problem is letting an attacker reuse
> the very same symmetric key for his own data (adaptive chosen plaintext).
> Knowing the IV ahead of time can significantly improve an adequate choice
> of plaintexts, which is why the problem is worse in SSLv3 and TLSv1.0.
>
> But it should really be possible for browsers to seperate the TLS sockets
> that evil code can use and the sockets that victim code can use safely.

If only applications would set the 'evil bit' it would make a lot of 
things simpler!

But we can't add that as a new requirement for the existing protocols.

> Sharing cached TLS sessions is not a problem, each connection will
> derive their own traffic encryption and mac keys.  If Browsers can not
> seperate those network traffics, then there will be much more serious
> problems in the browser architecture to worry about than an attack
> that requires a cooperating network sniffer and malware running in
> your browser and a significant amount of network traffic between
> them.

People keep thinking of this in terms of a compromised endpoint attack. 
Bard 2004 even talks about requiring a "trojan horse plug in" to be 
practical. Bard 2006 reduces that to a malicious Java applet.

But I'm not convinced. Basic HTTP and browser behavior still leaves a 
lot of room for creativity. When the corresponding flaw was identified 
in IPsec it was not so easily dismissed on the basis that it required a 
compromised endpoint. From what I hear, TLS is used for VPN trunking too.

What about SMTP/POP/IMAP over TLS? They have similar amounts of known 
plaintext as HTTP, and an attacker may have the ability to control a 
large volume of messages, perhaps even in both directions.

- Marsh