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.