SSL握手期间浏览器如何生成对称密钥 [英] How does browser generate symmetric key during SSL handshake

问题描述

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

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

问题

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

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

解决方案

这里 很好地描述了 HTTPS 连接建立的工作原理.我将总结双方(客户端和服务器)是如何获取会话密钥的，这个过程被称为密钥协商协议"，它是如何工作的:

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

4. 然后双方通过以下方式产生主密钥:

   master_secret = PRF(pre_master_secret,主秘密"，ClientHello.random + ServerHello.random)

<块引用>

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

按照这个过程，我们获得了一个 48 字节的主密钥".

I have a small confusion on SSL handshake between browser and server in a typical https web scenario:

What I have understood so far is that in the process of SSL handshake, client (browser in this case) encrypts a randomly selected symmetric key with the public key (certificate received from server). This is sent back to the server, server decrypts it (symmetric key) with the private key. This symmetric key is now used during rest of the session to encrypt/decrypt the messages at both the ends. One of main reasons to do so is given as faster encryption using symmetric keys.

Questions

1) How does browser pick and generates this "randomly" selected symmetric key?

2) Do developers (or/and browser users) have control on this mechanism of generating symmetric keys?

解决方案

Here is a very good description of how HTTPS connection establishment works. I will provide summary how session key is acquired by both parties (client and server), this process is known as "a key agreement protocol", here how it works:

1. The client generates the 48 byte "pre-master secret" random value.
2. The client pads these bytes with random data to make the input equal to 128 bytes.
3. The client encrypts it with server's public key and sends it to the server.

4. Then master key is produced by both parties in following manner:

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

The PRF is the "Pseudo-Random Function" that’s also defined in the spec and is quite clever. It combines the secret, the ASCII label, and the seed data we give it by using the keyed-Hash Message Authentication Code (HMAC) versions of both MD5 and SHA-1 hash functions. Half of the input is sent to each hash function. It’s clever because it is quite resistant to attack, even in the face of weaknesses in MD5 and SHA-1. This process can feedback on itself and iterate forever to generate as many bytes as we need.

Following this procedure, we obtain a 48 byte "master secret".

这篇关于SSL握手期间浏览器如何生成对称密钥的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！