TLS男子中间安全证书

Question

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

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

我必须说，网上的大部分信息都是如此模糊。这么多解释和挥手的漏洞都在继续。我的猜测很少有人能够很好地了解实际的机制？

Answer 1

你遗漏了几个步骤。其中之一是服务器到目前为止在整个握手上发送数字签名，并使用其私钥进行签名。只有服务器才能使用自己的证书。别人没人。客户端使用发送的证书中的公钥验证数字签名。这证明服务器拥有证书。它还证明服务器是发送所有其他握手消息的同一实体。

BTW你的第3步是虚构的。会话密钥永远不会发送。它在两端独立计算。

编辑评论您的回答：

  

服务器（来自JoesGoods）通过？

从CA获取证书

通常通过互联网浏览器。

  

这会被劫持吗？

不超过任何其他安全SSL会话。

  

证书已“签名”

正确。

  

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

没有。你做到了。

  

特别是具有网络服务器信息的位（JoesGoods'服务器信息）

没有。你做到了。

整个证书已使用CA的私钥进行签名，并不代表“加密”。

  

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

此时套接字不安全。它只是明文。

  

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

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

  

浏览器检查网络服务器（JoesGoods）是否与证书的签名部分匹配

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

  

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

签名

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

  

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

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

  

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

因为它不会那么安全。

您还有其中一些步骤无序。

在RFC 2246中已完全指定所有这些步骤时，我真的没有看到非正式地列举这些步骤的重点。关于在互联网上漂浮的TLS已经有足够的错误信息，例如this piece of unmaintained drivel。