Wireshark 抓包理解 HTTPS 协议

Wireshark捕获包是HTTPS协议HTTPS概述HTTPS (全名： hypertexttransferprotocoloversecuresocketlayer )协议为HTTP协议的安全版

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

窃听风险第三方可以知道通信内容。篡改风险第三方可以修改通信内容。冒充风险(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的过程。

客户端称为pldzx服务器dbdbh，整个握手过程如下图所示。

整个握手过程，通俗地说可以分为以下五个步骤。 (实际过程涉及比这更多的细节)。

首先，pldzx提供协议的版本号、客户端生成的随机数(Client random )和客户端支持的加密方法。

在步骤2中，dbdbh确认双方正在使用的加密方法，给出数字证书和一个服务器生成的随机数(Server random )。

在步骤3中，pldzx验证数字证书有效，生成新的随机数“Premaster secret”，并使用数字证书的公钥对该随机数进行加密，然后发送给dbdbh。

在第四步中，dbdbh使用自己的私钥获取从pldzx发送来的随机数，即Premaster secret。

步骤5、pldzx和dbdbh基于约定的加密方法，使用上述3个随机数生成用于加密下一个对话过程的“对话密钥”。

SSL握手的过程是双方发送消息的过程。消息是SSL协议的术语，而不是独立的TCP分组。根据服务器端的实现，一个TCP数据包可能包含多个消息。单独发送而不是分别发送每个消息是效率不高的。稍后可以在Wireshark捕获包中确认这一点。

下图是握手过程中发送的SSL消息。

客户端发送的初始消息

客户端帮助消息

客户端向服务器发送包含以下信息的Client Hello消息以初始化会话消息：

Version Number:客户端发送支持的最高版本的SSL/TLS。版本2表示SSL 2.0，版本3表示SSL 3.0，版本3.1表示TLS。随机生成数据(在服务器端生成用于通信的对称密钥)的32字节客户端随机数sessionidentification:session id为客户端恢复以前的会话只有在恢复session时，此字段才包含值。这简化了SSL握手过程，以避免每次请求都建立新连接并握手，并且握手过程需要大量计算资源。建立的连接信息分别存储在客户端和服务器端的session缓存中，并由session ID标识。 Cipher Suite:客户端将发送支持的加密套件列表。 Compression Algorithm:压缩算法，目前很少使用此字段；服务器端响应

服务器帮助消息

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

Version Number :服务器发送双引擎支持的最高SSL/TLS版本； randomlygenerateddata (在32字节的服务器端随机数中，客户端用来生成用于通信的对称密钥)的Session Identification :在该字段中输入New session ID 或者，客户端尝试恢复会话，但服务器端无法恢复，因此也会生成新的会话id；保留s

ession ID：和客户端发送的恢复会话 ID 一致，用于恢复会话；Null：该字段为 Null，表明这是一个新的 Session，但是服务端不打算用于后续的会话恢复，因此不会产生 session ID，该字段为空；Cipher Suite: 服务端发送双发支持的最安全的加密套件；Compression Algorithm：指定双方使用的压缩算法，目前该字段几乎不在使用；

Server Certificate 消息

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

Server Key Exchange 消息

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

Client Certificate Request 消息

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

Server Hello Done 消息

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

客户端回复

Client Certificate 消息

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

Client Key Exchange 消息

根据协商的密钥算法不同，该消息的内容会不同，该消息主要包含密钥协商的参数。比如双方使用 Diffie-Hellman (smdxmy) 算法生成 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) 1

下面为 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 (smdxmy) 算法，该消息用于传递 Diffie-Hellman (smdxmy) 算法的参数。

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

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

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

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