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

Question

在典型的https Web场景中,我对浏览器和服务器之间的SSL握手有一点混淆:

到目前为止我所理解的是,在SSL握手过程中,客户端(在这种情况下是浏览器)使用公钥(从服务器接收的证书)加密随机选择的对称密钥.这被发送回服务器,服务器用私钥解密它(对称密钥).现在,在会话的剩余时间使用此对称密钥来加密/解密两端的消息.这样做的一个主要原因是使用对称密钥加速加密.

问题 1)浏览器如何选择并生成这种"随机"选择的对称密钥？

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

Answer 1

以下是HTTPS连接建立如何工作的非常好的描述.我将提供双方(客户端和服务器)如​​何获取会话密钥的摘要,此过程称为"密钥协商协议",此处如何工作:

1. 客户端生成48字节的"预主密钥"随机值.
2. 客户端用随机数据填充这些字节,使输入等于128字节.
3. 客户端使用服务器的公钥对其进行加密,并将其发送到服务器.

4. 然后双方以下列方式生成主密钥:

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

PRF是"伪随机函数",它也在规范中定义并且非常聪明.它结合了秘密,ASCII标签和我们给它的种子数据,使用MD5和SHA-1哈希函数的密钥哈希消息认证码(HMAC)版本.输入的一半被发送到每个散列函数.这很聪明,因为即使面对MD5和SHA-1的弱点,它也能抵抗攻击.这个过程可以自己反馈并永远迭代,以生成我们需要的字节数.

按照这个过程,我们得到一个48字节的"主秘密".