Another renegotiation patch

[Steve Dispensa]

On 1/22/10 2:40 PM, "Daniel Kahn Gillmor" <dkg at fifthhorseman.net> wrote:

> On 01/21/2010 03:42 PM, Nikos Mavrogiannopoulos wrote:
>> I was thinking about the safe renegotiation case. Currently with the
>> defaults the client behavior is to drop the connection to servers that
>> do not advertise safe renegotiation... This is quite an inconvenience.
>> How do you think of instead of failing disabling renegotiation for this
>> session? I think this will prevent a lot of people from completely
>> disabling safe renegotiation and only disables the part of the protocol
>> that isn't secure..
> 
> The problem, as i understand it, is that the client is incapable of
> telling whether the plaintext prefix injection attack has already
> happened.  I don't think disabling renegotiation for the session
> resolves the problem.

Right, exactly. (And by the way, it's probably more precise to think of it
in terms of peers; the same attack is theoretically possible in the
direction of the client, but all of the described exploits are in the
direction of the server.)

> 
> For a server which does not announce and enforce safe renegotiation,
> what the client sees as an initial connection may unknowingly actually
> be renegotiating an existing session that was started by an attacker.

Yep.

> 
> The concern isn't that the (legitimate) client will have their session
> re-negotiated by an attacker; it's that the MITM attacker can trick the
> server into viewing the client's initial authentication as a
> re-negotiation of a TLS session already underway.

Right, while it looks like the initial negotiation to the client.

Again, this attack is theoretically possible in the opposite direction,
i.e., where the server sees an initial negotiation but the client thinks
he's renegotiating. Nobody has publicly described a way to attack that
angle, but it's still broken in theory.

> 
> for servers which do odd things like apply the credentials of the
> post-renegotiation client to the traffic that happened before the
> renegotiation (e.g. HTTPS, with client-side certificates required only
> for certain subdirectories), a safe-renegotiation-aware client *should*
> refuse to connect to servers which do not announce safe renegotiation if
> they want to resist this attack.

It's worse than that - you don't want to tweet your password. Think about
the Twitter attack; it's pretty general.

> 
> (i think!  i'm still struggling to get my head around this too, and i'd
> be happy for any corrections)
> 
> --dkg

This is incredibly subtle, and yeah, you've got it.

 -Steve