On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote: > Anyone care to give a "layman's" explanation of the attack? The > explanations I have seen assume a detailed knowledge of the way TLS/SSL > handle re-negotiation,
The re-negotiation handshake does not *commit* both parties in the new handshake to the previous cryptographic state of the TLS connection. If the man in the middle is willing to encrypt/decrypt handshake packets between a client new to the connection, and a server with which the MITM completed an earlier handshake, the MITM can "transfer" an existing session from himself to the client (victim), after injecting some initial data into the connection. The integrity and confidentiality properties of the origimal MITM<->server connection only protect both parties if neither party is willing to compromise those properties by proxying a 3rd party into the session. The new ingredient here, is that the 3rd party can be a victim, who is unaware of the proxying. The victim's handshake with the intended server is proxied into an already established TLS session by the MITM who is privy to the session state. The solution is to *commit* the two parties to a re-negotiation handshake to the previous handshake. -- Viktor. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com