你真的了解HTTPS的加密过程吗

1. 自建CA本地搭建HTTPS

然后配置nginx的ssl，搭建https服务

2. 接下来通过WireShark抓包分析HTTPS协议的交互过程

1. 客户端首先向服务器端发送一个 Client Hello 的 SSL 握手信息。

虽然只有 Client Hello 两个单词，但是其消息体里面包含了丰富的信息，我们在 WireShark 上选择这行记录，并双击，其里面包含了下面的一些主要信息。

（1）Handshake Type：Client Hello（握手类型）。

（2）Random（随机数）和一个时间戳。

（3）客户端支持的加密协议套装。

告诉 HTTPS 的服务器端，客户端能支持上面这 26 种加密协议套装上列出的算法，让服务器选择一个加密协议算法套装。

（4）访问的 Web 服务器的信息：

（5）客户端支持的签名算法：

客户端告诉服务器其支持 9 种签名算法，让服务器端自由选择一个用于后续的加密通信。

2. HTTPS 服务器马上给客户端回复 4 条 SSL 握手信息

HTTPS 服务器马上给客户端回复了下面这 4 条 SSL 握手信息。

Server Hello

Certificate

Server Key Exchange Server

Hello Done

下面具体来看这 4 条由 HTTPS 服务器端发出的 4 条消息里面到底有什么内容，其会告诉客户端什么秘密和信息呢？

（1）Server Hello SSL 握手信息

其重点是把客户端发送给服务器端的随机数又给发送回去了，而且还生成了服务器端的 Session ID 并发送给客户端，最后告诉客户端，服务器端准备选择作为秘钥交互的加密协议套装，该加密协议的套装名字肯定出现在客户端发送给服务器的支持的 26 个列表中，不信你可以翻回去对比一下。

（2）Certificate

SSL 服务器证书信息。在这条 HTTPS 服务器给客户端回复消息 SSL 握手信息里面，其还会把服务器端的 SSL 证书发送给客户端，从上图的转包信息中，我们能清晰地发现服务器端 SSL 证书的相关信息，比如，通用名字为 iis-web-01，组织单元为 it 等。

需要注意的是，如果是 SSL 的双向认证，服务器端也可以要求客户端把 SSL 证书发送给服务器端（对应的 SSL 握手消息名称为：CertificateRequest），这个时候，客户端就会把其 SSL 证书发送给服务器端，从而证明其就是服务器端信任的客户端。

（3）Server Key Exchange 握手消息

HTTPS 服务器出大招了，告诉了客户端其将会采用的 EC Diffie-Hellman 算法进行 HTTPS 服务器和客户端的秘钥交换。具体什么是 EC Diffie-Hellman 算法，大家可以自行查阅资料，这里不再赘述，并提供了 EC Diffie-Hellman 算法使用到的服务器端的参数：

曲线类型：

公钥信息

签名的算法：

签名的信息

（4）Server Hello Done 握手信息

握手信息列表结束了。

3. HTTPS 客户端马上给服务器端回复 3 条 SSL 握手信息

当客户端收到服务器端的相关公钥信息，SSL 证书以及摘要算法和摘要信息后，也不是无动于衷，而是积极的响应了下面的 3 条 SSL 握手信息。

Client Key Exchange

Change Cipher Spec

Encrypted Handshake Message

那么这三条 SSL 的握手信息将会透露出什么？客户端到底想告诉服务器端什么？让我们一一分解。

（1）Client Key Exchange 握手信息

其给服务器端发送了一条用服务器端公钥加密的信息，其里面就包含了预备主密码（Pre-Master secret），其是由客户端随机生成，之后会被用作生成主密码的种子。根据预备密码，服务器和客户端会计算出相同的主密码（Master secret），然后根据主密码生成下面的比特序列（秘钥素材）。

对称密码的秘钥

消息认证码的秘钥

对称密码的 CBC 模式中使用的初始化向量（IV）

需要注意的是，Client 秘钥交换的方式主要有两种，一种是通过 RSA 公钥密码进行交互，这个时候客户端会在发送 ClientKeyExchange 消息时，将经过加密的预备主密码一起发送给服务器。当使用 Diffie-Hellman 交换秘钥的时候，客户端会在发送 ClientKeyExchange 消息时，将 Diffie-Hellman 公开值（Pub Key）一起发送给服务器，根据这个值，客户端和服务器会各自生成预备主密码，而且更加这个预备主密码能够生成相同的对称主密码。

（2）Change Cipher Spec 握手信息

告诉服务器端，我要切换密码了！

（3）Encrypted Handshake Message 握手信息

客户端发出使用主密码加密的结束信息，告诉服务器端：“秘钥交换握手协议到此结束”。

4. HTTPS 服务端马上给客户端回复 2 条 SSL 握手信息

这次轮到服务器端发送“Change Cipher Spec”消息了，服务器告诉客户端：“好，现在我也要切换密码了”。

服务器端用预备主密码（Pre-Master secret）计算出的主秘钥加密了一条信息，并发送给客户端：“好的，秘钥交换握手协议到此结束”。如果通信双方都能把结束消息解密成功，说明主秘钥已经交换成功。就可以发送真正的用主密码加密的应用数据的信息了！

5. 服务端用对称秘钥把加密过的 HTML 网页内容发送给客户端

服务器端用成功交换了秘钥把加密过的 HTML 网页内容发送给客户端，客户端用以前收到过的对称秘钥进行解密，HTTPS 通信协议圆满结束。

上面的步骤只是把我当前环境下抓取到的使用 TL S1.2 协议规范进行了 HTTPS 通信原理和过程的梳理和解释，在不同的环境下，其通信过程会有一些差异，比如，如果配置了双向 SSL 认证，其 SSL 服务器端还会要求客户端把客户端的证书发送到服务端，从而验证客户端是否是可信任的，另外在进行主密码交换的过程中，也可能采用 RSA 公钥密码，而不是 Diffie-Hellman，此时，其 SSL 握手消息会有所不同，但是整体的流程和交互过程思路基本上保持相同。

上述具体流程如下图所示