Another renegotiation patch

[Daniel Kahn Gillmor]

On 01/22/2010 04:02 PM, Steve Dispensa wrote:
> 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.

Wouldn't that require the client to have initially negotiated to the
attacker, who was posing as the server?  That's basically ruled out by
the convention that TLS server operators are expected to offer an
initial certificate (anonymous/certificate-less servers aren't accepted
by any TLS client i've tried, but i might be trying wrong somehow).

The exploit works as widely as it does because the default mode in most
TLS connections today is that the client *is* initially anonymous from
the server's point of view, right?  Once one side has been authenticated
by their private key (and associated cert), that side of the session
cannot be controlled by an MITM attacker.

A server that demands a client certificate from the first handshake
can't be compromised this way (but of course there's no way for a client
to know that the server they're interacting with holds this policy).

Or is there some other way that this could work in the server-to-client
direction?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100122/03a5dd5f/attachment.pgp>