Re: [TLS] Handshake not under protection

[Martin Rex <[e-mail]>]

There seems to be a slight confusion based on me quoting only part
of Marsh' reply, and not the part the confirms the technical possibility
of client identity protection (below).


I confirmed that the restriction in rfc-5246 7.4.4. Certificate Request
"A non-anonymous server can optionally request a certificate from the client"
can not protect against server that wants to elicit a "Certificate"
message from TLS clients in order to reveal the identity of these clients.


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

Correct.  This will protect client identies only from purely
passive observers/attackers.

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


OK.  How about this characterization then:

Although it's technically possible to implement client identity
protection securely with the existing protocol, it is so significantly
underspecified that it makes it unlikely that even those clients
which care about this, implement it in a secure fashion today.

-Martin