0

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

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

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

4

3 回答 3

1

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

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

于 2012-10-31T07:03:51.570 回答
1

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

HTTPS 连接的最初几毫秒

于 2012-10-31T07:37:11.393 回答
1

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

然后密码套件确定这些对称密钥最终如何共享。SSL/TLS 握手的直接目的是在客户端和服务器之间建立一个共享的pre-master secret 。这被更广泛地称为密钥交换（参见 RFC 4346 附录 F.1.1，也许还有第 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，它们从中派生一个主密钥（参见RFC 4346 第 8.1 节）。

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

于 2012-10-31T10:14:16.993 回答