HTTPS会话过程整理

 整体交互图和数据包截图如上。具体分步骤解析如下：

  1、client hello：客户端发送client hello，包含自己支持的TLS版本（服务器从中选择好版本后，客户端不需要再次回复自己也同意，默认就是同意了，不需要显示地回复）、随机数（一会用来计算对称密钥用的）、密码套件（非对称算法使用什么、对称算法用什么、验证数据完整性的算法用什么）；

 

 2、server hello+server certificate+server hello done：服务器回复。这三个内容通常合并为一个数据包来发送。这里注意，有时候服务器也会向client发送ServerKeyExchange消息，消息中包含了服务器这边的EC Diffie-Hellman算法相关参数。此消息一般只在选择使用DHE 和DH_anon等加密算法组合时才会由服务器发出。通常只有这三个消息，具体解释如下：

1）服务器回复server hello，包含自己选择的TLS版本（通常为client hello支持的TLS版本中，最高的那个，如果自己也支持，就选择最高的，否则会从版本列表中找次高的，看自己是否支持。如果都没有，就回复 一个protocol_version警告给客户端，这个警告包含不支持的TLS版本号，以及自己支持的版本。如果还是两边无法协商出来，握手就会失败）、随机数、会话ID、选择的密码套件等；

 

 2）server certificate：服务器发送自己的数字证书，其中，包含服务器的RSA公钥，RSA算法是刚刚选择的非对称算法。发送这个证书还有个重要作用，就是证明自己的身份是合法的，因为里面还包含服务器自己的域名或者组织信息，客户端可以拿去验证服务器证书的真实性和合法性，建立信任链条；

 

 3） server hello done：完成hello；

3、client key exchange+change cipher spec+encrypted handshake message：客户端发送。这三个内容通常是合并在一个报文中的。

1）client key exchange：客户端生成一个预主密钥，并且用服务器证书里面的公钥进行了加密，然后把这个预主秘钥发给了服务器；

2）change cipher spec：我已经使用此预主密钥和我hello报文中的客户端随机数，你hello报文中的随机数，通过伪随机函数（PRF），生成了对称密钥，这也是以后咱们会话的会话密钥，从现在开始，后续会话就进入对称加密的加密状态了；

3）encrypted handshake message：使用会话密钥加密的“Finished”消息；

4、change cipher spec+encrypted handshake message：服务器回复。这两个内容通常是合并在一个报文中的。

1）change cipher spec：服务器用自己的私钥，对客户端发给自己的预主密钥进行解密。然后告诉客户端，我也使用了你给我的预主密钥，我hello报文中的客户端随机数，你hello报文中的随机数，通过伪随机函数（PRF），生成了对称密钥，也就是会话密钥。因为咱俩是基于同样的因子，同样的计算方法得到的这个会话秘钥，所以，我们俩的会话密钥是一样的，以后我们就对称加密了。从这个包开始，后续会话就进入对称加密的加密状态了；

2）encrypted handshake message：使用会话密钥加密的“Finished”消息。

5、握手完成。后续使用刚刚生成的会话密钥，对后续会话进行加密，这是一个对称加密的过程，即从第10个报文开始，就是真正的会话过程了。

 

 

 

 

 

【FAQ】

1、HTTPS 对称、非对称发生在哪里？

TLS握手过程，使用非对称加密（可以选择RSA、ECDHE等非对称算法）来安全地协商一个对称密钥（可以选择AES、DES、3DES等对称算法），然后在后续的数据传输中使用该对称密钥进行加密。

2、HTTPS 握手时，服务器必须从客户端的client hello已有的cipher suites选择套件，不能自己随意拼配么？

在TLS（Transport Layer Security）协议中，服务器确实需要从客户端发送的支持的cipher suites列表中进行选择，而不是随意拼配。选择时，会考虑安全性、性能、兼容性。

3、client hello里面的session id作用

主要是用于帮助服务器和客户端，管理和复用之前建立的会话。1）会话复用；2）快速恢复；3）安全性（Session ID本身并不涉及加密或安全性，但通过有效地管理会话状态，可以提高安全性，例如减少频繁地执行密钥交换可能带来的风险）。比如，client在向server发送ClientHello消息的时候，会传送Session ID给server端，server端收到session Id后会去session缓存中查找是否有相同值。如果找到相同值，则server直接发送一个具有相同session ID的ServerHello消息给client端（此时不必新建Session ID），然后双方各发一次ChangeCipherSpec消息后直接进入Finished消息互发阶段。

4、密码套件中，还有SHA，MD5是干嘛用的？

主要用来做完整性校验用的，保证发的东西没有被改过。

5、后续会话中，每次要发送数据前，都要发一次change cipher spec么？

发送数据之前并不需要每次发送一次ChangeCipherSpec消息。ChangeCipherSpec消息是TLS握手过程中的一部分，用于通知对方从未加密状态切换到加密状态。以下三种情况，会出现多个changecipherspec的情况：1）当出现会话重协商加密参数或者更新会话密钥；2）tls 1.3有一个early data（0-RTT）功能，允许第一次握手就发送加密数据，这种时候服务器也可能收到多个changecipherspec；3）有些错误场景也会引发多个changecipherspec。一些TLS实现可能会实施防护措施，限制changecipherspec的次数。