Wireshark 抓包理解 HTTPS 协议

2024-03-02 13:14:22

Wireshark 抓包理解 HTTPS 协议

HTTPS 简介

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer）协议是 HTTP 协议的安全版，在 HTTP 应用层和传输层加入了 SSL/TLS 层，确保数据传输的安全性，所以 HTTPS 协议并不是什么新的协议，仅仅是 HTTP 协议和安全协议的组合。

HTTPS 协议主要解决如下三个通信安全问题：

窃听风险（eavesdropping）：第三方可以获知通信内容。
篡改风险（tampering）：第三方可以修改通信内容。
冒充风险（pretending）：第三方可以冒充他人身份参与通信。

HTTPS 通过 SSL/TLS 协议解决了上述三个问题，可以达到：

加密数据以防止数据中途被窃取；
维护数据的完整性，确保数据在传输过程中不被改变；
认证用户和服务器，确保数据发送到正确的客户机和服务器；

既然安全问题是 SSL/TLS 保证的，那么就有必要仔细探索下 SSL/TLS 协议的机制，如下为 HTTPS 通信的整个网络协议栈，其中 SSL/TLS 协议又分为两层：

握手协议（SSL Handshake Protocol）：它建立在记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。

关于更多 SSL 和 TLS 知识见之前的文章: 基于 OpenSSL 生成自签名证书。

SSL/TLS 通信过程

开始加密通信之前，客户端和服务器首先必须建立连接和交换参数，这个过程叫做握手（handshake）。SSL/TLS 握手其实就是通过非对称加密，生成对称加密的 session key 的过程。

假定客户端叫做爱丽丝服务器叫做鲍勃，整个握手过程可以用下图说明：

整个握手过程通俗地说分为如下五步（真实的过程涉及的细节比这个多）：

第一步，爱丽丝给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
第二步，鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
第三步，爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。
第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。
第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。

SSL 握手的过程为双方发送消息的过程，这里所说的消息并不是一个独立的 TCP 数据包，而是 SSL 协议的术语。根据服务端实现的不同，可能一个 TCP 包中包含多条消息，而不是每条消息单独发送（每条单独发送效率太低），这个我们后面通过 Wireshark 抓包可以看到。

下图为双方握手过程中互相发送的 SSL 消息：

客户端发送的初始消息

Client Hello 消息

客户端发送 Client Hello 消息给服务端来初始化会话消息，该消息包含如下信息：

Version Number: 客户端发送它所支持的最高 SSL/TLS 版本。版本 2 代表 SSL 2.0，版本 3 代表 SSL 3.0，版本 3.1 代表 TLS。
Randomly Generated Data：一个 32 字节的客户端随机数，该随机数被服务端生成通信用的对称密钥（master secret）；
Session Identification ：session ID 被客户端用于恢复之前的会话（只有恢复 session 时该字段才有值），这样可以简化 SSL 握手过程，避免每次请求都建立新的连接而握手，握手过程是需要消耗很多计算资源的。已建立的连接信息存储在客户端和服务端各自的 session 缓存中，用 session ID 标识；
Cipher Suite: 客户端发送它所支持的加密套件列表；
Compression Algorithm: 压缩算法，目前该字段几乎不在使用；

服务端响应

Server Hello 消息

服务端回复 Server Hello 消息给客户端：

Version Number：服务端发送双发所支持的最高的 SSL/TLS 版本；
Randomly Generated Data：一个 32 字节的服务端随机数，被客户端用于生成通信用的对称密钥（master secret）；
Session Identification：该字段有如下三中情况：
New session ID：客户端和服务端初次建立连接时生成的 session ID。或者客户端尝试恢复 session，但是服务端无法恢复，因此也会生成新的 session ID；
Resumed Session ID：和客户端发送的恢复会话 ID 一致，用于恢复会话；
Null：该字段为 Null，表明这是一个新的 Session，但是服务端不打算用于后续的会话恢复，因此不会产生 session ID，该字段为空；
Cipher Suite: 服务端发送双发支持的最安全的加密套件；
Compression Algorithm：指定双方使用的压缩算法，目前该字段几乎不在使用；

Server Certificate 消息

服务端发送自己的 SSL 证书给客户端，证书中包含服务端的公钥，客户端用该证书验证服务端的身份。

Server Key Exchange 消息

这个消息是可选的，该消息主要用来传递双方协商密钥的参数，比如双方使用 Diffie-Hellman (迪菲) 算法生成 premaster secret 时，会用该字段传递双方的公共参数。所以具体该字段是什么内容取决于双方协商密钥的加密套件。

Client Certificate Request 消息

这个消息也是可选的，只有当服务端也需要验证客户端会用到。有的安全度高的网站会要求验证客户端，确认客户的真实身份，比如银行之类的网站。

Server Hello Done 消息

服务器发送 ServerHelloDone 消息，告知客户端服务端这边握手相关的消息发送完毕，等待客户端响应。

客户端回复

Client Certificate 消息

如果服务端发送了 Client Certificate Request 消息，那么客户端会发送该消息给服务端，包含自己的证书信息，供服务端进行客户端身份认证。

Client Key Exchange 消息

根据协商的密钥算法不同，该消息的内容会不同，该消息主要包含密钥协商的参数。比如双方使用 Diffie-Hellman (迪菲) 算法生成 premaster secret 时，会用该字段传递双方的公共参数。

Certificate Verify 消息

该消息只有在 Client Certificate message 消息发送时才发送。客户端通过自己的私钥签名从开始到现在的所有发送过的消息，然后服务端会用客户端的公钥验证这个签名。

Change Cipher Spec 消息

通知服务器此消息以后客户端会以之前协商的密钥加密发送数据。

Client Finished 消息

客户端计算生成对称密钥，然后使用该对称密钥加密之前所有收发握手消息的 Hash 值，发送给服务器，服务器将用相同的会话密钥（使用相同方法生成）解密此消息，校验其中的Hash 值。该消息是 SSL 握手协议记录层加密的第一条消息。

服务端最后对客户端响应

Change Cipher Spec 消息

通知客户端此消息以后服务端将会以之前协商的密钥加密发送数据。

Server Finished 消息

服务器使用对称密钥加密（生成方式与客户端相同）之前所发送的所有握手消息的hash值，发送给客户端去校验。

至此 SSL 握手过程结束，双发之后的通信数据都会用双方协商的对称密钥 Session Key 加密传输。

下图为 SSL/TLS 通信的整个过程：TCP 三次握手 + SSL/TLS 握手：

Wireshark 抓包分析 SSL/TLS 握手过程

本节使用 wireshark 抓包工具分析一个完整的 HTTPS 通信过程，看看通信过程中双方消息是如何传送的。前面我们说过，根据服务端实现的不同，可能一个 TCP 包中包含多条 SSL/TLS 消息，而不是每条消息单独发送（每条单独发送效率太低）。

使用如下 wireshark https 包过滤器:

tcp.port==443 and (ip.dst==104.18.40.252 or ip.src==104.18.40.252)

下面为 Wireshark 抓取的 https 流量包，展示了整个通信过程：建立 TCP 连接 --> SSL/TLS 握手 --> 应用数据加密传输：

上面是一个实际的 SSL/TLS 握手过程，分为如下 5 步：

客户端发送 Client Hello 消息给服务端；
服务端回应 Server Hello 消息；
服务端同时回应 Server Certificate、Server Key Exchange 和 Server Hello Done 消息；
客户端发送 Client Key Exchange、Change Cipher Spec 和 Client Finished 消息；
服务端最后发送 Change Cipher Spec 和 Server Finished 消息；

下面我们分步分析每个阶段的包的内容，看是否和前面的理论一致。

客户端发送 Client Hello 消息给服务端

可以看出 TLS 协议确实分为两层：TLS 记录层、TLS 握手层，其中 TLS 握手层基于 TLS 记录层。

另外客户端发送的 Client Hello 消息当中包含的信息也可以看到：

Version：客户端支持的 TLS 版本号；
Random：客户端生成的 32 字节随机数；
Session ID：会话 ID；
Cipher Suites：客户端支持的加密套件列表；
Compression Methods：客户端支持的压缩算法；

服务端回应 Server Hello 消息

Server Hello 包含如下信息：

Version：双方支持的 TLS 版本号；
Random：服务端生成的 32 字节随机数；
Session ID：会话 ID；
Cipher Suites：双方协商的加密套件；
Compression Methods：压缩算法；

服务端同时回应 Server Certificate、Server Key Exchange 和 Server Hello Done 消息

可以看出每个 TLS 记录层是一个消息，服务端同时回复了有 3 个消息：Server Certificate、Server Key Exchange、Server Hello Done。

从 Server Key Exchange 消息可以看出双方密钥协商使用的是 Diffie-Hellman (迪菲) 算法，该消息用于传递 Diffie-Hellman (迪菲) 算法的参数。

客户端发送 Client Key Exchange、Change Cipher Spec 和 Client Finished 消息

可以看出客户端同时回复了 3 个消息：Client Key Exchange、Change Cipher Spec 和 Client Finished 消息。Client Key Exchange 的内容为 Diffie-Hellman (迪菲) 算法的参数，用于生成 premaster key，然后和双方之前的随机数结合生成对称密钥。

服务端最后发送 Change Cipher Spec 和 Server Finished 消息

服务端最后发送 Change Cipher Spec 和 Server Finished 消息，至此 SSL/TLS 握手完毕，接下来双方会用对称加密的方式加密传输数据。

码农公寓

Wireshark 抓包理解 HTTPS 协议