[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] draft-ietf-tls-renegotation: next
From: David-Sarah Hopwood <david-sarah () jacaranda ! org>
Date: 2009-12-18 5:25:34
Message-ID: 4B2B124E.3030907 () jacaranda ! org
[Download RAW message or body]
Kyle Hamilton wrote:
> Also, it is illegal for any TLS implementation to negotiate
> NULL-NULL-NULL, and it is illegal for any TLS implementation to
> transmit application data after the initial handshake has been
> initiated and before the Finished messages have been generated by both
> sides.
>
> This would suggest that another mitigation for this attack would be to
> include a zero-length application-data packet in all renegotiations;
> if one side thinks it's an initial negotiation, and it receives an
> application data packet under the state that it thinks is
> NULL-NULL-NULL, it is required that it close the connection with a
> fatal handshake_failure alert.
>
> (The only problem with this potential mitigation is that if the client
> is connected to the MITM, and the MITM is connected to the server, the
> MITM could simply strip out the zero-length application-data chunk,
> since TLS relies on underlying mechanisms to verify that it has a
> two-way error-detected/corrected clear channel -- TCP/IP, SPX/IPX, a
> clean serial line, or an MNP5 modem. TLS doesn't try to detect lost
> chunks from the server.)
Unfortunately, this problem is a fatal objection to what was otherwise
a very interesting idea:
- If the extra record is sent before the ChangeCipherSpec of a
renegotiating handshake, then the attacker can strip it out
(because it won't be included in the handshake_messages,
and it doesn't affect the sequence number of messages after the
ChangeCipherSpec, which resets the sequence number to zero).
- If the extra record is sent after the ChangeCipherSpec but
before the Finished message, then (by my reading) the receiving
peer MUST treat this as a fatal error regardless of whether it
believed the handshake was initial or renegotiating.
--
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic