跳到主要内容
AcoFork Feed

阿里云网关 DPI 阻断绕过漏洞分析报告:TLS Client Hello 分片逃逸

🚨 警告: 提了Bug也没人管,公开了,侵删

阿里云网关 DPI 阻断绕过漏洞分析报告:TLS Client Hello 分片逃逸 #

目标资产: 0721for.me (未备案域名)
解析 IP: 39.107.95.178 (阿里云)
漏洞类型: DPI 深度包检测逃逸 / Fail-Open (失败即放行)
核心原因: 防火墙 DPI 引擎无法正确处理 TCP 分片的 TLS Client Hello 包

1. 结论摘要 #

经深度抓包分析,阿里云网关针对未备案域名的 SNI 阻断策略存在严重的底层实现缺陷。当 TLS Client Hello 数据包大小超过以太网 MTU (1500 字节) 从而触发 TCP 分片时,DPI 引擎会因无法重组报文或解析超时而选择直接“放行”

随着现代浏览器(Chrome/Firefox)和新版工具(Curl)默认启用 后量子加密 (PQC, X25519Kyber768),Client Hello 包大小普遍暴增至 1800+ 字节。这导致正常的现代 HTTPS 流量能够天然绕过监管阻断,而旧版客户端或手动降级的请求反被拦截。

2. 现象对比与证据链 #

我们对比了多种客户端配置下的抓包数据,结果呈现出完美的二元对立:凡是分片的包均绕过,凡是不分片的包均被拦截

客户端环境 TLS 关键特征 包大小 (approx) TCP 分片 结果 原因分析
Chrome / Firefox 默认开启 PQC (Kyber768) ~1900 bytes 绕过 (200 OK) 包过大触发分片,DPI 解析失败导致放行
Curl (Linux 新版) 默认开启 PQC (Kyber768) ~1800 bytes 绕过 (200 OK) 同上
Curl (伪装 TLS 1.2) 伪装 1.2 但带 PQC Key Share ~2400 bytes 绕过 (200 OK) 只要有 PQC 撑大包,版本号伪装也能过
Curl (手动指定) --curves X25519 (禁用 PQC) ~300 bytes ❌ 否 拦截 (RST) 单包完整,DPI 成功提取 SNI 并拦截
Curl (Windows) 旧版/Schannel (无 PQC) ~450 bytes ❌ 否 拦截 (RST) 同上
Firefox (强制 1.2) 纯 TLS 1.2 (无 KeyShare) ~180 bytes ❌ 否 拦截 (RST) 纯 TLS 1.2 包极小,DPI 轻松解析拦截

3. 技术细节分析 #

3.1 核心机制:PQC 撑爆 MTU #

3.2 DPI 缺陷:Fail-Open #

3.3 关键抓包证据 (Wireshark Frames) #

  1. Frame 4251 (Firefox - 绕过):
  1. Frame 964 (Firefox 强制 TLS 1.2 - 拦截):
  1. Frame 568 (伪装 TLS 1.2 - 绕过):

4. 危害与建议 #

  1. 升级 DPI 引擎:必须支持 TCP 流重组(Reassembly),确保能够还原并解析跨包的 TLS Client Hello。
  2. 优化解析逻辑:即使不重组,也可以尝试在第一个分片中尽力提取 SNI(SNI 通常靠前),但这可能容易被 Padding 混淆绕过。最稳妥的方式依然是流重组。