Another renegotiation patch

[Daniel Kahn Gillmor]

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.

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.

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.

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.

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

	--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/6c656275/attachment.pgp>