客户端如何在 SSL 中验证服务器证书？

Question

我阅读了很多关于这个主题的内容，所有“详细”的解释似乎都错过了一步：

为了让客户端验证服务器，它做了以下事情（根据我的理解）：

1. 它从服务器获取证书。证书将包含公钥和数字签名。

2?) 客户端使用公钥验证签名是否正常。

这就是我感到困惑的原因。说我是中间的那个人。我可以连接到服务器并获取服务器提供给我的任何信息，然后将其转发给客户端。客户如何知道谁实际出示了证书？

以下是我也知道的一般情况：

1. 客户端知道公钥。它用它加密一条消息并将其发送到服务器。

2. 服务器知道私钥，解密消息，然后发回。

3. 现在客户端可以与服务器共享对称密钥了。

4. 中间的人可以在场，但没关系，因为没有私钥就无法解密数据。

那么这与证书中的（静态？）数字签名有何关系？

请帮助我理解该特定步骤（验证签名）。

Answer 1

关于流程，我想我可以为您回答这个问题。

1. 客户端发送一个 TLS 请求，其中包含有关它可以支持的信息。

2. 服务器收到它并说我可以支持它并提供由 Verisign 或 Go Daddy 等签名的公钥和服务器证书。

3. 客户端收到它，验证其本地信任存储中的基于有效性的信息，创建一个包含在服务器公钥中的密钥返回给服务器，然后它们形成一个安全的加密通道。 为了让某些人进入 MITM，他们需要拥有带有确切 CN、位置、城市和站点名称等的 CA 根签名证书，这应该是不可能的，因为 CA 没有分配双证书。

Answer 2

一开始，您向证书颁发机构 (CA) 请求证书 通过提供 CSR（由域详细信息和服务器的公钥组成）。

然后CA将通过以下步骤颁发数字证书：

1. CSR 使用哈希算法签名，即 SHA256/md5 生成哈希（CSR）

2. 然后使用其签名者私钥之一对散列后的 CSR 进行加密。即，加密（哈希（CSR））

3. 然后加密(hash(CSR))附加到CSR，我们可以称之为数字证书

数字证书 = CSR + 加密(hash(CSR))

---

证书验证：

服务器在建立 TLS 连接时向用户代理发送证书。

然后用户代理（浏览器）查看证书，检查证书是否来自受信任的 CA。

如果它来自受信任的 CA，那么用户代理会解析证书，我们将在其中获得 CSR 和加密（哈希（CSR））。

4. 现在我们使用散列算法创建 CSR 的散列，我们生成散列（CSR）。

5. Encrypted(hash(CSR)) 使用 CA 的公钥解密。由此，我们将得到 hash(CSR)。

如果步骤 4 中的 hash(CSR) == 步骤 5 中的 hash(CSR)，则验证证书。

有关 TLS 中的密码套件和协商过程的更多详细信息，请参阅 TLS 握手过程。

Answer 3

进一步挖掘后，我发现了我缺少的东西。

服务器提供带有签名的证书文件。我缺少的是“数字签名算法”或类似的算法。

假设 P 是公钥，R 是私钥。

基本上，如果 H 是输入，R 是私钥，我们会得到 C 作为输出。

由于C是数字签名算法的结果，我们可以使用公共P​​和输出C来获得H。

这回答了我的问题的原因是： 假设有人伪装成服务器并且能够准确地重放 C。当然证书看起来是有效的，但是 C 不能继续进行，因为进一步的消息将使用公共 P 加密。

这是我从未见过的答案。

我在这里找到了信息： http://www.jscape.com/blog/what-is-a-digital-signature