Client Certificate in SSL HandShake insecure?

Question

Imagine we have an application which is trying to establish a secure connection to a server by using SSL. Now we want the user to authenticate himself with a client certificate which he stores in an secure keystore.

So if I read this specification right the server is sending its certificate during the handshake protocol and is able to demand a certificate from the client with a certificate request, if that's neccessary. Now the user sends his certificate to the server just like the server did before which means in plaintext since no keys were exchanged yet.

What I'm not getting now is, if the client certificate is send in plaintext and the certificate is not bound to a specific device and the public key of the client inside its certificate is not used to generate the symmetric key which is used for encryption later, why is it not possible for an attacker to sniff the handshake protocol between the client and the server, assuming he is sitting in the same wireless lan as his victim? Like that he could see the client certificate, copy it and use it on his own.

So how is this scenario prevented? Of cause the attacker would not be able to change some data of the certificate since he doesn't have the private key the certificate was signed with, but wouldn't it be enough to copy the certificate to steal his victims identity? What am I missing here? Is the certificate bound to the device after all? But I thought it wouldn't since it's just containing some information about the client himself and his public key.

I thought it would be a better idea to send the client certificate after the handshake protocol when a symmetric key was exchanged and the application data is encrypted. I know you could also user additional user credentials like a username and a password but I am just talking about the security of the client certificate now.

So what do you think?

Answer 1

The certificate contains only the public key -- that's public data. The important part is not the Certificate message that the client sends, but the CertificateVerify message which the client also sends. That message contains a digital signature which the client computes using his private key, and over the previous handshake messages. The attacker can sniff all he wants, he will not get the private key, which is not sent, and he will not be able to compute another signature, applicable over another SSL exchange.

Answer 2

Even when the client certificate is visible, the signature made using the private key cannot be forged. Previous answers have given more details about the Certificate Verify message, but the public/private key principle is the same as for server certificates (or asymmetric cryptographic mechanisms in general): if you don't have the private key, you can't impersonate the entity to which the certificate was issued.

A secondary problem of client-certificate authentication is that, if it's done during the initial handshake, the certificate itself is visible to the eavesdropper in clear. In some cases, this may not be satisfactory, since this may reveal the identity of the user (e.g. CN=Bob Smith).

A way to mitigate this is to use client-authentication only in a renegotiated handshake.

Answer 3

The client will sign their message with their private key which can be decrypted using the public key which is openly shared and trusted as corresponding to the client. Since the server can decrypt this information with the public key of the client, it knows the information came from the client. In the event that the next step of the negotiation is RSA, the contents of the packet are a portion of a key encrypted with the server's public key, thus only the server can decrypt the second level of encryption.

As for a rogue user picking up on the certificate and trying to hijack the session, the server has the public key for the user and the attacker will not be able to generate information that will decrypt with that public key, so the connection is guaranteed that the originator of the connection will continue to be the client of the connection.

If the client certificate is not pre-shared, it would be possible to prevent a session from forming with the client and instead substitute an attacker's public key, but at that point the target user would not be in the session and would not have the key information for the session. The same MITM prevention applies as normal server certificate SSL after the initial handshake, the provision of a client certificate simply guarantees the client identity remains the same over one or more sessions.

Answer 4

Also something else to consider. In order to illicit the a client's certificate you need a certificate which has been signed by a Certificate Authority - who's very job is to vouch for who you are. The client should only trust the certificates which have been signed by a reputably CA.