Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance
On Mon, Nov 09, 2009 at 02:36:47PM +0200, Yoav Nir wrote:
> On Nov 9, 2009, at 2:17 PM, Yair Elharrar wrote:
>
> >The proposed draft is intended to resolve an MITM attack scenario,
> >but is the new extension tamper-resistant?
>
> It's as resistant as TLS is.
>
> >Since the MITM handles all traffic between the real client and real
> >server, it could add a fake extension to the 2nd ClientHello with
> >its original verify_data, and empty the returned extension in the
> >ServerHello.
>
> The Finished messaged at the end of the TLS handshake signs all the
> previous data. Unless the MITM can replicate the server's calculation
> of the opaque_verify_data field, the client will notice that the
> finished message is wrong (it signs an extension that the client did
> not send).
Indeed, the Finished message is the key.
Note that there's no real need for the channel binding to actually be
sent, as in EKR's proposed fix: there's only a need to include it as an
extra input to the PRF call used to construct the Finished messages.
However, by sending the channel binding data as a Hello extension, this
proposal does the least amount of violence to existing implementations.
Nico
--
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.