BurpSuite 代理原理 和 证书钉扎检测技术

目录

• HTTP协议抓包
• HTTPS协议抓包
• WebSockets协议了解
• 证书钉扎（Certificate Pinning）

---

BurpSuite是一个手动Web安全测试工具，主要通过拦截HTTP、HTTPS、WebSockets这三种网络流量给安全测试者可以便捷分析流量中所呈现的问题。

下面主要讨论HTTP、HTTPS的流量转发过程，经过的节点。

HTTP协议抓包

这个协议的流程是最简单的。

1. 浏览器根据代理设置，将原本要发往 example.com:80 的 HTTP 请求包，发送给了本地的 127.0.0.1:8080 (Burp)。

2. Burp 接收到请求，这是其可以拦截和查看明文数据的关键。

3. Burp 以自己的网络身份（源IP变为Burp主机的IP，即 192.168.1.100）将请求原样或修改后转发给真正的目标服务器 93.184.216.34:80。

4. 目标服务器处理请求，并将响应发送回请求的源地址，即 192.168.1.100（Burp所在机器）。

5. 操作系统将收到的响应数据包交给监听端口的 Burp。

6. Burp 将响应返回给浏览器。

---

HTTPS协议抓包

这个协议的流程稍微复杂些。需要理解 Burp Suite 是如何作为中间人介入这个过程的。其核心在于，Burp 需要让浏览器信任Burp“伪造”的证书。

如下主要介绍，服务器证书和Burp证书分别做了什么操作。

先复习一下无代理的HTTPS流程：

下面的流程主要是浏通信双方共同计算出一个相同的会话秘钥，用于对称加密 。

sequenceDiagram
participant C as 浏览器
participant S as 服务器

Note over C, S: TLS 握手开始
C->>S: 1. Client Hello<br/>（支持加密套件、随机数C）
S->>C: 2. Server Hello<br/>（选择加密套件、随机数S）<br/>+ Server Certificate<br/>（服务器证书）
Note right of C: 浏览器验证证书：<br/>1. 颁发者CA是否可信？<br/>2. 域名是否匹配？<br/>3. 是否在有效期内？
C->>S: 3. Pre-Master Secret<br/>（用证书公钥加密）
Note over C, S: 双方根据随机数C、S、Pre-Master<br/>计算出相同的会话密钥
S->>C: 4. Finished<br/>（用会话密钥加密）
C->>S: 5. Finished<br/>（用会话密钥加密）
Note over C, S: 安全通道建立完成！
C->>S: 应用数据传输<br/>（全部用会话密钥加密）

对上图关键步骤的说明：

Server Certificate (服务器证书)：

• 它是什么？ 一个数字文件，由公共可信的证书颁发机构 (CA)签发。

• 它的作用？做身份认证：向浏览器证明“我就是 example.com”，而不是一个钓鱼网站。

• 携带公钥：证书内包含了用于加密的公钥。浏览器会用这个公钥来加密信息，只有持有对应私钥的真正服务器才能解密。

• 浏览器如何验证它？ 浏览器和操作系统中都预装了一个可信CA根证书列表。浏览器会检查收到的服务器证书是否由这个列表中的某个CA签发。如果是，则证书可信；如果不是，浏览器就会弹出严重警告。（需要先理解证书信任链流程。）

Pre-Master Secret ：

• 由浏览器生成一个随机值（Pre-Master Secret），用服务器证书里的公钥加密后，发送给服务器。

• 只有拥有对应私钥的服务器才能解密它。随后，双方利用这个值和之前交换的随机数，各自生成完全相同的会话密钥。

会话密钥 (Session Keys) ：

• 生成会话秘钥后，所有的应用数据（HTTP请求/响应）都将使用这个对称的会话密钥进行加密和解密。

• 对称加密比非对称加密（公钥私钥）快得多，适合大量数据传输。

有代理的HTTPS流程：

对上图及证书角色的详细解释：

本地证书（Burp Suite 的 CA 根证书）：

• Burp的证书需要你手动安装到浏览器或操作系统中的证书。它由 Burp Suite 自己生成，代表 Burp 自己成为一个私有的、本地的证书颁发机构 (CA)。

• 它的作用？ 建立信任锚点。你告诉浏览器：“这是我的测试工具，我完全信任它颁发的任何证书，请不要报警”。一旦安装并信任此证书，浏览器就会将 Burp CA 加入到它的“可信CA根证书列表”中。（需要先理解证书信任链流程。）

从服务器下载的证书（在 Burp 场景中）：

• 当 Burp 收到浏览器对 https://example.com 的请求时，它会立即同时进行两个独立的 TLS 握手。

• Burp 服务器：Burp 作为一个标准的客户端，与真实服务器完成 TLS 握手。它会收到并验证服务器的真实证书（步骤3）。如果服务器的证书无效（如域名不匹配、由不可信CA签发），Burp 会在 Alerts 标签页向你告警。

• 浏览器 Burp：与此同时，Burp 会动态地、实时地为 example.com 这个域名伪造一个证书。这个假证书的“颁发者”是 Burp CA（步骤4）。

浏览器验证的是谁的证书？

• 浏览器收到的是 Burp 代理发送给浏览器“伪造”的证书（步骤4）。伪造证书的大致流程： Burp拿到真实证书后，截取出证书里的关键字段，Burp用它自己的CA私钥，完全“重新签发”了一张新的假证书。这个新证书里的公钥，是 Burp 自己临时生成的密钥对中的公钥，而不是服务器的公钥。

• 浏览器执行验证流程：“这个证书是给 example.com 的吗？是的。是可信CA签发的吗？我来看看颁发者...哦，颁发者是 ‘PortSwigger CA’（Burp CA），而我已经把这位CA加入信任列表了。所以这个证书没问题！” → 验证通过。

• 因为浏览器信任了 Burp CA，所以它信任 Burp CA 颁发的所有证书。

解密的奥秘：

• 浏览器用 Burp 假证书里的公钥加密 Pre-Master Secret（步骤5）。

• 因为 Burp 伪造了这个证书，所以它持有对应的私钥，因此它可以解密这个 Pre-Master Secret。

• 至此，Burp 就成功截获了这个最关键的参数。然后，它再拿着这个参数，用服务器真实证书的公钥加密，发送给服务器（步骤6）。

• 最终，Burp 和浏览器之间建立了一条加密通道（使用会话密钥①），而 Burp 和服务器之间建立了另一条独立的加密通道（使用会话密钥②）。Burp 坐在中间，可以解密两条通道上的所有流量。

注：企业的网络架构中也会有很多HTTPS流量转发场景，原理是一样的。把企业中的流量代理服务器替换成BurpSuite去代入理解即可。

---

WebSockets协议了解

WebSockets协议是什么？

WEB领域里已经有一个主流通信协议——HTTP了（HTTPS只是加密后的HTTP），为什么还要有WebSockets协议？

因为 HTTP 协议有一个缺陷：通信只能由客户端发起。

WebSockets解决一件HTTP不能完成的事：

WebSockets协议解决了服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话。（这个技术也属于服务器推送技术的一种）

标识符：

协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。

ws://example.com:80/some/path

wss://example.com:80/some/path

协议的数据格式和HTTP类似，但又有所区别，用到在查吧，这里只做一个大致了解即可。

---

证书钉扎（Certificate Pinning）

也称HTTP公钥固定（或称 HTTP公钥钉扎，HTTP Public Key Pinning，缩写HPKP）

证书钉扎指应用程序或服务器不再信任所有根CA，而是预先知道并“锁定”它期望看到的特定证书（或公钥）。

简单来说：服务器使用了白名单校验制度。

这个技术可以有效防止客户端使用中间代理的情况，一般应用在APP领域。

公钥固定原理：

flowchart TD
A[App启动或首次请求] --> B[从服务器获取当前证书链]
B --> C[提取当前证书公钥<br>（或整个证书）]
C --> D[计算其哈希值<br>（如SHA256）]
D --> E{与App内预嵌的<br>可信哈希值比对}

E -- 匹配 --> F[校验成功<br>连接继续]
E -- 不匹配 --> G[校验失败]
subgraph G [失败处理措施]
H[立即终止连接]
I[记录安全事件]
J[向服务器告警]
K[通知用户]
end

对上图流程的详细说明：

1. 预置信任锚点：

   • 在开发阶段，开发人员提取目标服务器证书的公钥（或整个证书）。
   • 计算该公钥的哈希值（例如 SHA-256）。
   • 将这个哈希值硬编码到应用程序的源代码中，或者放在一个配置文件中，然后随应用一起发布。

2. 运行时校验：

   • 当应用程序（或启用了钉扎的浏览器）与服务器建立 HTTPS 连接时，它会照常接收服务器的证书链。
   • 在完成了标准的证书验证（检查域名、有效期、CA签名等）之后，钉扎逻辑会额外执行以下操作：
     • 从服务器发送来的证书中提取出公钥。
     • 使用相同的哈希算法（如 SHA-256）计算该公钥的哈希值。
     • 将计算得到的哈希值与应用程序内部预置的哈希值进行比对。

3. 决策与执行：

   • 匹配：如果两个哈希值完全一致，说明服务器提供的证书正是应用程序所信任的特定证书。连接被允许建立，数据传输继续。
   • 不匹配：如果哈希值不一致，即使该证书由全球可信的CA（如 Let's Encrypt, DigiCert）签发且完全有效，应用程序也会立即终止连接。这就是它防御中间人攻击的关键——Burp Suite 生成的假证书，其公钥哈希值绝对不可能与App内预置的真证书公钥哈希值相同。

APP公钥固定 防御过程：

1. 你试图用 Burp Suite 拦截一个启用了证书钉扎的 App 的流量。
2. App 发起 HTTPS 请求，请求被路由到 Burp。
3. Burp 与真实服务器建立连接，获取到服务器的真实证书。
4. Burp 动态生成一个伪造的证书，这个证书的域名虽然正确，但是由 Burp 自己的 CA 签发的，因此其公钥与真实证书的公钥完全不同。
5. Burp 将这个伪造的证书返回给 App。
6. App 的钉扎逻辑启动：
   • 提取伪造证书的公钥。
   • 计算其哈希值。
   • 与内部预置的正确公钥哈希值进行比对。
   • 结果：不匹配！
7. App 立即触发错误，断开连接。你在 Burp Suite 中通常会看到 SSL Handshake Failed、Connection Reset 之类的错误，根本无法看到任何明文流量。

证书钉扎的优缺点：

优点	缺点
极大的增强安全性：有效防止MITM攻击，即使攻击者控制了CA或用户信任了恶意根证书也无济于事。	维护复杂性：服务器证书到期或更换时（尤其是更换CA），必须同时更新客户端App内预置的钉扎信息，否则会导致大规模连接中断。
减少信任依赖：不依赖外部CA系统的绝对安全。	部署风险：如果部署不当（例如只钉扎了一个证书而没有备份），证书失效会导致服务彻底瘫痪。
针对性强：只保护特定的、重要的域名和连接。	安全性并非绝对：如果App本身被逆向分析，攻击者可以提取出预置的哈希值，从而伪造证书（但需要一定逆向、脱壳技术，难度相对高）。

为了平衡安全性和维护性，通常采用以下策略：

• 备份 pin：不仅钉扎当前证书的公钥，还钉扎备份证书的公钥，以防当前证书出现意外。
• 有效期：为钉扎信息设置有效期，超过期限后不再检查，以避免长期失效的风险。
• 报告机制：校验失败时，不仅断开连接，还尝试向服务器发送报告，帮助管理员发现问题。

注：在制定安全方案时，需要考虑的事项。