Re: [TLS] Handshake not under protection

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> Ravi wrote:
> >
> > p.s. I prefer not to think of the handshake happening "under protection"
> > of previous session. Another example of this is in current draft which
> > says: "The handshake is in the clear to the attacker but encrypted over
> > the attacker's TLS connection to the server." The handshake itself is
> > always of course is in the clear, certain values in it are encrypted
> > with certain keys. And in some cases this results in binding to previous
> > sessions. This sounds nitpicky, but I only say this because perfectly
> > smart security people with some knowledge of SSL can read sentences like
> > above to assume the entire handshake (including client_random and
> > server_random) is encrypted.
> 
> +1.
> 
> There is no "protection" being provided. People who are thinking
> renegotiation provides real security for client certificates are
> somewhat misguided.

I disagree to this conclusion about client identity protection.

> 
> At the TLS level, it's possible for the current session to be
> anon-anon-DH, which provides no protection.

And which rfc-5246 requires to _not_ request a client certificate:

   7.4.4.  Certificate Request

   When this message will be sent:

       A non-anonymous server can optionally request a certificate from
       the client, if appropriate for the selected cipher suite.

> 
> In practice, client apps will hand over the plaintext client certificate
> to any MitM that asks for it.

Unfortunately, this observation is very true for most of the installed base.

It may easily be wrong for clients that do care about client identity
protection and require a TLS renegotiation before sending a client
certificate.

The client certificate itself is sent with whatever protection the
record layer currently applies (non on an initial handshake) without
any kind of additional protection in a Certificate message from the client
to the server if the server includes a CertificateRequest message
between ServerHello and ServerHelloDone.

At that point, the Server is _not_ authenticated.  The server has
already sent his "Certificate" message (containing the server certificate),
but that could be fake.  Only when the TLS handshake succeeds, the
client knows that the provided server certificate wasn't fake -- and
at that point the application could decide whether it wants to
reveal its identity to that authenticated server through TLS
renegotiation.


Client identity protection through renegotiation _can_ be used in
a secure fashion.  There is no guidance in the TLS spec how to do it,
though, and most existing clients are willing to send a client
certificate in any handshake.  A number of clients will send 
their client certificate to servers on request in the initial
handshake even when the server doesn't indicate that it trusts
one of the trust anchors necessary to verify that client cert.
(But the latter is a mitigation strategy at best).


-Martin