10

If I understood correctly, when using TLS with client authentication, the client certificate is transmitted to the server in plain text. The client certificate might include personal information, (like CN=name, or X509v3 Subject Alternative Name: email:name@server.com), which could be used to identify users connecting to sites secured with https.

Is there a way to securely transmit the client certificate to the server when using TLS client authentication, without exposing personal information?

twobeers
  • 1,079
  • 5
  • 10
  • FWIW TLS 1.3 in 2018 fixes this; (tentative) keyexchange is now completed and encryption enabled before authentication is done (kind of like SSH but for both directions) – dave_thompson_085 Dec 12 '18 at 04:04
  • See also [Does a client certificate identify the owner to unrelated websites?](https://security.stackexchange.com/questions/199515/does-a-client-certificate-identify-the-owner-to-unrelated-websites): the threat isn't just leaking to an eavesdropper but also to a third party website. – Gilles 'SO- stop being evil' Dec 12 '18 at 07:12

1 Answers1

9

It is possible:

  • Server and client negotiate SSL without client certificate requirement
  • Encrypted communications begin
  • Server sends Hello Request to ask for a renegotiation, this one encrypted
  • Client willing, another handshake ensues
  • Server sends a Certificate Request to trigger client certificate authentication
  • (Encrypted) handshake continues normally, and client certificate is protected by TLS.

I don't know how easily you can convince existing server implementations to do it, but the protocol allows it. I seem to remember that there are other existing reasons and implementations that trigger a renegotiation immediately after the first (unencrypted) handshake finishes.

Updated to reflect @dave_thompson_085's correction, see also his comment regarding TLS 1.3.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 1
    Actually server doesn't sponaneously send ServerHello; it sends HelloRequest and if client agrees the second handshake starts with ClientHello as usual (but with Renegotiation Indication set per RFC 5746); see RFC 5246 7.4.1.1. Although now in 2018 TLS 1.3 (RFC 8446) no longer allows renegotiation at all, but does encrypt authentication on the initial handshake. – dave_thompson_085 Dec 12 '18 at 04:04
  • @dave_thompson_085 good call, thank you for catching me on that. I've updated to include the correction, but I suggest you add a separate answer expanding upon the TLS 1.3 changes, as 1) comments aren't trusted to stay forever and 2) I think that would be an excellent alternate answer. – gowenfawr Dec 12 '18 at 05:00