TLS break

[Bernie Cosell]

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:bernie at fantasyfarm.com     Pearisburg, VA
    -->  Too many people, too few sheep  <--       



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com