首先，由于有太多相关帖子，我很抱歉再次发送有关此问题的问题。阅读了它们和相关网站后，我仍然不清楚几点。
- 浏览器通过安全套接字连接到服务器
- 服务器用它的公钥和它的证书来响应。这是我遇到最多麻烦的步骤。在这个从服务器到客户端的消息中，证书可以很容易地从服务器的公钥中分离出来吗？如果它是根证书(已经包含在浏览器中)，那么中间人就无法伪造它，但如果不是呢？客户端用来验证证书的任何这种在线机制都不能被劫持吗？此外，如果客户端的计算机受到威胁，根 CA 也会受到威胁，对吧？有什么步骤可以避免这种情况吗？最后一件事:据说证书在签名之前是不安全的。我不明白这是什么意思，特别是因为证书可以自行签名。我认为这应该意味着有人正在确保消息的真实性，因此证书签名本身听起来不安全(“你是真正的证书吗？”......“嗯，当然，我是”)。如果用于验证证书的机制是互联网，我想知道它是如何安全的。签署证书等同于(字面上)客户验证证书吗？
- session key 用公钥加密并发送到服务器。此 session key 是一个对称 key ，服务器和客户端都将使用该 key 进行其余的加密通信。
我必须说，网上的大多数信息都非常模糊。解释和挥手中有很多漏洞。我的猜测是很少有人非常了解实际机制？
最佳答案
您遗漏了几个步骤。其中之一是服务器在到目前为止的整个握手过程中发送数字签名，并使用其私钥签名。只有服务器可以使用自己的证书来做到这一点。没有别人的。客户端使用发送的证书中的公钥验证数字签名。这证明服务器拥有证书。它还证明服务器是发送所有其他握手消息的同一实体。
顺便说一句，您的第 3 步是虚构的。根本不会发送 session key 。两端独立计算。
编辑对您的回答的评论:
Server (from JoesGoods) gets a certificate from the CA via?
通常通过互联网浏览器。
Can this be hijacked?
不超过任何其他安全 SSL session 。
The certificate is "signed"
正确。
which means a bit of it is encrypted using the CA's private key.
没有。这是你编造的。
Specifically the bit that has the web server's info (JoesGoods' server info)
没有。这是你编造的。
整个 证书是用 CA 的私钥签署的，这并不意味着“加密”。
Bob's browser connects to server through a secure socket and sends a "hello" packet.
此时套接字不安全。它只是明文。
The server sends its public key and certificate to Bob.
没有。服务器发送其证书。公钥已经在证书中。
the browser checks that the webserver (JoesGoods) matches what's in the signed portion of the certificate
整个证书已签名。客户端检查它连接的服务器是否与证书的 subjectDN 相匹配。
The webserver's public key is also signed with the CA's private key
因为它在证书中。否则没有其他方法可以实现。这就是它不单独发送的原因，也是整个证书被签名的原因，而不仅仅是您喜欢的部分。
The browser sends a client key exchange packet to the webserver (JoesGoods) using the webserver's public key included in step (2).
这部分是密码套件相关的。您所描述的内容适用于 RSA 密码套件。 Diffie-Hellman 是一个不同的故事，并且有扩展空间以包括其他人。
This client key is used to generate symmetric keys to conduct the remainder of the exchange. This client key is called a "premaster secret" and is a random key. Since the symmetric keys are created using this key, I wonder why not just send the symmetric key itself since the connection is encrypted and validated at this point.
因为它不会那么安全。
您还有一些步骤乱序了。
当这些步骤已经在 RFC 2246 中完全指定时，我真的不明白非正式地列举所有这些步骤的意义.互联网上已经有足够多关于 TLS 的错误信息，例如 this piece of unmaintained drivel .
关于security - TLS 中间人安全证书，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19921716/