Client-Authentication during TLS/SSL and Replay-Attacks

Question

I have found this explanation about how a Client-Authentication works during SSL-Handshake. So according to oracle a client-authentication works as follow:

1. The Client sends his certificate, random-data and a signiture of that random data to the server.
2. Server verify the signiture of the random-data using the public key in the certificate.
3. The server checks the certificate’s validity period.
4. Server checks if the CA in the certificate is a trusted CA.
5. Server uses the public key of the CA to verify the signiture in the certificate.

After these five steps the User is authenticated.

Question: If an Attacker gets the User certificate, the random-data and the signiture of that random-data, is the attacker able to start a replay-attack?

I think that the random-data must be chellange to prevent against a replay-attack. So what is the common way to authenticate a user by using a client-certificate?

Answer 1

I think you did not fully understand how client authentication works and the article you cite does it describe it only in a simplified way. To cite from this article:

The SSL protocol requires the client to create a digital signature by creating a one-way hash from data generated randomly during the handshake and known only to the client and server.

The import part is that these are not random data generated by the client only but that part of the random data is generated by the client and another random data are generated by the server. Or to say it more correctly: the client signs all messages send and received so far with its certificate. These messages include among others also 256 bit random data generated by the client and another 256 bit random data generated by the the server. See RFC 5246 (TLS 1.2) section 7.4.8 for the details.

If an Attacker gets the User certificate, the random-data and the signiture of that random-data, is the attacker able to start a replay-attack?

Since the signature in the CertificateVerify message also depends on random data generated by the server a replay attack can only be done if the server would use the same random data in a handshake as in a handshake previously sniffed by the attacker. But this can only happen if the random generator in the server is severely broken or if the attacker is extremely lucky because the probability that the server uses exact the same 256 bit random number as in a previous handshake is nearly zero.