SSL握手期间浏览器如何生成对称密钥答案

【问题标题】：How does browser generate symmetric key during SSL handshakeSSL握手期间浏览器如何生成对称密钥
【发布时间】：2011-04-25 13:32:50
【问题描述】：

在典型的 https web 场景中，我对浏览器和服务器之间的 SSL 握手有点困惑：

到目前为止，我所了解的是，在 SSL 握手过程中，客户端（本例中为浏览器）使用公钥（从服务器接收的证书）加密随机选择的对称密钥。这被发送回服务器，服务器使用私钥对其进行解密（对称密钥）。现在在会话的其余部分使用此对称密钥来加密/解密两端的消息。这样做的主要原因之一是使用对称密钥进行更快的加密。

问题

1) 浏览器如何选择和生成这个“随机”选择的对称密钥？

2) 开发人员（或/和浏览器用户）是否可以控制这种生成对称密钥的机制？

【问题讨论】：

客户端不生成会话密钥；不加密；并且不传输它。会话密钥是通过密钥协商协议导出的。你的描述基本不正确。您的问题建立在错误的假设之上。

标签： ssl random browser-security

【解决方案1】：

Here 很好地描述了 HTTPS 连接建立的工作原理。我将总结一下双方（客户端和服务器）如何获取会话密钥，这个过程被称为“密钥协商协议”，这里它是如何工作的：

客户端生成 48 字节的“pre-master secret”随机值。
客户端用随机数据填充这些字节，使输入等于 128 个字节。
客户端使用服务器的公钥对其进行加密并发送给服务器。

然后双方通过以下方式生成主密钥：

master_secret = PRF(
   pre_master_secret, 
   "master secret", 
   ClientHello.random + ServerHello.random
)

PRF 是“伪随机函数”，也在规范并且非常聪明。它结合了秘密、ASCII 标签和我们使用 keyed-Hash Message 提供的种子数据 MD5 和 SHA-1 哈希的身份验证代码 (HMAC) 版本职能。一半的输入被发送到每个散列函数。它的聪明，因为它对攻击具有相当的抵抗力，即使面对 MD5 和 SHA-1 的弱点。这个过程可以自我反馈并永远迭代以生成我们需要的尽可能多的字节。

按照这个过程，我们得到一个 48 字节的“主密钥”。

【讨论】：

客户端不生成会话密钥；不加密；并且不传输它。会话密钥是通过密钥协商协议派生的。
@EJP 你是对的，我的回答完全不正确，我重写了。请检查一下，如果您认为现在更好，请告诉我。
@user207421，您能否分享有关会话密钥如何生成的更多信息？
@Xilang 检查我更新的答案，我根据 user207421 的评论更正了它。
@honey 它必须为每个会话生成，而不仅仅是每个服务器。

【解决方案2】：

引用网络视频上的这个精彩视频，minute 1:18:07

那么，您从哪里获得计算机上的随机性，因为您的计算机是确定性设备吗？

它会收集熵，比如你的鼠标移动、你的键笔画运动和硬盘的时间，它试图收集所有来自宇宙的随机性都变成了一个拉动，以便它可以为一个连接[此会话]生成随机密钥。如果这种随机性被打破并且它发生了很多次在过去的 30 年里，这些都不起作用。如果对手可以弄清楚您的随机性是多少，然后他们就可以猜出您的密钥。所以使用好的随机性。

注意：密钥是每个会话创建的。

【讨论】：

视频太好了。它回答了我关于网络安全的许多问题。一旦我开始看，我就无法阻止自己看更多。讲师回答任何非安全专家程序员想知道的每个随机问题。我一定会回去再看一遍。
不回答提出的问题。