Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt

[Yoav Nir <[e-mail]>]

On May 6, 2012, at 7:53 PM, Marsh Ray wrote:

> On 05/06/2012 03:49 AM, Mohamad Badra wrote:
>> 
>> I was reading "no need to have an (EC)DH certificate to authenticate the
>> first CCS". In that case, active attacks are possible.
> 
> Right, EH does not resist active attacks. It is possible for an active 
> attacker to learn what the client or server would have sent in the 
> handshake. But any such attack causes the handshake to fail in all the 
> scenarios where TLS currently provides integrity protection, i.e., 
> everywhere except for anon-anon DH connections or a pwned trusted root CA.
> 
> It may be possible to get better guarantees for messages that are sent 
> after the Client Key Exchange or Server Key exchange (such as RFC 4680 
> 'Supplemental Data' messages). But some TLS implementations reportedly 
> do not check these signatures until the Finished messages and many 
> non-browser clients do not even look at the name on the server cert 
> until the handshake is complete.
> 
> This means that the protections offered by EH to client certs is 
> limited. Applications requiring serious security for the content of 
> client certs should still use renegotiation.
> 
> If the client has an interest in protecting the client cert he MUST NOT 
> transmit the client cert until he's fully authenticated the server. 
> Generally this requires renegotiation, but many servers will not allow 
> the client to initiate that.
> 
> Consequently, general purpose clients like web browsers can be tricked 
> into transmitting the client cert to an active attacker. The only thing 
> that can fix that is to change the client behavior to be more strict. In 
> order to avoid breaking existing applications, clients can only become 
> more strict if they are given positive indication to do so. Most forms 
> of negotiation can be falsified by an active attacker at the point the 
> client cert must be sent.

I must be missing something. Here's your modified handshake, and I'm assuming (EC)DHE_RSA or (EC)DHE_ECDSA

      Client                                               Server

      ClientHello (with EH ext)    -------->
                                                    ServerHello2a
                                               [ChangeCipherSpec]
                                                    ServerHello2b
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      [ChangeCipherSpec]
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      Finished                     -------->
                                   <--------             Finished
      Application Data             <------->     Application Data

An active attacker can either move DH public keys between the client and server, but in that case it won't have the shared secret, and so - no certificate
So the active attacker has to perform a different DH with each side. But that means that the ServerKeyExchange from the server signs a different public key from the one the client saw, so that's not valid, and the attacker can't generate one that is appropriate, because it doesn't have the private key for the server certificate.

So regardless of whether ECDSA or RSA keys are used, how can the attacker get the certificate?

Yoav