Re: [TLS] Handshake not under protection

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> Yes, you are right.  A MitM can not sign the ServerKeyExchange himself,
> but he can just ask the real server to do it.
> 
> But this thread is about sending a client certificate in a renegotiation
> handshake, so there should be no MitM (if the client has validated the
> first handshake).
> 
> Perhaps I misunderstood what was being asked.


Since I re-vived this thread, I'll try a summary of the latest
messages, which were about availability and security of client identity
protection through a TLS renegotiation handshake.


When servers do not ask for client certificates on the initial handshake,
but only during a TLS renegotiation, then this protectes client
identities from passive observers / passive attackers only.

If a client wants to protect his identity from active attackers (MitM)
as well, and only reveal it to selected servers, then this will require

  (1) an initial TLS handshake where the TLS server provides his
      Server certificate

  (2) an app-level determination that the authenticated TLS-Server
      to which the client identity may be revealed

  (3) a TLS renegotiation where the server requests and the client
      sends a client certificate.

 
A DH_anon session will not be sufficient for (1), because it
precludes (2).  The authentication of the Server in (3) happens
much too late (Server.Finished) to be usable for the determination
whether the client may a Certificate message on handshake (3).


-Martin