Re: [TLS] Handshake not under protection

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> Marsh Ray wrote:
> 
>> 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.

The client cert is requested in the renegotiating handshake, not the
initial one.  An anon-anon-DH session provides no "protection" for the
client cert passed in renegotiation.

But it probably makes some people feel more secure to not see the
details (usernames, emails, phone numbers, street addresses) flying by
on the wire.

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

I haven't yet found a client that requires renegotiation before
supplying a client cert.

I have seen common recommendations to have the server ask for it by
renegotiation, as if that were a secure solution.

> 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

Yep.

> -- and
> at that point the application could decide whether it wants to
> reveal its identity to that authenticated server through TLS
> renegotiation.

There are several significant points during the handshake that seem to
require special application-layer processing. Rarely do we see one
callback implemented perfectly, much less for two handshakes!

> Client identity protection through renegotiation _can_ be used in
> a secure fashion.

It could be done securely if the application layer specified its
operation thoroughly.

HTTPS does not, I wonder if any do?

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

That's my point exactly.

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

Seems like the legit server's list of trust anchors would be trivial to
discover.

- Marsh