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?