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

问题描述

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

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

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

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.

问题

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

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

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

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. 客户端生成48个字节的主密码"随机值.
2. 客户端使用随机数据填充这些字节，以使输入等于128字节.
3. 客户端使用服务器的公钥对其进行加密，然后将其发送到服务器.

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

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
)

PRF是伪随机函数"，在 规格，非常聪明.它结合了秘密，ASCII标签和 我们使用keyed-Hash消息给它的种子数据 MD5和SHA-1哈希的身份验证代码(HMAC)版本 功能.输入的一半发送到每个哈希函数.它的 聪明，因为即使面对 MD5和SHA-1的弱点.此过程可以反馈有关自身和 永远迭代以生成所需数量的字节.

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.

按照此过程，我们将获得48个字节的主密码".

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

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