握手包括这些（粗略的）步骤：

1. 服务器发送它的公钥。
2. 客户端使用该公钥加密设置信息，并将其发送回服务器。
3. 服务器解密客户端的提交并使用它来派生共享秘密。
4. 进一步的步骤使用该共享密钥来设置要使用的实际加密。

因此，您的问题的答案是，由于冒名顶替者无法执行第 3 步（因为它没有私钥），它永远无法进入第 4 步。它没有共享秘密，所以它可以t 完成握手。

Asudhak，如果这有点令人困惑，请不要感到难过。发明非对称密码学是数学的一大进步。当人们第一次遇到它时，如果不是完全不可能的话，它似乎非常违反直觉。

当客户端（通常是 Web 浏览器）和服务器（通常是 Web 浏览器）想要建立一个安全的通信通道时，他们会执行所谓的“密钥交换”。

在公共密钥服务器提供给客户端程序中没有任何秘密。它的唯一功能是加密信息。

客户端生成一个只有 Web 浏览器知道的一次性机密密码。然后客户端使用服务器的公钥来加密一次使用的秘密密码。公钥只能加密，公钥不能解密！

客户端可以安全地将这个加密的秘密密码传输到服务器。任何可能截获此密钥交换的中间人都不会获得有用的信息，因为他几乎可以肯定无法解密那一次使用客户端生成并使用服务器的公钥加密的秘密。

服务器，并且只有服务器拥有对应的私钥。服务器的私钥只能用于解密。 服务器的私钥永远不会传输给任何人！

服务器使用私钥解密客户端（Web 浏览器）生成的一次性密码。

客户端和服务器现在都知道了一个其他人都不知道的秘密！

使用这个秘密，他们可以使用任何传统的对称加密算法来加密他们的后续对话，并高度相信通道是安全的。

此外，客户端有一个“证书”存储，其中包含它信任的组织的公钥。如果服务器不提供称为证书的数字文档，其中包含使用受信任组织的私钥加密的哈希值，则实际的 TLS 密钥交换将失败。客户端可以使用这个散列和可信公钥来知道这个服务器被认为是可信的。

当客户端获取服务器公共证书并使用它来加密用于生成主密钥的 PreMasterSecret 时，您将无法完成TLS 握手。

客户端以 ClientKeyExchange 消息进行响应，该消息可能包含 PreMasterSecret、公钥或任何内容。（同样，这取决于选择的密码。）这个 PreMasterSecret 是使用服务器证书的公钥加密的。

客户端和服务器然后使用随机数和 PreMasterSecret 来计算一个共同的秘密，称为“主秘密”。此连接的所有其他密钥数据都来自此主密钥（以及客户端和服务器生成的随机值），它通过精心设计的伪随机函数传递。

请记住，在非对称密码学中，公钥绝不是秘密，通常（假设没有其他缺陷）对攻击者没有用处。

现有的答案谈论使用证书的公钥进行加密，这并不总是实际使用的（尤其是 DSA 或 DHE 密码套件）。（例如，这里有一个包含更多详细信息的答案。）

SSL/TLS 握手的直接目的是在客户端和服务器之间建立一个共享的 pre-master secret。然后将这个预主密钥导出为主密钥，然后导出为加密密钥（和 MAC）。此过程更广泛地称为密钥交换（参见RFC 4346 附录 F.1.1）。

为确保您与正确的一方进行通信，您需要使用支持经过身份验证的密钥交换的密码套件。（默认情况下，匿名密码套件在合理配置中被禁用。）

这种经过身份验证的密钥交换分为两类：

• RSA 密钥交换（例如TLS_RSA_WITH_AES_128_CBC_SHA）：客户端使用服务器的公钥（在证书中找到）加密预主密钥。只有合法的服务器才能用它的私钥解密。

• DHE 密钥交换（例如TLS_DHE_RSA_WITH_AES_256_CBC_SHA，或带有 DSS 证书的密码套件）：进行 Diffie-Hellman 密钥交换。它通常是 Ephemeral DH，具有固定参数（DH，不是 DHE）的变体非常罕见。（拥有基于 RSA 的证书并不意味着 RSA 密钥交换。）服务器对其 DH 参数进行签名，客户端根据服务器证书中的公钥验证签名。由于只有合法服务器能够使用其私钥进行签名，因此交换是经过身份验证的。

一种方法使用加密，另一种使用数字签名，两者都使用证书中的公钥。两者都有相同的最终结果：客户端可以与拥有其证书私钥的服务器独占共享的预主密钥。

（当然，另一点是客户端必须验证它相信证书是有效的并颁发给它想与之通信的服务器，但这些是稍微分开的点。）