SSL握手过程[关闭]答案

【问题标题】：SSL handshake process [closed]SSL握手过程[关闭]
【发布时间】：2012-10-20 12:48:28
【问题描述】：

我开始了解安全性并阅读有关 SSL 握手方案的信息。在这个post 中，回复者提到对称密钥是在浏览器上生成的，使用服务器的公钥加密并发送到服务器。

但是，在其他文章中，他们提到生成并发送了一个 pre-master secret，而不是用于计算对称密钥。

我可以知道哪个是正确的解释，以及这个 pre-master secret 是如何生成并用于生成对称密钥的？

【问题讨论】：

【解决方案1】：

您链接到的帖子中的描述只是对协议的简化说明。

客户端生成预主密钥，并在握手过程中使用服务器的公钥对其进行加密。然后双方按照RFC 6101中的方法推导出对称密钥材料，包括IV和MAC密钥。

【讨论】：

【解决方案2】：

下面是一篇描述 SSL/TLS 握手的优秀文章的链接（包括客户端和服务器都使用 pre-master secret 来生成 master secret，用于生成一组会话密钥） MAC 和加密）：

【讨论】：

【解决方案3】：

说浏览器生成对称密钥只是一种简化（至少比说加密是用证书完成的要好）。您可能对 Security.SE 上的this answer 感兴趣，了解更多详情：

然后，密码套件确定这些对称密钥最终如何共享。 SSL/TLS 握手的直接目的是在客户端和服务器之间建立一个共享pre-master secret。这更广泛地称为key-exchange (see RFC 4346 Appendix F.1.1, and perhaps Section 7.4.7)。

这分为两类（不包括匿名密钥交换）：

RSA 密钥交换（例如TLS_RSA_WITH_AES_128_CBC_SHA）：客户端使用服务器的公钥（在证书中找到）加密预主密钥。
DH(E) 密钥交换（例如TLS_DHE_RSA_WITH_AES_256_CBC_SHA）：发生 Diffie-Hellman 密钥交换。服务器对其 DH 参数进行签名，客户端根据服务器证书中的公钥验证签名。（拥有基于 RSA 的证书并不意味着 RSA 密钥交换。）

在握手结束时，无论使用这两个步骤中的哪一个，客户端和服务器都拥有一个共同的 pre-master secret，他们从中派生出一个 master秘密（见RFC 4346 Section 8.1）。

如RFC 4346 Section 6.3 中所述，双方都可以从该主密钥 导出加密密钥（和 MAC 密钥）。

【讨论】：