On 11 Nov 2009 at 10:57, 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, which is not something that is easy to come by > without reading the RFC. (As opposed to the main protocol, where one can > find textbook descriptions.)
I had a hard time with this, too, but this PDF really clarified it for me: <http://extendedsubset.com/Renegotiating_TLS_pd.pdf> Let me try a "layman's" explanation (assuming I have it right) We start assuming the attacker can to hijack or MITM the victim's TCP connections. The attacker opens *its*own* TLS connection to the server [so that is now being encrypted by a symmetric key the attacker picked] and sticks some data into the pipe. The victim wants a TLS connection and so begins negotiating one. The attacker just MITM's that as a *renegotiation* with the server for its TLS connection. (that is, the victim thinks they're negotiating a NEW TLS connection, but the attacker proxies that into a *renegotation* on the existing TLS connection). In short order the attacker is frozen out of the connection [since it will then be encrypted by a key picked by the victim], BUT: the victim's data will ride over the TLS connection that the attacker had previously set up and pre-loaded with some data, and so the victim's data *FOLLOWS* the attacker's -- the attacker was able to inject arbitrary data *in*front* of the victim's data. As I understand it, this is only really a vulnerability in situations where a command to do something *precedes* the authentication to enable the command. The obvious place where this happens, of course, is with HTTPS where the command [GET or POST] comes first and the authentication [be it a cookie or form vbls] comes later. /bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[email protected] Pearisburg, VA --> Too many people, too few sheep <-- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [email protected]
