Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance

[Yoav Nir <ynir at checkpoint.com>]

Below

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).

To calculate the opaque_verify_data field, the MITM would need the  
(pre_)master_secret, and that is encrypted using the server's public  
key. So no, the MITM cannot mess with the extensions.

> In addition, until such time that all clients in the world start  
> supporting this extension (e.g. kiosks in airports), servers will  
> have to support backward compatibility. The MITM can downgrade every  
> client by simply removing the extension from the ClientHello.

They can't downgrade the client, but the client can't expect any  
server to support the extension. Maybe the browser vendors can disable  
the green EV indication for servers that don't support the extension.

>        Yair

Attachment: smime.p7s
Description: S/MIME cryptographic signature