苟新节

主题

 

为什么 HTTPS 很安全，抓包工具却还能抓到包？ ​

更新: 8/31/2026字数: 0 字 时长: 0 分钟

HTTPS 是安全的（传输内容被加密），但抓包工具仍能“抓到包”，原因在于加密范围和抓包方式不同。

1. HTTPS 到底保护了什么 ​

HTTPS = HTTP + TLS/SSL。 TLS 会加密应用层数据（请求头、Body、Cookie 等），并提供完整性校验和身份认证（通过证书）。 它不加密以下信息：

  • IP 地址、端口
  • 数据包大小、时间、方向
  • TLS 握手中的部分明文信息（如 SNI，可暴露域名）
  • 加密后的密文本身

所以用 Wireshark 这类工具在网络接口上抓包时，你能看到大量 TCP/TLS 数据包在流动，但看不到明文内容，只能看到“有加密流量在传”。这并不违背 HTTPS 的安全性。

2. 传输过程详解 ​

一旦 HTTPS 通信通道建立，客户端发出的每一个 HTTP 请求（Request） 和 服务器返回的每一个 HTTP 响应（Response） 都会经过“客户端加密 → 网络传输 → 服务端解密”以及反向的完整过程。

在 HTTPS 中，数据传输并不是单向的，而是请求与响应两个方向都要独立加解密。客户端上行与服务器下行各使用一把方向独立的对称密钥（均由握手阶段协商出的同一主密钥派生），任何中间环节截获的都只是密文：

1. 客户端发送请求时：

  • 客户端：将真实的 HTTP 请求（包含请求头 Header、URL 路径、Cookie、Body 等）用协商好的对称密钥进行加密，变成密文数据包。
  • 网络传输：密文数据包在互联网上传输（中间节点如路由器、或旁路抓包工具如 Wireshark，都只能看到密文）。
  • 服务器：收到密文后，用对应的对称密钥解密，还原出原始的 HTTP 请求，并交给后端服务处理。

2. 服务器返回响应时：

  • 服务器：处理完请求后，将 HTTP 响应（包含状态码、响应头 Header、返回的 HTML/JSON/图片等）用另一把方向独立的对称密钥进行加密。
  • 网络传输：加密后的响应数据包传回客户端。
  • 客户端：浏览器/APP 收到密文后，用对应的对称密钥解密，拿到明文数据并渲染展示给用户。

2.1 性能与开销问题 ​

你可能会担心：“每个请求都加解密，性能开销不会很大吗？”

HTTPS 采用了非对称加密 + 对称加密结合的方案，完美解决了性能问题：

  • 第一次连接（TLS 握手）：使用非对称加密（RSA/ECC，计算量大，较慢）来验证证书身份，并安全地在双方之间协商出一个“对称密钥”（Session Key）。
  • 后续所有请求/响应（数据传输）：全部使用对称加密（AES/ChaCha20，计算极快，硬件级加速）。现代 CPU 对对称加解密有专门的硬件指令集（如 AES-NI），单次加解密耗时几乎可以忽略不计（微秒级）。

因此，除了第一次握手稍微多耗时几毫秒，后续每一个请求和响应的加解密对用户体验几乎没有影响。

3. 为什么 Charles、Fiddler、mitmproxy 等能看到明文 ​

这些工具通常不是单纯“旁路监听”，而是做中间人（MITM）代理：

  1. 工具在设备上安装并信任自己的根证书（Root CA）。
  2. 客户端（浏览器/App）发起 HTTPS 请求时，代理截获连接。
  3. 代理用自己的证书（由自己的 Root CA 签发）冒充目标网站，发给客户端。
  4. 因为系统已信任这个 Root CA，客户端认为证书合法，建立“加密”连接。
  5. 代理解密流量 → 可以看到/修改明文 → 再重新加密转发给真正的服务器。

本质是：你主动让设备信任了抓包工具的证书，相当于自己打开了“后门”。 这不是 HTTPS 协议被破解，而是信任链被人为破坏。

3.1 正常 HTTPS 通信（无法被窃听） ​

在未安装抓包工具证书时，任何试图拦截数据的第三方都会被浏览器拒绝：

[ 客户端 / 浏览器 ]                                         [ 目标服务器 ]
        │                                                         │
        ├──────────────── 1. 发起 HTTPS 请求 ────────────────────>│
        │                                                         │
        │<── 2. 返回服务器真实证书 (由权威 CA 签发，如 Let's Encrypt) ─┤
        │                                                         │
  (验证证书合法)                                                  │
  (用服务器公钥加密密钥)                                             │
        │                                                         │
        ├──────────── 3. 发送加密后的会话密钥 (Pre-Master) ────────>│
        │                                                         │
        │<─────────── 4. 使用协商好的密钥进行 TLS 加密通信 ─────────>│

3.2 抓包工具解密流程（中间人攻击 / MITM） ​

开启抓包工具并安装抓包根证书（Root CA）后的全过程：

[ 客户端/APP ]                [ 抓包工具 (Fiddler/Charles) ]            [ 目标服务器 ]
      │                                    │                                  │
      │── 1. 发起 HTTPS 请求 (被拦截) ─────>│                                  │
      │                                    ├──── 2. 伪装客户端发起 HTTPS 请求 ─>│
      │                                    │                                  │
      │                                    │<─── 3. 返回服务器真实证书 ────────┤
      │                                    │                                  │
      │<── 4. 动态生成并返回“假证书” ──────┤  (用服务器真实公钥建立通道 B)   │
      │       (用抓包工具自身 CA 签名)      │                                  │
      │                                    │                                  │
(检查操作系统信任列表)                      │                                  │
(发现已安装该 CA，信任假证书)               │                                  │
(用假证书公钥加密密钥)                      │                                  │
      │                                    │                                  │
      │── 5. 发送通道 A 密钥 ─────────────>│                                  │
      │                                    │                                  │
      │<======== 6. 加密通道 A ===========>│<======== 7. 加密通道 B ==========>│
      │                                    │                                  │
      │  数据用“假密钥”加密                │  数据用“真密钥”加密              │
      │ ─────────────────────────────────> │ ────────────────────────────────>│
      │                                 [ 解密 ]                              │
      │                                 [ 查看/修改明文 ]                      │
      │                                 [ 重新加密 ]                          │

关键节点小结 ​

  • 关键打破点在第 4 步：抓包工具给客户端发的是“假证书”。
  • 关键信任点在第 5 步：由于你预先将抓包工具的根证书安装到了操作系统/设备的受信任列表里，客户端才误以为这张“假证书”是安全合法的，进而完成了密钥交换。

4. 正常网络路径上的抓包 vs 解密 ​

场景能抓到数据包？能看到明文？说明
普通 Wireshark 旁路抓包能否只能看到加密密文
代理类工具 + 信任自定义 CA能能主动 MITM
有服务器私钥或会话密钥能能特殊情况（极少见）
App 开启证书锁定（Pinning）能通常否即使安装了自定义 CA 也会失败

5. 对称密钥是怎么“算”出来的 ​

最终用于加密数据的对称密钥，并不是直接在网络上传输的，而是双方在握手过程中各自在本地“算”出来的。区别只在于：ECDHE 靠双方交换公钥各自计算；RSA 靠客户端加密传一个随机数、双方各自派生。

方式一：DH / ECDHE 密钥交换算法（现代 HTTPS / TLS 1.3 标准） ​

这是目前最安全、应用最广的方式（具备前向安全性）。它的神奇之处在于：双方在公开的网络上交换参数，即使黑客抓包拿到了所有传输的数据，也绝对算不出最终的对称密钥。

生成流程： ​

  1. 客户端生成临时私钥 A，通过数学公式算出公钥 A'，把公钥 A' 发给服务端。
  2. 服务端生成临时私钥 B，通过数学公式算出公钥 B'，把公钥 B' 发给客户端。
  3. 各自计算：
  • 客户端用 自己的私钥 A + 服务端的公钥 B'→算出对称密钥 K。
  • 服务端用 自己的私钥 B + 客户端的公钥 A'→算出对称密钥 K。

数学原理：基于椭圆曲线或离散对数难解性。公式满足 (gA)B=(gB)A=gAB 。网络上传输的只有 gA 和 gB ，黑客在不知道 A 或 B 的情况下，无法算出 gAB 。

提醒：双方交换的公钥本身是公开的，公钥的真实性必须靠证书 / CA 签名保证——这正是第 3 节所说“抓包工具利用被信任的自签 CA 进行中间人攻击”的前提。

方式二：RSA 非对称加密算法（较早期的 HTTPS / TLS 1.2） ​

这种方式比较直观，属于“一方生成，加密传给另一方”：

生成流程： ​

  1. 服务端将自己的公钥（包含在 CA 证书里）发送给客户端。
  2. 客户端在本地随机生成一个随机数（称为 Pre-Master Secret，预主密钥）。
  3. 客户端用服务端的公钥对这个随机数加密，发送给服务端。
  4. 服务端用自己的私钥解密，拿到这个随机数。
  5. 双方各自用这个相同的随机数（加上前面握手时传输的另外两个明文随机数），通过相同的算法衍生出最终的对称密钥。

局限性：如果服务端的私钥未来泄露了，黑客拿到过去抓的所有包，就能解密出 Pre-Master Secret，进而解密历史所有流量。因此 TLS 1.3 已废弃此方式，全面转向 ECDHE。

核心小结 ​

机制谁生成的？怎么让对方知道的？
ECDHE 算法 (主流)双方各自生成各自的临时私钥/公钥。双方互相发送公钥，然后各自用数学公式在本地算出同一把对称密钥。
RSA 算法 (传统)客户端在本地生成随机数（预主密钥）。客户端用服务端公钥加密后传给服务端，服务端用私钥解密拿到。

总结： HTTPS 保证的是“在正确验证对方身份的前提下，内容不被第三方窃听/篡改”。抓包工具能抓到包，是因为它们要么只看到密文，要么通过你信任的中间人证书主动解密。协议本身并没有失效。