引言

在网络抓包和安全审计中，经常会使用抓包工具（如 Burp、Fiddler、charles）来分析 HTTPS 流量。但是，HTTPS 的加密机制和证书验证这部分原理有些摸不清。本文将结合我的学习过程，把抓包代理、根证书以及域名证书梳理清楚。

HTTPS 证书基础

以本网站为例，可以通过浏览器上的安全连接来查看证书信息。

服务器证书

每个 HTTPS 网站都有自己的 SSL/TLS 证书（例如由 Let’s Encrypt 签发）。它主要包含两点：

1. ​公钥和私钥​：私钥保存在服务器上，用于加密/解密 TLS 流量。
2. ​域名信息(CN/SAN)：浏览器通过它确认自己访问的域名是否匹配证书。

其中公共名称 (CN) 和主题备用名 (SAN)

系统/浏览器根证书

• 浏览器和操作系统自带一些受信任的根证书，通常由公认 CA 签发。
• 浏览器验证服务器证书时，会检查证书链是否能追溯到这些根证书。
• 根证书​本身不参与 TLS 流量加密​，也不包含服务器私钥，只用于验证信任链。

不适用代理访问流程

• 浏览器向服务器发起 TLS 握手。
• 服务器提供自己的 Let’s Encrypt 证书（CN/SAN = zunmx.top）。
• 浏览器检查证书链是否由本地信任的根证书签发。
• 浏览器验证域名匹配 → TLS 建立。

使用抓包工具

其原理可以理解为中间人攻击(MITM)

首先需要信任代理工具的根证书，这步很重要。

1. 浏览器到本地代理服务器(这个代理服务器指的是抓包工具)
2. 代理截获请求，根据访问的域名，通过信任的根证书来伪造这个域名的ssl证书【这一步是为了欺骗本地浏览器】
3. 代理发送请求给服务器（这里就是正常访问，和伪造的证书一点关系都没有）
4. 服务器返回数据给代理
5. 代理通过伪造的证书再加密，返回给浏览器

这样浏览器就无法感知到这个服务器是否是正常的，因为你信任了根证书，这个根证书校验通过了你伪造的域名证书，这就形成了一个闭环。

为什么要伪造域名证书

• 浏览器访问 HTTPS 网站时会检查 ​域名是否匹配​。
• 代理工具的根证书本身不包含域名信息，无法直接建立 TLS。
• 所以每次访问一个新域名，代理必须​生成一张 CN/SAN 对应域名的伪造证书​，签发给浏览器，这样浏览器才能信任并完成握手。
• 实际上就是正常网站的ssl证书，搞一个假的，让代理工具（服务器端）使用，浏览器因为信任根证书了，所以才能走通。

理解

​代理充当两面角色​

• 对浏览器是“服务器”，用伪造证书欺骗浏览器
• 对服务器是“客户端”，使用真实证书通信

服务器无感知

• 无论代理解密多少流量，服务器看到的依然是正常 TLS 客户端

图解

上半部分是正常访问
下半部分是代理访问

结语

经常使用这类工具，今天把原理大概摸清了，如果有哪里不对，欢迎指正。