自建CA本地搭建https

//第一步，为服务器端和客户端准备公钥、私钥
# 生成服务器端私钥
openssl genrsa -out server.key 1024
# 生成服务器端公钥
openssl rsa -in server.key -pubout -out server.pem

//第二步，生成 CA 证书
# 生成 CA 私钥
openssl genrsa -out ca.key 1024
# X.509 Certificate Signing Request (CSR) Management.  ca证书签名请求
#要求填写一些资料。Common Name是能访问的域名
openssl req -new -key ca.key -out ca.csr

# X.509 Certificate Data Management.    生成ca证书
openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt

//第三步，生成服务器端证书
# 服务器端需要向 CA 机构申请签名证书，在申请签名证书之前依然是创建自己的 CSR 文件
openssl req -new -key server.key -out server.csr
# 向自己的 CA 机构申请证书，签名过程需要 CA 的证书和私钥参与，最终颁发一个带有 CA 签名的证书
openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.cr

之后再配置nginx的ssl即可

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

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

image.png

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

enter image description here

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

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

enter image description here

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

enter image description here

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

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

enter image description here

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

enter image description here

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

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

enter image description here

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

• Server Hello
• Certificate
• Server Key Exchange Server
• Hello Done

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

（1）Server Hello SSL 握手信息

enter image description here

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

（2）Certificate

enter image description here

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

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

（3）Server Key Exchange 握手消息

enter image description here

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

• 曲线类型：named_curve: secp256r1
• 公钥信息
• 签名的算法：rsa_pkcs1_sha1
• 签名的信息

（4）Server Hello Done 握手信息

握手信息列表结束了。

enter image description here

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

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

enter image description here

• Client Key Exchange
• Change Cipher Spec
• Encrypted Handshake Message

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

（1）Client Key Exchange 握手信息

enter image description here

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

• 对称密码的秘钥
• 消息认证码的秘钥
• 对称密码的 CBC 模式中使用的初始化向量（IV）

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

（2）Change Cipher Spec 握手信息

enter image description here

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

（3）Encrypted Handshake Message 握手信息

enter image description here

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

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

enter image description here

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

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

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

enter image description here

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

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

上述具体流程如下图所示

7042f5c3d9e3437d5b0b30b30f43c802.jpg