通过抓包分析 HTTPS

自建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

本作品采用《CC 协议》,转载必须注明作者和本文链接
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!