TLS中间人安全证书
首先，我很抱歉发送另一个关于这个观看的问题，因为有这么多相关的帖子。 通读他们和相关网站后，我仍然不清楚几点。
我必须说，网上的大部分信息都很模糊。 这么多洞在解释和挥手继续。 我的猜测是很少有人知道实际的机制很好？
你遗漏了几个步骤。 其中之一是服务器在整个握手过程中发送一个数字签名，并使用私钥签名。 只有服务器可以用它自己的证书来做到这一点。 没有人的。 客户端使用发送的证书中的公钥验证数字签名。 这证明了服务器拥有证书。 它也证明了服务器是发送所有其他握手消息的相同实体。
顺便说一句你的第3步是虚构的。 会话密钥永远不会发送。 它是在两端独立计算的。
编辑评论你的答案：
服务器（来自JoesGoods）通过CA获得证书？
通常通过互联网浏览器。
这可以被劫持吗？
没有比任何其他安全SSL会话可以。
证书是“签名”的
正确。
这意味着它的一部分使用CA的私钥进行加密。
不，你做到了。
特别是具有Web服务器信息的位（JoesGoods的服务器信息）
不，你做到了。
整个证书都经过签名，并不意味着使用CA的私钥“加密”。
Bob的浏览器通过安全套接字连接到服务器并发送“hello”数据包。
此时插座不安全。 这只是明文。
服务器将其公钥和证书发送给Bob。
不。服务器发送其证书。 公钥已经在证书中。
浏览器会检查Web服务器（JoesGoods）是否与证书的签名部分相匹配
整个证书都经过签名。 客户端检查它所连接的服务器是否与证书的subjectDN相匹配。
网络服务器的公钥也使用CA的私钥进行签名
因为它在证书中。 否则，没有其他办法可以完成。 这就是为什么它不是单独发送的原因，这也是为什么整个证书都被签名的原因，而不仅仅是你喜欢的位。
浏览器使用步骤（2）中包含的Web服务器公钥将一个客户端密钥交换数据包发送到网络服务器（JoesGoods）。
这部分是密码套件相关的。 您所描述的内容适用于RSA密码套件。 Diffie-Hellman是一个不同的故事，并且有扩展的空间可以包含其他人。
此客户端密钥用于生成对称密钥以执行交换的其余部分。 这个客户端密钥被称为“预主密钥”，并且是一个随机密钥。 由于对称密钥是使用这个密钥创建的，我想知道为什么不直接发送对称密钥本身，因为此时连接被加密和验证。
因为它不会那么安全。
你也有一些这些步骤没有秩序。
当我们在RFC 2246中已经完全指定了这些步骤时，我真的没有看到这些步骤非正式地列举。关于TLS已经有很多关于TLS的错误信息，例如这种无法维护的动态链接。
链接地址: http://www.djcxy.com/p/3705.html