SSL证书和身份验证

Question

I've been looking for information about SSL certificates and encryption protocols. I got very good answers, especially on this website.

There's only one thing I don't get. If I got this right, the verification of the identity (I mean the verification of the server identity, not the certificate identity) is made using asymmetric cryptography.

That means the steps would be (stop me if I'm wrong):

• Client uses verified public key to encrypt a random challenge string and send it to server.
• Server decrypts it using its private key and sends it back to the client.
• Client checks if the response from server matches the random challenge string it just sent.

What prevents a fake server to do it like this, with a real certificate for, say, www.example.com but without having the private key?

• Client uses verified public key to encrypt a random challenge string and send it to server.
• Fake server sends the encrypted random challenge string to www.example.com, as a client wanting to check its identity.
• www.example.com sends back the decrypted random challenge string to fake server.
• Fake server sends it back to client.
• Identity is confirmed?

Answer 1

Client uses verified public key to encrypt a random challenge string and send it to server.

The key exchange mode where the client encrypts something with the server's public key is the RSA key exchange mode. There's a full description of it in section F.1.1.2 of the TLS specification .

Essentially, the client generates the pre-master secret, encrypts it with the server's public key (found in the server certificate the server has sent), and sends it to the server (in a Client Key Exchange Message). That's it. Only the server with the matching private key can decipher it. The server doesn't send any deciphered version back to the client, so couldn't ask for a 3rd party to do whatever operation you seem to have in mind with it.

Answer 2

This is just a straw-man argument. The steps you have listed are completely imaginary. The actual steps are:

1. The server sends its certificate as part of the TLS handshake.
2. The server sends a digital signature over its certificate and the other handshake messages, signed by its private key.
3. The client uses the public key in the certificate to verify the digital signature.

Only a server that has the private key corresponding to the public key in the certificate can succeed.

I suggest you do some reading, and not of random postings on the Internet: try the normative reference: RFC 2246 .