TLS 中间人安全证书

Question

首先，我很抱歉发送了另一个关于此问题的问题，因为有很多相关的帖子。在阅读了它们和相关网站后，我仍然不清楚几点。

1. 浏览器通过安全套接字连接到服务器
2. 服务器用它的公钥和它的证书来响应。这是我最麻烦的一步。在这个从服务器到客户端的消息中，证书可以很容易地与服务器的公钥分开吗？如果它是根证书（已经包含在浏览器中的证书），那么中间人无法伪造它，但如果不是呢？客户端用来验证证书的任何这种在线机制都不能被劫持吗？此外，如果客户端的计算机受到威胁，根 CA 也可能受到威胁，对吗？有什么步骤可以避免这种情况吗？最后一件事：据说证书在签名之前是不安全的。我不知道这意味着什么，尤其是因为证书可以自己签名。我认为这应该意味着有人在保证消息的真实性，所以证书签名本身听起来不安全（“你是真正的证书吗？”......“嗯，当然，我是”）。如果验证证书的机制是互联网，我想知道它是如何安全的。签署证书与（字面意思）说客户端验证证书是否相同？
3. 会话密钥用公钥加密并发送到服务器。此会话密钥是一个对称密钥，服务器和客户端都将用于其余的加密通信。

我必须说，网上的大多数信息都非常模糊。解释和挥手有很多漏洞。我的猜测是很少有人非常了解实际的机制？

Answer 1

您遗漏了几个步骤。其中之一是服务器在整个握手过程中发送一个数字签名，并使用其私钥签名。只有服务器可以使用自己的证书来执行此操作。别人的。客户端使用已发送证书中的公钥验证数字签名。这证明服务器拥有证书。它还证明服务器是发送所有其他握手消息的同一实体。

顺便说一句，您的第 3 步是虚构的。会话密钥根本不会发送。它在两端独立计算。

编辑评论你的答案：

服务器（来自 JoesGoods）通过以下方式从 CA 获得证书？

通常通过 Internet 浏览器。

这可以被劫持吗？

没有任何其他安全 SSL 会话可以做到。

证书已“签名”

正确。

这意味着它的一部分是使用 CA 的私钥加密的。

没有。你编的。

特别是具有 Web 服务器信息的位（JoesGoods 的服务器信息）

没有。你编的。

整个证书是用 CA 的私钥签名的，这并不意味着“加密”。

Bob 的浏览器通过安全套接字连接到服务器并发送“hello”数据包。

此时套接字并不安全。它只是纯文本。

服务器将其公钥和证书发送给 Bob。

没有。服务器发送其证书。公钥已经在证书中。

浏览器检查网络服务器 (JoesGoods) 是否与证书签名部分中的内容相匹配

整个证书都已签名。客户端检查它所连接的服务器是否与证书的 subjectDN 匹配。

网络服务器的公钥也用 CA 的私钥签名

因为它在证书中。否则没有其他方法可以实现这一点。这就是它不单独发送的原因，也是整个证书被签名的原因，而不仅仅是你喜欢的位。

浏览器使用步骤 (2) 中包含的网络服务器公钥向网络服务器 (JoesGoods) 发送客户端密钥交换数据包。

这部分取决于密码套件。您所描述的适用于 RSA 密码套件。 Diffie-Hellman 是一个不同的故事，还有扩展空间以包括其他人。

此客户端密钥用于生成对称密钥以进行剩余的交换。此客户端密钥称为“预主密钥”，是一个随机密钥。由于对称密钥是使用此密钥创建的，我想知道为什么不直接发送对称密钥本身，因为此时连接已加密和验证。

因为它几乎没有那么安全。

这些步骤中的某些步骤也有问题。

当RFC 2246 中已经完全指定了所有这些步骤时，我真的没有看到非正式列举所有这些步骤的意义。互联网上已经有很多关于 TLS 的错误信息，例如this piece of unmaintained drivel。