揭露并绕过基于 SNI 的中国防火长城对 QUIC 协议的审查
摘要
尽管 QUIC 握手数据包是加密的，但自 2024 年 4 月 7 日起，中国防火长城（GFW）已开始阻止特定域名的 QUIC 连接。在本研究中，我们对 GFW 对 QUIC 的审查进行了测量和分析，以了解其审查的方式和内容。我们的测量结果表明，GFW 大规模解密 QUIC 初始数据包，应用启发式过滤规则，并使用与其它审查机制不同的黑名单。我们还发现该系统存在一个关键缺陷：解密带来的计算开销使其在中等流量负载下效果降低。此外，我们证明这种审查机制可以被利用来阻止中国境内任意主机与世界其他地区之间的 UDP 流量。我们与多个开源社区合作，将规避策略集成到 Mozilla Firefox 浏览器、quic-go 库以及所有主要基于 QUIC 的规避工具中。
1. Introduction
自 2021 年标准化以来，QUIC 迅速成为一种主要的互联网协议。它现在已成为 HTTP/3 加密的基础[7]，并且在 2024 年，Cloudflare 估计超过 30%的网页请求使用了 QUIC[14]。QUIC 的普及也给审查者带来了问题，他们必须调整以前的技术以适应这种新协议。虽然审查者此前曾完全阻止该协议[25, 70 §5.2]，但首次有用户报告称，中国防火长城（GFW）于 2024 年 4 月开始针对特定域名阻止 QUIC 连接，这与他们基于 SNI 对 TLS 流量进行审查的方式类似[11, 37]。
审查针对特定网站的 QUIC 连接在州一级具有挑战性，因为 QUIC 会加密所有数据包，而 TLS 则不同，其目标服务器名称是以明文形式发送的。在 QUIC 中，即使是第一个握手消息（即 QUIC 客户端初始消息），也是经过加密的，尽管这种加密使用的是被动网络观察者可以推导出的密钥。这意味着，如果审查者想要根据服务器名称指示（SNI）字段阻止 QUIC 连接，就需要解密每个 QUIC 连接的第一个数据包以揭示目标站点。因此，反审查社区有必要了解防火长城（GFW）新的审查设计和实施细节，以便更新规避策略。
在这项工作中， 1 我们测量了中国对 QUIC 连接进行检查和阻止的新能力——这是首次针对 QUIC 连接的大规模全国性检查和定向审查。我们证实，中国正在大规模解密并检查 QUIC 连接中的第一个数据包。通过一系列实验，我们推断出防火长城处理 QUIC 连接的规则和高级解析逻辑。例如，我们发现防火长城会忽略源端口低于目标端口的 QUIC 数据包，这可能是为了优化仅检查客户端流量而采取的措施。
- 1 Project homepage: https://gfw.report/publications/usenixsecurity25/en
我们使用类似 traceroute 的测量方法表明，负责 QUIC 审查的设备与现有的防火长城（GFW）设备位于同一跳，这表明它们可能使用共享基础设施或具有相似的管理方式。然而，尽管存在这种接近性，我们测量了触发 QUIC 审查的域名集合，并发现防火长城的 QUIC 黑名单与中国用于 TLS、HTTP 或 DNS 审查的黑名单有显著差异。特别是，就域名数量而言，QUIC 黑名单大约是 DNS 黑名单的 60%大小。令人惊讶的是，这些域名中有很大一部分甚至不支持 QUIC 协议，因此尚不清楚为何它们会出现在专门针对 QUIC 的审查名单上。
我们进一步证明，中国的定向 QUIC 审查可以被突破，使得防火长城（GFW）无法完全阻止 QUIC 连接。这揭示了防火长城在 QUIC 审查方面存在一个可利用的漏洞：攻击者可以发送适量的 QUIC 初始数据包，甚至发送到未被审查的域名，从而导致防火长城不堪重负，使其他发往被审查域名的 QUIC 连接被大幅降低速率地阻断。
最后，我们表明，GFW 的 QUIC 审查系统使整个国家容易受到攻击。我们提出了一种可用性攻击，利用 QUIC 审查机制来阻止中国境内的任何主机通过 UDP 与任何外国主机通信。例如，这种攻击可用于阻止访问所有位于境外的 DNS 服务器，从而导致广泛的互联网中断。我们使用自己在全球各地的服务器对这一攻击进行了测试，并证明单个伪造机器就可以阻止大部分这些主机与中国境内的观察点进行通信。由于其潜在的严重性，我们将这一漏洞披露给了中国的 CERT 组织。最后，我们讨论了该漏洞对突破审查社区的影响，以及针对有害行为者（即 GFW）利用漏洞所涉及的复杂伦理问题。
2. Background and Related Work
QUIC 协议。QUIC 是一种基于 UDP 的网络协议，最初由 Google 开发[27]，后来于 2021 年被 IETF 标准化为 RFC 9000 [43]。QUIC 类似于 TLS，但运行在 UDP 上，可降低延迟并实现浏览器控制的拥塞控制。QUIC 已被采用作为 HTTP/3 的加密基础[7]，2024 年，Cloudflare 估计超过 30% 的网页请求使用 QUIC [14]。此外，QUIC 对反审查社区也具有重要意义，因为它对所有数据包进行加密，以防止中间设备对其进行跟踪和篡改[27 §3]。
QUIC 客户端初始数据包。QUIC 握手中的第一个数据包是客户端初始数据包。由于 QUIC 数据包从一开始就已加密，但尚未进行密钥交换，因此初始数据包使用从目标连接 ID（DCID）和特定于版本的盐值[58]导出的密钥进行加密。这两个字段均以明文形式发送在 QUIC 客户端初始数据包中，允许服务器（以及被动的网络观察者）解密有效载荷。因此，这种保护机制并不能为观察方提供机密性或完整性，但可以防止路径外的欺骗攻击。
一旦初始数据包的有效载荷被解密，就会显示一组包含一个或多个 CRYPTO 帧的 TLS 1.3 客户端问候消息，其中列出了客户端支持的密码套件和 TLS 扩展。通常，这些 TLS 扩展之一将是服务器名称指示（SNI），它指定了客户端尝试连接的目标主机名。由于初始密钥可由任何网络观察者计算，因此可以解密 TLS 客户端问候消息及其明文内容，包括 SNI。
QUIC 阻断。2021 年，Elmenhorst 等人发现，尽管许多 QUIC 网站在伊朗和中国无法访问，但这并非由于任何基于 SNI 的审查。相反，这是因为伊朗阻止了前往这些 QUIC 终端主机的 UDP 流量[25 §5.2]，而中国则同时阻止了前往这些特定 QUIC 终端主机的 TCP 和 UDP 流量[25 §5.1]。随后，在 2022 年 3 月，ValdikSS 发现俄罗斯的 TSPU 阻止了所有使用 QUIC 版本 1（0x00, 0x00, 0x00, 0x01）、目标端口为 443 且有效载荷大小至少为 1001 字节的 QUIC 连接[70 §5.2, 63]。2024 年 12 月，乌兹别克斯坦阻止了带有加密客户端问候（ECH）扩展的 QUIC 连接[16]。据我们所知，中国于 2024 年 4 月开始根据 SNI 字段对 QUIC 连接进行阻断，截至 2025 年 6 月，中国成为首个也是唯一一个能够这样做的国家。
其他审查机制。防火长城（GFW）采用多种方法实施其封锁政策，包括域名系统（DNS）污染[4, 6, 20, 29, 38]、IP 地址封锁[25, 66]、基于关键词的过滤[11, 13, 37]以及主动探测[2, 26, 66 §5, 65 §4.5, 22 §4.3]。对于基于 UDP 的 DNS 请求，防火长城会向被禁止域名的查询注入虚假响应；对于 HTTP(S)流量，它会对 TCP 连接进行状态检查，并在检测到 HTTP Host 标头或 TLS SNI 扩展字段中包含被审查的域名时注入伪造的 RST 数据包[67]。随后会有一段短暂的“残留封锁”期，主要通过额外注入伪造的 SYN+ACK 和 RST 数据包来实现，不过最近的研究表明，丢弃数据包的方法也被使用[37 §5.4, 10]。
3. QUIC 网络审查机制
在本节中，我们研究了防火长城（GFW）如何检测并阻止连接到被禁域名的 QUIC 连接。我们发现，无论服务器 IP 地址如何，GFW 都会根据客户端的初始 SNI 来阻止 QUIC 连接。GFW 会检查 UDP 流中的第一个数据包，如果该数据包是一个包含中国 QUIC 特定黑名单域名的 QUIC 客户端初始数据包，则 GFW 会在接下来的 3 分钟内丢弃客户端发送到服务器的数据包（图 1）。
图 1：QUIC SNI 审查概述，包括决策流程、初始数据包解密、基于 SNI 的过滤以及针对标记连接触发的剩余阻止规则。
实验设置与观察点。我们在国内和国外使用了一组观察点来进行实验，这使我们能够通过防火长城（GFW）双向测试连接。在中国境内，我们共使用了七个观察点：四个位于北京，两个位于广州，一个位于上海。我们选择这些中国地区是因为它们是主要互联网交换中心（IXP）的所在地，众所周知防火长城部署在这些地方[52 §4.5, 36, 28 VI.C]。这些观察点由腾讯云（AS45090）和阿里云（AS37963）提供。在中国境外，我们使用了六个位于新加坡（AS16509）、圣何塞（AS14618）、旧金山（AS14061）、弗吉尼亚北部（AS14618）、开普敦（AS16509）以及美国一所大学（AS32）的观察点。
我们使用 Quiche [46]开发了一个自定义的 QUIC 客户端，该客户端允许我们构造特定的客户端初始数据包。由于我们观察到无论服务器响应如何，客户端的数据包都会触发阻断，因此在我们的实验中，服务器运行的是 tcpdump，而不是 QUIC 服务器。为了确保测量结果准确并避免干扰，我们在服务器上配置了 iptables 规则，以丢弃所有发往客户端的出站 ICMP 数据包。
3.1. QUIC 连接阻断
当我们观察到带有禁止 SNI 的 QUIC 客户端初始消息时，GFW 会丢弃所有后续共享相同源 IP、目的 IP 和目的端口的 UDP 数据包。我们通过从中国三个监测点位置向美国的一台服务器发送带有 QUIC 版本 1 和 google.com 作为 SNI 的 QUIC 客户端初始消息来发现了这一行为。我们发现，虽然这些 QUIC 客户端初始消息到达了我们的服务器，但随后客户端到服务器连接中的任何 UDP 数据包都会被审查者拦截长达 180 秒。
在此期间，如果客户端从不同的源端口向同一服务器端点（目标 IP 和端口）发送了 10 字节的随机数据包，这些数据包也会被 GFW 丢弃。然而，发送到服务器新目标端口的随机数据包并未被阻止，这表明 GFW 是基于三元组（源 IP、目标 IP、目标端口）进行拦截，以防止通过更改源端口进行的简单绕过尝试。正如我们通过让服务器在接收到 QUIC 客户端初始消息后，发送一个 Server Initial 消息以及携带随机 10 字节有效载荷的额外 UDP 数据包所证实的那样，我们也观察到这种拦截仅限于客户端到服务器方向；服务器发送的数据包并未被丢弃。
单个数据包即可触发残留阻断。与之前已知的由防火长城（GFW）实施的 TLS-SNI 审查不同[38 §3.1]，后者需要检测至少两个数据包（SYN 后跟 PSH/ACK），而 QUIC 审查机制仅需一个包含禁止 SNI 的 QUIC 客户端初始数据包即可激活。这是已知防火长城首次通过丢弃数据包的方式对基于 UDP 的协议实施残留阻断。尽管防火长城过去曾通过伪造数据包注入的方式审查基于 UDP 的 DNS 流量[4, 6, 38]，但此前并未采用丢弃数据包的方法来阻止基于 UDP 的协议。这可能是因为这种类型的审查需要设备具备在路径上直接丢弃数据包的能力，而以往仅通过注入方式的审查则只需使用旁路技术，审查设备仅能观察到数据包的副本。此外，防火长城残留的数据包丢弃行为还引入了一种新的可用性攻击途径，攻击者可利用防火长城阻止任意主机之间的通信。我们在第 6 节中探讨了这种攻击方式。
不一致的双向阻断。虽然我们初步实验表明，进入或离开中国的流量可能会触发阻断，但这一行为在 2024 年 9 月 30 日发生了变化。从那时起，大多数监测点的入站流量已不再触发阻断，但北京和广州的流量除外。
阻断延迟。我们的实验显示，在检测到包含禁止 SNI 的 QUIC 客户端初始数据包与长城防火墙开始丢弃数据包之间存在短暂的延迟，这使得一些数据包能够到达服务器。GFW 未能丢弃包含禁止 SNI 的 QUIC 客户端初始数据包的事实表明，GFW 存在一定程度的路径部署[64 §2.1]。结合其路径上的数据包丢弃能力，我们认为其部署架构是路径部署与在线部署的混合模式，这与 GFW 对 TLS ESNI 流量的阻断方式类似[32]。
为了精确测量这种阻断延迟，我们采用了一种类似于 2020 年研究的方法，该研究测量了包含加密服务器名称指示（ESNI）扩展的 TLS 流量被阻断时的延迟[32]。具体而言，我们测量了在触发 QUIC 初始数据包后，我们继续接收后续数据包的时间长度。
我们进行了一天的实验，以确定防火长城（GFW）对 QUIC 的阻断延迟。从我们在北京的观察点出发，每小时的前五分钟，我们向位于新加坡的我们所控制的服务器发起 25 个 UDP 流（源端口和目的端口各不相同）。在每个连接中，我们以每秒 100 个数据包的速率持续发送独特的 10 字节有效载荷。实验开始后的第 5 秒，我们向与正在进行的连接对应的 25 个目的端口中的每一个，从不同的源端口发送了一个带有禁止 SNI google.com 的 QUIC 初始数据包。这些 QUIC 初始数据包会触发防火长城对这 25 个目的端口进行阻断（对于我们的客户端/服务器对，无论使用哪个源端口），从而使服务器停止接收 10 字节的有效载荷。
在服务器端，我们捕获了数据包，并寻找那些 UDP 数据包之间至少有 120 秒间隔的连接，这表明 QUIC 客户端的 Initial 成功触发了审查。对于这些连接，我们查看了客户端发送被阻止的 QUIC Initial 的时间，以及服务器在审查导致的间隔之前接收到的最后一个 UDP 负载。这代表了在审查触发后，数据包仍能立即通过防火长城时的阻断延迟，精度可达 10 毫秒。
阻断延迟范围为 60 毫秒到 7.5 秒（图 2）。超过 90% 的连接在一秒钟内被阻断，但也有很长的尾部延迟需要更长时间。我们推测，阻断延迟的差异与防火长城必须处理的 QUIC 流量大小有关（见附录 A）。我们在第 5 节中探讨利用这一特性来降低防火长城对 QUIC 流量审查的性能。
图 2：累积分布函数（CDF）显示了 GFW 实施阻止规则并导致后续数据包丢弃所需的时间分布。在超过 90%的情况下，GFW 会在一秒钟内阻止连接。观察到的阻止时间范围从最短的 0.06 秒到最长的 7.5 秒不等。
3.2. 流跟踪逻辑
与具有明确三次握手以标记新连接开始的 TCP 不同，UDP 是一种无连接协议，没有明确的传输层握手。这使得中间设备难以识别新的 UDP 流的开始。尽管可以通过连接 ID（CID）追踪 QUIC 连接，但我们发现 GFW 并未使用 CID 来跟踪 QUIC 流，而是采用 UDP 四元组（源 IP、目的 IP、源端口、目的端口），并在其流跟踪系统中设置 60 秒的超时机制来保持状态。为了了解这一点，我们依赖于这样一个事实：只有当 UDP 流中的第一个数据包是带有禁止 SNI 的 QUIC 客户端初始消息时，GFW 才会阻止该连接。如果在初始数据包之前出现任何其他 UDP 数据包，则不会阻止该连接。
我们从北京的一个观察点向美国的一台服务器发送了一个带有随机 10 字节载荷的 UDP 数据包。然后，我们在等待一段时间后，在同一连接中以每秒间隔的方式连续发送了三个 QUIC 客户端初始消息（Initial messages），这些消息的载荷也是随机的 10 字节。我们重复了这一实验，并在每次迭代中将随机载荷数据包与客户端初始消息之间的延迟增加一秒，直到观察到阻塞现象为止（即 180 秒内未收到任何数据包）。
我们发现，当第一个随机载荷数据包与客户端初始消息之间的时间延迟达到 60 秒时，就会出现阻塞现象，这表明由随机 UDP 载荷启动的数据流被跟踪了 60 秒。在这 60 秒窗口之后发送的 QUIC 初始消息触发了阻塞，这表明防火长城（GFW）已经重置了该数据流的状态，并将 QUIC 初始消息视为一个新的数据流。
没有 UDP 重组功能。我们发现，GFW 不会对拆分到多个 UDP 数据报中的 QUIC 初始数据包进行重组。考虑到在 2024 年 4 月 7 日部署时，很少有 QUIC 客户端发送无法装入典型 UDP 数据报的大型 QUIC 初始数据包，这种设计选择可能是合理的。然而，正如第 7 节所述，自 2024 年 9 月 13 日[ 1]以来，Chrome 对其 QUIC 初始数据包进行了一系列更改，使其变得过大而无法装入单个 UDP 数据报。这些针对广泛使用的浏览器的更改使得 GFW 的防护效果降低，因为只有当 SNI 扩展出现在第一个 UDP 数据报中时，它才能进行拦截。
3.3. 源端口必须大于目标端口
我们发现，向美国的服务器发送带有被禁止 SNI 的 QUIC 客户端初始数据包，并不总是会触发拦截。为了进一步调查这种行为，我们进行了多项实验，旨在确定审查者用来过滤 QUIC 连接的具体规则。
我们选择了一系列端口，范围从 401 到 450，步长为 1。我们从位于北京的观察点向美国服务器发送带有 SNI google.com 的 QUIC 客户端初始消息，并枚举该范围内所有可能的源端口和目的端口组合。在发送每个 QUIC 客户端初始消息后，我们等待一秒钟，然后间隔一秒再发送五个额外的 UDP 数据包，每个数据包都带有独特的 10 字节有效载荷。这个过程重复了十次，在每次迭代中使用不同的目的 IP 地址（来自分配给我们的服务器的/28 子网）。为了防止之前连接产生的残留阻塞，我们在每次迭代之间等待五分钟。对于每对端口，我们记录成功接收的连接数量以及被阻止的连接数量（即未收到后续 UDP 数据包的数量）。
如图 3 所示，GFW 不会阻止源端口号小于或等于目的端口号的连接。然而，这种阻止行为并不统一，这表明连接被阻止的一致性存在差异。我们还以 1,000 为步长对所有端口（1 到 65,535）进行了相同的实验，发现这一过滤规则在所有端口上都是一致的（附录 B）。
图 3：GFW 会豁免源端口等于或低于目标端口的 QUIC 初始数据包连接。实验于 2024 年 12 月 2 日在中国北京的一个观察点进行。
防火长城（GFW）限制了需要检查的连接数量。审查机构应用这种启发式端口检查规则来限制其需要检查的连接数量。由于大多数客户端会选择一个（高）临时端口 2 并连接到较低的知名端口号（例如 443），因此防火长城可以通过忽略源端口低于目标端口的数据包，丢弃可能的服务器到客户端流量。
当审查员采用这一规则时，会产生两个问题：1）审查员能迅速排除多少流量？2）审查员会遗漏多少个 QUIC 客户端初始连接？为了评估该规则的效率和漏报率，我们从美国一所大学的流量采集点收集了 UDP 流，并分析了源端口和目的端口号码的分布情况。
表 1 显示了 QUIC 客户端初始数据包（Inits）和 UDP 数据报的分布情况，这些数据基于源端口和目的端口，是在 2025 年 1 月 22 日美国当地时间（太平洋标准时间，UTC-8）8:00 至 9:00 之间，在一所美国大学的流量镜像中观察到的。审查机构仅处理 UDP 源端口大于目的端口的数据包（即 UDP sport > dport），这意味着他们捕获了超过 90%的所有 QUIC 客户端初始数据包，而仅对所有 UDP 数据包中的 30%进行流表查找。实际尝试解密的 UDP 有效载荷比例更低：如第 3.2 节所述，防火长城（GFW）仅解析一个流（定义为五元组：源 IP、目的 IP、源端口、目的端口、UDP 协议）中未在最近 60 秒内出现过的第一个 UDP 数据报的有效载荷。
表 1：2025 年 1 月 22 日太平洋标准时间（UTC-8）上午 8:00 至 9:00 期间，在美国一所大学的网络分路器上观察到的基于源端口和目的端口的数据包数量分布。如果 UDP 报头中的源端口（sport）大于目的端口（dport），审查机制才会进一步考虑流跟踪，这使得在仅查看 30%的 UDP 数据包时，能够捕获超过 90%的所有 QUIC 客户端初始数据包。
QUIC 客户端初始化 |
UDP 数据报 |
|||
| 源端口 > 目的端口 | 6.7 M | (92.3%) | 3.7 B | (29.8%) |
| 运动 < dport | 0.6 M | (7.6%) | 8.4 B | (68.0%) |
| 运动 = dport | 4.6 K | (0.06%) | 2770 万 | (2.2%) |
3.4. 日间阻挡模式
图 3 中的变化性表明，连接并非始终被阻断，而且这种阻断是非确定性的。为了进一步研究这一现象，我们从不同位置进行了一周的实验，以观察全天及所有目标端口上 QUIC 连接被阻断的频率。我们使用位于中国的三个地点与美国服务器建立连接。我们发送了 1,000 个并发探测（即包含 SNI google.com 的 QUIC 客户端初始数据包，随后每 5 秒延迟 1 秒，并通过 UDP 发送 5 个后续数据包，每个数据包包含独特的 10 字节有效载荷，从中国三个地点分别向美国服务器的 10 个 IPv4 地址和所有端口发送）。在所有情况下，我们确保源端口大于目标端口，如第 3.3 节所述。如果在 QUIC 客户端初始数据包之后，服务器未接收到任何 10 字节的后续 UDP 有效载荷数据包，则我们将该连接标记为被审查。然后，我们通过汇总每个客户端位置每小时的数据，计算被阻断连接的百分比。
阻断率受一天中不同时间段的影响。如图 4 所示，三个城市均呈现出明显的昼夜变化规律，阻断百分比在清晨时段达到峰值，而在白天降至最低水平。北京的阻断率始终最高，其次是上海和广州。这一模式表明，阻断率受到中国互联网使用模式的影响，在网络流量较低的时段观察到最高的阻断率。
图 4：来自中国三个主要城市的客户端向美国服务器发送连接时，被阻止的 QUIC 连接所占比例随时间的变化情况。所示时间戳为北京时间（CST，UTC+8），跨度为 2024 年 11 月 15 日至 22 日。
我们假设这种行为的发生是因为防火长城（GFW）在任何给定时间只能处理有限的流量。大规模解密 QUIC 初始数据包的运行成本非常高，这使得封锁率对网络负载非常敏感，而网络负载会随一天中的不同时间段而变化。在之前关于防火长城关键词过滤和 DNS 注入机制的研究中也观察到了类似的昼夜模式[4 §7, 15 §3.2]，这表明存在计算能力限制，导致防火长城在高峰时段的效率降低。值得注意的是，这一点在 QUIC 连接的背景下变得越来越重要，因为与 HTTP 和 DNS 等其他明文协议相比，解析 QUIC 流量的计算成本更高。在第 5 节中，我们将进一步提供证据，表明当通过防火长城的 QUIC 初始数据包数量增加时，可能会使其不堪重负，从而导致其审查效果下降。
3.5. 查找审查设备
我们进行了一项增量式 IP TTL 测量，以定位审查设备。我们在 QUIC 客户端初始消息中设置了一个固定的 IP TTL 值，从 1 开始，在每次实验中增加 1。在每个实验的第一秒内，我们将 10 条带有 google.com SNI 的 QUIC 客户端初始消息发送到美国服务器的 53 端口，确保只要数据包到达审查者，就会触发拦截。5 秒钟后，我们再发送 100 个 UDP 数据报，其 4 元组与 QUIC 客户端初始消息相同。这些 UDP 数据包的有效载荷为 10 字节，包含在 QUIC 客户端初始数据包中使用的编码 TTL 值。我们通过观察这 100 个 UDP 数据报是否被丢弃来推断 QUIC 初始消息是否到达了审查者。这项测量在中国的三个观测点（北京、上海和广州）进行，每个实验重复 10 次。
如表 2 所示，我们发现 QUIC 阻塞直到 IP TTL 值分别为 9、11 和 12 时才被触发，分别对应我们的上海、北京和广州客户端。对于上海和广州，触发阻塞的跳数位于 ChinaNet 骨干网络中；而对于北京，则位于中国联通的骨干网络中。
同样地，我们使用相同的四元组，并将 IP TTL 值递增，向服务器的 53 端口发送了针对 google.com 的 DNS 查询。我们观察到，只有当 IP TTL 值与 QUIC 阻断所观察到的值相匹配时，DNS 注入才会被触发，这表明新设备与现有的防火长城（GFW）设备位于同一跳上。
表 2：通过 Traceroute 结果识别防火长城（GFW）的 UDP 审查节点：通往执行 QUIC 和 DNS 拦截的设备的路径，包括来自三个不同客户端位置的最终未被审查的跳数。
| 城市 | 距离（QUIC/DNS）跳数 | 审查跳数 -1（ISP/AS） |
审查跳数（ISP/AS） |
| 上海 | 9/9 | 中国网通上海市网络（AS4812） |
中国网通骨干网（AS4134） |
| 北京 | 12/12 | 中国联通骨干网（AS4837） |
中国联通骨干网（AS4837） |
| 广州 | 11/11 | 中国网通广东省网络（AS4134） |
中国网通骨干网（AS4134） |
3.6. QUIC 解析的特殊性
GFW 的 QUIC 审查在几个方面并未严格遵循 QUIC 规范[43, 58]。我们设计并发送了多个经过修改的 QUIC 有效载荷，这些有效载荷本应被符合 RFC 规范的实现拒绝，以观察它们是否仍会触发 GFW 的审查。如果确实如此，则表明 GFW 未能正确忽略不符合规范的 QUIC 有效载荷，这可能为规避方法或其他漏洞提供机会。我们的修改后的 QUIC 有效载荷在表 3 中进行了描述，图 5 显示了通过 GFW 发送这些有效载荷的结果。对于每个有效载荷，我们从中国的监测点向境外服务器以及从境外服务器向中国境内服务器分别发送了 20 个连接，以确定它们是否会触发审查。
表 3：我们运行的每个实验的描述，用于分析 GFW 的 QUIC 解析机制。对于每个实验，我们标记了有效载荷是否曾被观察到被阻止（第 3.6 节），以及它是否可用于削弱 GFW（第 5 节）。
| 实验编号 | 测试的 QUIC 初始数据包描述 |
被阻止？ | 降级？ |
| 1 | 数据包编号为一字节。 |
✓ | ✓ |
| 2 | 从 QUIC 数据包中移除最后一个字节。 |
✕ | ✓ |
| 3 | 带有错误身份验证标记的版本号无效。版本号：0x00000002。 |
✕ | ✕ |
| 4 | 这两个连接 ID 的长度均为 0x00。 |
✓ | ✓ |
| 5 | 源连接 ID 的长度为 0xff。 |
✕ | ✓ |
| 6 | CRYPTO 帧的长度为 0x00，但仍包含有效载荷。 |
✓ | ✓ |
| 7 | 扩展中的敏感域（例如 ALPN 中包含 google.com），而非 SNI 扩展。 |
✕ | ✓ |
| 8 | QUIC 载荷包含单个 CRYPTO 帧以及多个 PING 和 PADDING 帧。 |
✕ | ✓ |
| 9 | 一个 QUIC Initial 数据包，其 TLS Client Hello 包含 Encrypted Client Hello 扩展，外部 SNI 为 cloudflare-ech.com。 |
✕ | ✓ |
| 10 | 一个 QUIC 版本 2 数据包。 |
✕ | ✕ |
图 5：每次实验运行中被拦截的类似 QUIC 的数据包百分比。对于每种负载，我们建立了 20 个连接，并测量了有多少个连接被目标主机接收。每个负载（如表 3 所示）测试了对标准 QUIC 客户端初始值的修改，并深入了解了防火长城（GFW）QUIC 审查器的解析逻辑。
无需填充。虽然 QUIC 规范要求初始数据包必须填充到至少 1200 字节，但我们发现 GFW 并未强制执行这一要求。我们能够通过仅 137 字节的小型有效载荷触发审查机制。然而，由于 GFW 不会注入响应，因此不存在放大攻击的风险。
长度字段歧义。规范中定义连接 ID 的长度在 8 到 20 字节之间，但该字段支持的最大长度可达 255 字节。我们发现，将源和目标连接 ID 都设置为长度为 0x00（太短）时会被阻止，尽管根据规范应忽略这种情况。另一方面，长度为 0xff 并未被阻止，这表明防火长城正确地检查了上限。奇怪的是，我们发现即使 CRYPTO 帧的指定长度为 0x00，只要有效载荷中包含禁止的 SNI，防火长城也会阻止该载荷。防火长城似乎会从有效载荷的其余部分推断出 CRYPTO 帧的长度，这意味着它无法正确处理拆分的 CRYPTO 帧（例如 Google Chrome 浏览器所使用的帧）。
特定版本的封禁。只有包含版本字段中明文字节模式 0x00000001 的 QUIC 第 1 版数据包才会受到封禁。最近标准化的 QUIC 第 2 版 [21] 使用了不同的初始加密密钥盐值，因此并未被封禁。这表明防火长城（GFW）要么尚未更新其过滤机制以适应新版本的盐值，要么仍然依赖于针对第 1 版的明文字节模式匹配来进行数据包检查。
4. 随时间监控黑名单
在本节中，我们研究了被防火长城（GFW）的 QUIC-SNI 审查机制所屏蔽的网站。我们分析了当前被屏蔽的网站、屏蔽列表随时间的变化情况，以及 QUIC 屏蔽列表与其他审查方法（如 TLS-SNI、HTTP 和 DNS）所使用的屏蔽列表之间的对比。正如第 3.4 节所述，防火长城的 QUIC 审查机制是非确定性的，因此需要一种实验方法来尽量减少误报。对于每个测试域名，我们从多个观察点发送携带 SNI 的 QUIC 客户端初始消息，并在多次试验中重复该过程。此外，为了避免特定目标端口上残留审查导致的不准确性，我们在任何 180 秒的时间窗口内，都不会向相同的三元组（源 IP、目标 IP、目标端口）发起连接。
我们对防火长城（GFW）的 QUIC 黑名单进行了超过三个月的监测。由于双向封锁存在不一致的情况——特别是，我们的大多数观测点在 2024 年 9 月 30 日之后停止了双向封锁——因此我们采用了由内而外的测量方法。我们在北京部署了十个观测点（AS45090）来运行客户端脚本，并在美国一所大学（AS32）部署了一个观测点作为服务器。服务器被分配了一个/28 IPv4 子网。对于每个待测域名，客户端向服务器发送一个 QUIC 客户端初始消息，等待一秒钟，然后每隔一秒发送五个独特的 10 字节 UDP 有效载荷数据包。如果后续的 UDP 有效载荷数据包均未收到，则我们将该 SNI 标记为被封锁。
我们使用了 2024 年 10 月 2 日获取的完整 Tranco 列表（ID：664NX） 3 ，其中包括大约七百万个完全限定域名（FQDNs），用于测试。我们承认，这个列表可能无法全面涵盖所有被审查的域名。然而，我们认为，一个相当大的流行域名列表能够代表防火长城的 QUIC 黑名单。
在每次测试中，对于每个名称，位于北京的十个客户端观察点中的每一个都会向我们美国服务器的一个不同 IP 地址发送一个 QUIC 客户端初始消息。根据我们在第 3.3 节中的发现，我们始终使用大于目标端口的源端口来触发阻止。我们以 cron 作业的形式在中部标准时间（CST）凌晨 3 点至 6 点之间运行这些实验。这是因为我们观察到在这段时间内阻止率最高（第 3.4 节）。
由于在此期间的阻止率对我们连接而言至少为 50%，我们将每个 QUIC 客户端初始测试重复十次，以确保我们的黑名单提取准确性高于 1− (1 − 50% ) 10 = 99.9%。在服务器端，我们汇总了每天被阻止的每个 SNI 的数据。这些实验已经持续了三个多月，从 2024 年 10 月 8 日开始，一直持续到 2025 年 1 月 15 日。
图 6：2024 年 10 月 8 日至 2025 年 1 月 15 日期间，GFW 对完整 Tranco 列表（ID：664NX）的 QUIC SNI 审查所阻止的 FQDN 数量。被阻止的域名数量按周汇总。条形图显示了随着时间推移黑名单每周的变化情况。
QUIC 阻断列表。每周，我们发现 GFW 平均阻断了来自 Tranco 列表的 43.8K 个 FQDN（图 6）。在我们的实验整个期间，我们观察到 GFW 阻断了来自 Tranco 列表的 58,207 个唯一 FQDN（表 4）。
表 4：支持 QUIC 的完全合格域名（FQDN）数量、被 QUIC-SNI 审查阻止的域名数量，以及它们的交集。QUIC 审查测试于 2024 年 10 月 8 日至 2025 年 1 月 15 日进行。
完全合格域名 |
数量 |
总计测试（Tranco 列表） |
6,955,968 |
| 支持 QUIC | 1,489,967 |
QUIC 阻断情况 |
58,207 |
被阻止与支持 QUIC 的域名数量 |
38,451 |
通过 QUIC 被阻止的域名可能并不支持 QUIC。我们通过直接发起 HTTP/3 请求而非依赖 Alt-Svc 标头来测试这些域名是否支持 QUIC，因为有些服务器虽然支持 HTTP/3-over-QUIC，但并未公开声明。根据我们的测量结果，我们识别出 58,207 个通过 QUIC 被阻止的完全合格域名（FQDN），其中 38,451 个实际上支持 HTTP/3-over-QUIC（见表 4）。在这组被阻止的域名中，有 9,345 个流行的二级域名（例如 google.com、hrw.org、youtube.com、tiktok.com）也被发现被阻止，但其中只有 3,233 个实际支持 QUIC。值得注意的是，大量 googlevideo.com 子域名（35,443 个）出现在了被阻止列表中，这表明存在更广泛的针对*.googlevideo.com 的屏蔽规则，并导致支持 QUIC 的域名数量增加。由于并非所有被 QUIC 阻止的域名都实际支持 QUIC，因此很难确定防火长城（GFW）黑名单背后的准确逻辑。GFW 可能出于对潜在未来 QUIC 支持的预判而提前阻止这些域名，也可能使用了与 QUIC 无关的其他标准来进行屏蔽决策。
4.1. Comparison with Other Blocklists
我们对 GFW 的 QUIC-SNI 黑名单与其他已建立的 GFW 审查机制（包括 TLS-SNI、HTTP Host 和基于 DNS 的封锁）进行了对比分析。为了评估 TLS-SNI 的封锁情况，我们采用了基于先前研究[11, 37]的方法。我们在北京设立了一个客户端，在美国设立了一个接收服务器，以进行由内而外的测量，并与我们的 QUIC-SNI 封锁分析保持一致。我们的接收服务器被配置为接受 TCP 连接，但不响应任何数据。在每次测试中，客户端完成 TCP 握手后，会发送包含测试域名 SNI 值的 TLS Client Hello 消息。我们监控连接是否出现 TCP RST 数据包——这是 SNI 封锁的一个典型特征。对于 HTTP Host 测试，我们采用了类似的方法，但将 TLS Client Hello 替换为 HTTP GET 请求，其中 Host 标头字段包含测试域名。
为了进行 DNS 审查测试，我们遵循了先前研究中已建立的方法论[6, 38]。我们配置了位于北京的客户端，使其向一个位于美国的受控 IP 地址发送 DNS 查询，而该 IP 地址上并未运行任何 DNS 服务器。这种配置使我们能够明确地将接收到的任何 DNS 响应归因于防火长城（GFW）的注入行为，因为我们的服务器被配置为忽略所有查询。为了确保在 TLS-SNI、HTTP Host 和 DNS 这三种测试方法之间进行一致的比较，我们使用了来自同一 Tranco 列表中的域名。我们在 2025 年 1 月 9 日至 2025 年 1 月 15 日这一周内进行了这些测量，并收集了被列入黑名单的域名。
图 7 展示了 TLS-SNI、HTTP 主机名、DNS 和 QUIC 协议的黑名单之间的重叠情况。在我们测试的 Tranco 列表域名中，DNS 封锁影响的域名数量最多（106,973 个），其次是 HTTP（105,488 个）和 HTTPS（102,216 个）。QUIC 黑名单明显较小，包含的域名数量约为其他三个黑名单的 55%。在通过 QUIC 协议被封锁的 58,207 个域名中，有 11,854 个域名仅通过该协议被封锁。值得注意的是，在这些仅通过 QUIC 协议封锁的域名中，我们发现实际支持 QUIC 协议的域名仅有 2,329 个。
图 7：显示 HTTPS、HTTP、DNS 和 QUIC 的黑名单之间重叠情况的维恩图。每个协议的黑名单汇总自 2025 年 1 月 9 日至 2025 年 1 月 15 日为期一周的时间段内。
我们发现有 40,447 个域名同时出现在所有四个黑名单中，占总数的 24.4%（以交集除以并集计算）。在单独比较 QUIC 阻断与其他三种协议时，我们发现与 HTTPS 的重叠率（交集除以并集）最高，为 46,251 个域名（40.51%），其次是 HTTP，为 43,191 个域名（35.84%），以及 DNS，为 41,484 个域名（33.54%）。这些发现表明，每种审查机制都使用不同的但相互重叠的黑名单，从而形成一个互补系统，最大限度地扩大了防火长城的审查范围。例如，在现代浏览器中，一个基于 HTTP/3-over-QUIC 的浏览会话通常首先进行 DNS 查询，然后通过 HTTP/2（或更早版本）发起请求，最后升级到基于 QUIC 的 HTTP/3。防火长城的审查策略旨在单独或组合影响每个阶段，确保用户无法访问被禁止的网络内容。
表 5 显示了 GFW 针对 Tranco Top 10k 网站（包括支持 QUIC 的网站）以及随机选取的 500 个完全限定域名（FQDNs）的 DNS、HTTP、TLS 和基于 QUIC 的审查所使用的黑名单之间的 Jaccard 指数（交集与并集之比）。
TABLE 5: The Jaccard Index (Intersection over Union) of the GFW’s blocklists for DNS-, HTTP-, TLS-, and QUIC-based censorship of the Tranco top 10k, alongside websites supporting QUIC, and a randomly selected sample of 500 fully qualified domain names (FQDNs).
| DNS | HTTP | TLS | QUIC | 支持 QUIC | 样本 500 | |
| DNS | - | - | - | - | - | - |
| HTTP | 0.57 | - | - | - | - | - |
| TLS | 0.67 | 0.43 | - | - | - | - |
| QUIC | 0.19 | 0.20 | 0.26 | - | - | - |
| 支持 QUIC | 0.19 | 0.20 | 0.13 | 0.05 | - | - |
| 样本 500 | 0.03 | 0.03 | 0.03 | 0.01 | 0.05 | - |
5. GFW 降级攻击
在图 4 中，我们观察到，在中国流量高峰时段，防火长城对 QUIC 协议的审查效果较差。这促使我们假设，通过发送防火长城需要处理的 QUIC 数据包，可以有目的地降低防火长城的审查效果。虽然我们的实验为了解中国的审查系统设计提供了有价值的见解，但也引发了一些伦理方面的担忧。我们在第 9 节中仔细考虑并讨论了这些问题。我们设计实验时确保用户和其他互联网设备不受影响，并特别保证我们的测试仅针对防火长城进行优化。
在这个实验中，我们使用了三个观察点。第一个位于中国（北京，阿里巴巴，AS37963），我们称之为 ChinaVP；第二个位于美国（东部，Digital Ocean，AS14061），我们称之为 USVP；第三个位于美国的一家研究机构（密歇根大学，AS36375），我们称之为 StressVP。我们的目标是在适度的 QUIC 流量存在的情况下，测量防火长城（GFW）对 QUIC 协议的审查效果。这个实验由两个同时进行的部分组成：测量部分和压力测试部分。
在测量部分，我们配置三个探测点执行以下操作：ChinaVP 向 USVP 发送一个包含禁止域名（即 SNI 字段中的 google.com）的 QUIC Initial 数据包（有效载荷为 267 字节），并将目的端口设置为小于源端口（如第 3 节所示，以触发审查机制）。在一秒钟的暂停后，我们在同一连接中发送 100 个 UDP 数据包，每个数据包包含固定的无害有效载荷 1,111 字节。这一过程针对 1000 对不同的源-目的端口组合重复进行。如果服务器（USVP）接收到 QUIC Initial 数据包以及后续 95% 或更多的数据包，则我们将该连接标记为允许（规避审查）。
在施压部分，我们使用 StressVP 以不同的发送速率（从 100kpps 到 1500kpps，每次增加 100kpps，持续七分钟，并间隔三分钟的暂停）向 ChinaVP 所在的 /14 网络前缀中的 IPv4 地址发送两种类型的流量。我们的目标是发送足够的流量来对防火长城（GFW）施加压力，同时不会影响网络链路或路由器。通过选择一个较大的网络进行发送，我们发送的流量对单个主机的影响被稀释了。
此外，为了避免我们的施压数据包到达终端主机，我们估计了/14 中各个 IP 地址与 StressVP 之间的跳数距离。我们使用 ZMap 运行 TTL 限制的 DNS 扫描，解析整个/14 网段上的 example.com 域名。我们通过从/14 中的 164 个 DNS 服务器接收到的 DNS 解析停止情况，来近似每个 IP 地址与 StressVP 之间的跳数距离。然后，我们将从 StressVP 发出的施压数据包的 TTL 值设置为比/14 中最小（最近）跳数距离的 DNS 服务器小一。
在施压阶段，我们向防火长城（GFW）发送两种类型的（TTL 限制的）流量：QUIC 初始数据包，以及随机生成的具有固定载荷的 UDP 数据包。对于 QUIC 数据包，我们使用 ChinaVP 和 USVP 之间发送的相同 QUIC 初始载荷，其中包含被禁止的 SNI，以触发 GFW 的审查机制。对于随机载荷，我们使用与 QUIC 载荷长度相同的无害字节。我们使用 ZMap [23]发送这些载荷中的每一个，并将发送速率配置为平均每秒不超过 6 个数据包（pps）到/14 中的每个 IP 地址。
我们的实验包括从我们的 StressVP 向 ChinaVP 的/14 发送（TTL 有限的）QUIC 初始数据包。这一过程在不同的日期重复三次，一次按递增顺序发送，另两次则以随机打乱的发送速率进行。同时，我们从 ChinaVP 向 USVP 测量允许连接的比例。然后，我们重复该实验三次（与 QUIC 压力测试不同步），但发送的是随机负载，而非 QUIC 初始数据包，并测量允许连接的比例。图 8 显示了我们的实验对防火长城（GFW）的影响（取平均值）。随着 QUIC 初始数据包发送速率的增加，防火长城更难审查 ChinaVP 和 USVP 之间的连接。而在发送随机负载时，我们并未观察到这种模式，这意味着性能下降仅由 QUIC 负载的处理引起，而非网络流量本身导致网络性能下降，这一点也得到了我们网络监控的进一步支持。请注意，所有实验均在中国的清晨时段进行，此时防火长城对 QUIC 流量的审查效果更好（见图 4）。
图 8：我们通过发送两种长度相等的数据包（0–1500 Kpps）来对 GFW 进行压力测试：一种是包含被禁止的 SNI（被审查的压力测试，Censored Stressing）的 QUIC 初始数据包，另一种是包含随机负载（随机压力测试，Random Stressing）的 UDP 数据包。在测试过程中，我们通过发送固定速率的 QUIC 初始数据包，随后再发送 100 个数据包，以此模拟从中国到美国的 1000 个 QUIC 连接，并测量 GFW 未能审查掉的连接比例（被审查流量）。随着我们增加用于压力测试的 QUIC 初始数据包的数量，GFW 审查我们测量的 QUIC 连接的能力会降低，从而增加了 GFW 处理 QUIC 数据包的难度。为了确保我们的测试仅影响 GFW 而不会影响网络，我们在测试期间测量了两个观测点之间未被审查的 QUIC 流量（出口/入口控制流量）。
网络监控。在我们进行实验时，我们以两种方式监测 ChinaVP 与 USVP 之间的网络状况。首先，我们在两个方向上发送未被审查的 QUIC 连接，并监测两端接收到的数据包比例。其次，我们使用 ZMap 以较慢的速度（650 pps）扫描 tcp/443 端口上的/14 网络，并测量网络中的响应率。如果在我们的实验过程中，这些指标中的任何一个显著下降，可能是因为网络链路已饱和，这表明我们必须停止实验。由于在我们的实验过程中从未观察到任何指标下降，我们认为我们的实验对 GFW 之外的网络和设备的影响可以忽略不计。
逆向工程。除了帮助用户规避审查外，降级攻击也有助于理解 GFW 的处理机制。例如，如果特定的 QUIC 有效载荷可用于降低 GFW 审查的有效性，那么即使该有效载荷本身并未被阻止，我们也知道它已经在某种程度上被 GFW 处理过。另一方面，如果某个有效载荷对 GFW 没有影响，则很可能在执行计算成本较高的步骤之前就被丢弃了。
表 3 显示了每个载荷是否成功削弱了防火长城（GFW）的审查效力。我们通过以 1200 Kpps 的速度发送每个载荷，并观察允许的被审查连接所占的比例是否超过 60%，以此来测试其效果，这表明该载荷对防火长城产生了影响。这些结果表明，防火长城会使用默认的 QUIC 版本处理所有载荷，即使那些未解密或具有无效身份验证标签的载荷也能削弱防火长城的功能。然而，要触发审查行为，有效的标签是必需的，这暗示着防火长城中“慢”的部分很可能是解密载荷时的加密操作。
6. Availability Attack
先前的研究表明，残留的审查有时会被攻击者“武器化”，用于实施可用性攻击[8, 9]。在这种类型的攻击中，攻击者向目标 B 发送一个触发审查的请求，并伪造源 IP 地址为受害者 A。如果该请求在 A 和 B 之间的防火墙中触发了残留的阻止机制，则这两个主机将无法通信，因为防火墙会认为受害者 A 发送了一个被禁止的请求。残留的审查通常持续 1 到 3 分钟[9, 10, 11, 37, 64, 66]，攻击者可以在残留审查结束后或期间简单地伪造额外的触发数据包，以使受害者和目标继续处于被阻止状态。
我们的研究首次发现，防火长城（GFW）对基于 UDP 的协议实施了残留阻断。虽然防火长城过去一直通过伪造数据包注入的方式审查基于 UDP 的 DNS 流量，但并未采用丢弃数据包的方法来阻止基于 UDP 的协议。然而，防火长城新的 QUIC 阻断机制采用了丢弃数据包的方式，从而引入了一种新的可用性攻击向量，影响整个中国。特别是，攻击者可以利用这种可用性攻击，阻止中国境内的主机与境外服务器之间的 UDP 连接。例如，这种攻击可以阻止所有位于中国境外的开放或根 DNS 解析器从中国境内被访问，从而导致该国范围内的大规模 DNS 故障。
在本节中，我们通过针对我们自己的主机和服务器进行实验，来研究这种攻击的实际可行性。
攻击设置。此次攻击需要能够伪造 IP 数据包的能力，而这需要一台不受出口过滤限制的服务器。我们从一家公共 VPS 提供商处获得了一台这样的主机，并验证了我们可以伪造 IP 数据包，并且这些数据包在中国境内可以被接收。在中国境内，我们使用了一台位于广州、由我们控制的 VPS，因为这台主机在进出方向都受到 QUIC 审查，这意味着从中国境外连接到这台服务器的客户端也会受到 QUIC 审查。为了模拟“受害者”主机，我们在 AWS 在中国以外运营的 32 个地区中，每个地区都获取了一台 AWS EC2 实例。
对于每个 EC2 实例，我们向位于广州的 VPS 发送了一个 DNS 查询。然后，我们测量该请求是否被我们的 VPS 接收到，这表明连接最初是可用的。
接下来，我们从一台能够伪造数据包的攻击机器上，为每个 EC2 实例向中国的 VPS 发送了十个经过篡改的被审查 QUIC 客户端初始数据包。这些数据包旨在触发 GFW（防火长城）对 EC2 实例 IP 地址与位于中国的 VPS 的 IP:端口之间的残留审查机制。这些数据包到达中国 VPS 的路径可能与来自 EC2 机器的数据包所走的路径有很大不同，这意味着它们可能会经过不同的 GFW 节点，从而使攻击失效。我们每秒发送这些伪造的数据包。
与此同时，我们从每个 EC2 实例测量攻击的有效性，每五秒钟向中国的 VPS 发送一个 DNS 请求。如果在实例与 VPS 之间的路径上存在残留的审查机制，该请求将被阻止，这表明可用性攻击成功。
图 9：该地图显示了受可用性攻击影响的 EC2 实例的位置。受影响最严重的主机以红色阴影显示，受影响较小的主机以绿色阴影显示。中国境内的黑点是受害服务器的位置，美国境内的黑点是伪造攻击服务器的位置。
表 6 和图 9 显示了 EC2 实例的位置以及攻击的影响。在 32 个 EC2 实例中，超过一半（17 个）受到我们攻击的严重影响。尽管对于受影响严重的主机，仍有一些数据包能够通过，但我们发现这主要是由于 3 分钟残留审查机制到期的时间点所致。当该机制到期时，在下一个伪造数据包到达并重新阻止实例之前，最多有一秒钟的时间。如果发送速度更快或与到期时间同步，可以提高阻止率。此外，我们还观察到有 7 个主机大约有一半的时间受到影响，这表明给定实例与 VPS 之间可能存在多条网络路径，而只有一部分路径经历了残留审查。
表 6：显示了服务器从每个 AWS 区域接收的数据包数量。可用性攻击持续了 30 分钟，真实客户端每 5 秒发送一个数据包。欺骗服务器位于美国，受害服务器位于中国广州。对于每个 AWS 主机，攻击服务器每秒发送十个伪造的 QUIC 客户端初始数据包，每个数据包都在一个新的连接中。
| 大陆/地区 | 城市/地区 | # 接收的数据包 | 360 的 % |
| 非洲 | 开普敦 | 110 | 30.56% |
| 亚太地区 | 香港 | 360 | 100.00% |
| 亚太地区 | Hyderabad | 13 | 3.61% |
| Asia Pacific | Jakarta | 360 | 100.00% |
| Asia Pacific | 马来西亚 | 360 | 100.00% |
| 亚太地区 | 墨尔本 | 360 | 100.00% |
| 亚太地区 | 孟买 | 360 | 100.00% |
| 亚太地区 | Osaka | 145 | 40.28% |
| Asia Pacific | Seoul | 246 | 68.33% |
| Asia Pacific | 新加坡 | 360 | 100.00% |
| 亚太地区 | 悉尼 | 360 | 100.00% |
| 亚太地区 | 泰国 | 360 | 100.00% |
| 亚太地区 | 东京 | 229 | 63.61% |
| 加拿大 | 卡尔加里 | 26 | 7.22% |
| 加拿大 | 中央 | 13 | 3.61% |
| 欧洲 | 法兰克福 | 244 | 67.78% |
| 欧洲 | 爱尔兰 | 16 | 4.44% |
| 欧洲 | 伦敦 | 12 | 3.33% |
| 欧洲 | 米兰 | 17 | 4.72% |
| Europe | Paris | 10 | 2.78% |
| Europe | 西班牙 | 15 | 4.17% |
| 欧洲 | 斯德哥尔摩 | 14 | 3.89% |
| 欧洲 | 苏黎世 | 17 | 4.72% |
| 以色列 | 特拉维夫 | 18 | 5.00% |
| 墨西哥 | 中东 | 13 | 3.61% |
| 中东部 | 巴林 | 201 | 55.83% |
| Middle East | UAE | 22 | 6.11% |
| South America | Sao Paulo | 12 | 3.33% |
| US East | 北弗吉尼亚 | 195 | 54.17% |
| 美国东部 | 俄亥俄 | 21 | 5.83% |
| 美国西部 | 北加州 | 21 | 5.83% |
| 美国西部 | Oregon | 19 | 5.28% |
其余八个实例完全没有受到影响，主要位于太平洋地区，这表明欺骗位置并未与这些主机共享网络路径。我们确认，当从真实客户端直接发送被审查的 QUIC 客户端初始数据包时，所有 32 个主机都能够触发审查。
防御。由于 UDP 数据包的无状态特性和易于伪造，因此在进行审查的同时抵御这种攻击是困难的。一种潜在的缓解方法是在检测到相应的 QUIC 服务器问候（Server Hello）和后续客户端数据包之后才触发审查，从而确保连接处于活动状态且未被一端伪造。然而，这种方法存在显著局限性。首先，它需要对连接进行有状态跟踪，这会对中间设备带来巨大的开销。此外，不对称路由（即客户端到服务器（C2S）路径与服务器到客户端（S2C）路径不同）固有的挑战使得准确跟踪连接变得复杂。如果路径不对称，中间设备可能完全无法观察到服务器问候消息，从而导致连接未被审查，并容易受到攻击。最后，攻击者仍可伪造连接的两端以触发阻止操作，这使得该方法成为一种无效的防御手段。
或者，审查员可以采用基于注入的阻断机制，避免基于丢包的残留审查。然而，这种方法也存在风险和局限性。例如，根据图 2 所示，当前解密相关的延迟会导致 QUIC 初始数据包（QUIC Server Initial）在注入的数据包到达之前就已经到达客户端并建立共享密钥，从而使注入失效。
由于 QUIC 协议旨在抵御基于注入的断开连接攻击，因此防御这种攻击具有独特挑战性，这促使人们需要残余审查机制。与此同时，UDP 的无连接特性使得欺骗客户端初始信息变得极为简单，从而在采用残余审查时为可用性攻击敞开了大门。要想让审查机构能够在 QUIC 中实施有针对性的封锁，同时防止可用性攻击，就需要精心的设计。
7. Circumvention
正如第 3.2 节所述，GFW 为了高效地以线速解析并阻止 QUIC 流量，做出了若干简化假设。这些设计选择再次表明，GFW 的设计者和开发者遵循“劣质胜于无”的哲学 [31]。这些假设是以牺牲审查系统的准确性和鲁棒性为代价的，从而为规避措施提供了机会。我们已负责任地向反审查社区和开源社区披露了我们所发现的规避策略。
使用源端口 <= 目的端口。如第 3.4 节所述，GFW 通过忽略 srcport <= dstport 的 UDP 数据报来专注于客户端到服务器的流量。绕过这种封锁的一个临时解决方案是使用大于或等于源端口的目的端口。对于规避代理的情况，可以将服务器运行在高于或等于客户端临时端口范围的端口上。Web 服务也可以运行在非标准的更高端口上，并通过 HTTP 标头中的 Alt-Svc 字段或 DNS HTTPS 记录向 Web 客户端提供这些端口。一种简单且与应用程序无关的方法是在更高的端口上进行监听，即使用 iptables 规则将发送到更高端口（例如 65535）的所有流量重定向到当前监听端口（例如 443），方法是使用 iptables -t nat -A PREROUTING -p udp --dport 65535 -j REDIRECT --to-port 443。这对于无法更改其监听端口或无法监听多个端口的软件尤其有用。
在任何 UDP 数据报之前发送 QUIC 客户端初始包。防火长城（GFW）的 QUIC 审查机制依赖于一个假设，即 QUIC 客户端初始包是新连接流中的第一个数据包。一种简单的绕过方法是在客户端初始包之前插入一个带有随机负载的 UDP 数据报。对于真正的 QUIC 服务器来说，第一个 UDP 数据报会被忽略，但防火长城将无法从第一个数据包中解析出 SNI 值并豁免该连接流。随后的客户端初始包不会被检查，连接将得以建立。我们通过在 QUIC 客户端初始包之前发送一个带有随机负载的 UDP 数据报，确认了这种防御措施能够有效绕过防火长城对连接的阻断。此外，我们也针对 Chromium Quiche [35] QUIC 服务器实现进行了测试，验证其确实会忽略随机 UDP 负载。
连接迁移。QUIC 的连接迁移功能利用连接 ID 在网络变更时保持会话的连续性。防火长城（GFW）采用了一种选择性过滤策略：它允许初始的 QUIC 数据包通过，但阻止客户端到服务器的后续数据包，同时不监测连接 ID。由于服务器到客户端的数据包未被阻止，因此在阻止生效前完成 1-RTT 握手并随后迁移到不同网络四元组（源 IP、源端口、目的 IP、目的端口）的客户端可以绕过防火长城。
相关方法在 QUICstep [44]中有所介绍，该方法引入了一种连接迁移技术，旨在规避 QUIC 审查。这种方法利用了 QUIC 的连接迁移功能，通过在一个安全通道上执行 QUIC 握手，而该通道可能具有低带宽和高延迟。握手成功完成后，连接会迁移到常规通信通道，从而实现所有数据的完全加密。
QUIC 客户端初始分片。QUIC 客户端的初始消息可以以多个 UDP 数据报的形式发送，也可以以单个包含多个 QUIC 帧的 UDP 数据报形式发送。截至 2025 年 1 月，防火长城（GFW）在将 TLS 客户端 Hello 消息拆分为多个 UDP 数据报或将其分割为单个 UDP 数据报中的多个 QUIC 帧时，不会重新组装该消息。这种行为可被利用来绕过防火长城对 QUIC 的审查，方法是将 SNI 分散到客户端初始消息中的多个 QUIC 加密帧中。
值得注意的是，Chrome 于 2021 年引入的 Chaos Protection 机制[19]将 QUIC 客户端初始消息分散到多个 QUIC 帧中，并在 UDP 数据报之间进行混洗。此外，Chrome（自版本 124 起[12]）支持 TLS 1.3 中的后量子密钥协商，从而可以使用 ML-KEM 和 Kyber 密钥。启用此功能会导致 QUIC 客户端初始消息被分割成多个 UDP 数据报，因为较大的密钥大小超过了最大 QUIC 数据包大小。这些特性恰好利用了防火长城无法重组碎片化的 QUIC 客户端初始数据包的能力，从而使 Chrome 的数据包能够绕过防火长城对 QUIC 的审查。
加密客户端问候（ECH）。ECH[51]允许客户端通过从 DNS HTTPS 记录获取的密钥，向服务器加密其 TLS 客户端问候消息的一部分。因此，SNI 扩展被加密，使客户端能够将其隐藏起来，避免被审查者发现。与 QUIC 的客户端初始消息加密不同，ECH 加密是不对称的，网络观察者无法对其进行解密。
审查员可以选择阻止所有包含 ECH 的载荷。然而，现代浏览器已经开始在 TLS 中发送“假”的 ECH 载荷，即使服务器并不支持它。截至 2025 年 1 月，防火长城（GFW）不会阻止包含 ECH 的 QUIC 载荷，除非外部（可解密的）SNI 指向被屏蔽的域名。
版本协商。QUIC 的版本协商机制[43 §6]提供了一个有趣的规避机会。该过程通常始于服务器收到一个包含不支持版本号的初始数据包时。作为回应，服务器发送一个版本协商数据包并等待客户端提交一个使用支持版本的新初始数据包。客户端可以通过故意发送一个未知版本的初始数据包来策略性地利用这一机制，使得第一个数据包的有效载荷无法解密。因此，连接流中的后续数据包能够绕过防火长城的过滤机制。随后，客户端可以继续使用支持的版本完成握手，从而有效地规避审查措施。
“权宜之计”解决方案值得部署吗？尽管这些解决方案都机会性地利用了防火墙的实现细节，但由于资源限制和其他优先事项[5]，中国可能无法轻易修补所有这些漏洞。在过去的研究中，我们已经看到类似的权宜之计解决方案在对抗审查方面持续有效多年[66 §8.3]。另一方面，许多此类突破封锁策略可以很容易地被使用 QUIC 协议的代理和突破封锁工具部署，而这些工具并不面临同样的官僚主义限制[5]。
负责任的披露。我们将有关中国 QUIC 审查以及突破封锁策略的发现分享给了反审查和开源社区。具体而言，我们联系了 Mozilla Firefox[48]、Mozilla Neqo 库[49]、quic-go 库[53]、Lantern[18]、Hysteria[39]、TUIC[59]、sing-box[54]、V2Ray[61]和 Xray[68]的开发者。
SNI 切片功能（通过客户端初始分片实现）已于 2025 年 1 月 27 日包含在 Neqo v0.12.0 版本中[24, 50]。自那时起，Mozilla Firefox 已集成此功能，并于 2025 年 4 月 30 日将其作为默认功能随版本 137 发布[24, 47]（可通过 about:config 页面中的 network.http.http3.sni-slicing 参数进行配置）。
表 7：quic-go v0.52.0 [53]的集成时间表。自 2025 年 5 月 23 日发布以来，流行的规避工具更新了其依赖项，这使得 SNI 切片默认启用，从而绕过了防火长城基于 QUIC SNI 的审查。
| 项目 | 版本 | 发布日期 |
|
| sing-box | 1.12.0-beta.17 | 2025 年 5 月 22 日 [ 55] |
|
| V2Ray | 5.33.0 | 2025 年 5 月 26 日 [ 62] |
|
| Xray | 25.6.8 | 2025 年 6 月 6 日 [ 69] |
|
| 歇斯底里症 | 2.6.2 | 2025 年 6 月 7 日 [40] |
|
quic-go 库在 2025 年 5 月 23 日发布的 v0.52.0 版本中引入了 SNI 切片技术[53]。如表 7 所示，这一更新使依赖于 quic-go 的突破封锁工具能够绕过防火墙对 QUIC SNI 的审查。
截至 2025 年 6 月，我们正与 Mozilla Neqo 和 Firefox 团队合作，在 Mozilla Firefox 中集成一种补充性的规避技术（在握手之前添加虚假负载），以提高对防火长城的抗性[72]。
8. 讨论
我们的发现提出了关于防火长城（GFW）对 QUIC 连接的封锁的两个关键问题：（1）它对常规网络流量的影响，以及（2）它对基于 QUIC 的代理的影响。在访问网站时，浏览器首先会使用 HTTP(S)-over-TCP 连接到服务器，只有当服务器通过 Alternate Service 头宣布支持 QUIC 时才会尝试使用 QUIC。因此，基于 HTTP 主机和基于 TLS SNI 的封锁仍然是阻止网络流量的主要机制，只有当一个网站未被这两种机制封锁时，防火长城的 QUIC 封锁才会生效。防火长城的 QUIC 封锁本质上充当了网络流量的次要审查机制。
专注于基于 QUIC 的代理，像 Hysteria [39]这样的工具日益流行，以及 IETF 的 MASQUE 工作组[41]正在进行的标准化工作，都表明该协议在 VPN 和代理领域具有巨大的未来潜力。QUIC 的流控和多路复用流、快速连接建立以及对连接迁移的支持，能够显著提升性能。通过在 HTTP/3 服务器中使用无提示身份验证，QUIC 隧道可以隐藏在主流的 HTTP/3 流量中，甚至可能逃避主动探测的检测。然而，我们的研究结果表明，防火长城（GFW）基于 SNI 的过滤机制会在握手过程的早期阶段破坏这些优势，从而有效地阻止许多 QUIC 代理的使用。
一个明显的例子是 Cloudflare 的 WARP VPN，它最近开始使用 MASQUE[17]（HTTP/3-over-QUIC 代理）来传输流量。我们发现，用于 MASQUE 的子域名被防火长城（GFW）屏蔽，从而中断了 VPN 客户端的启动握手。这种模式表明防火长城明确针对 MASQUE 代理。类似地，Hysteria 也面临类似的情况：不仅其主项目域名 v2.hysteria.network 被屏蔽，而且用户为 Hysteria 代理所使用的自定义域名也被屏蔽。
9. Conclusion
针对 2024 年 4 月 7 日 GFW 基于 QUIC SNI 的审查，我们开展了测量实验，以识别、监测、揭露并绕过这一机制。我们发现这种新型封锁机制可被用于阻止中国境内和境外主机之间的任意 UDP 流量。此外，我们还提出了一种旁路规避策略，在适度的流量负载下可降低 GFW 的有效性。我们与多个开源社区合作，将这些规避策略集成到 Mozilla Firefox 浏览器、quic-go 库以及所有主要基于 QUIC 的规避工具中。
致谢
我们感谢匿名的牧羊人和审稿人提出的宝贵意见。我们的研究最初是由勇敢的中国用户发起的，他们率先报告了 QUIC 的审查情况，我们对他们表示深深的感激。我们特别感谢匿名的 RQWDKM，他与我们一起进行了初步测量和调查，参与了讨论，并为本文提供了详细的反馈。
我们衷心感谢 Mozilla Neqo 和 Firefox 团队的许多成员，感谢他们在讨论、支持以及实施规避方案方面所作出的宝贵贡献。在此特别感谢 Christoph Kerschbaumer、Kershaw Jang、Lars Eggert、Martin Thomson、Max Inden 和 Valentin Gosu 等人。
我们特别感谢 Marten Seemann 将规避方案整合到 quic-go 中。我们也非常感谢 Lantern 的 Adam Fisk 在这一努力中的支持与协调。此外，我们还感谢 Hysteria、Lantern、sing-box、TUIC、V2Ray 和 Xray 的开发者和贡献者，他们提供了在线讨论空间，并迅速采纳了规避策略。
最后，我们感谢以下人士以及许多其他不愿透露姓名的人士，感谢他们的支持、反馈和富有见地的讨论：Bill Marczak、Dan Boneh、David Fifield、David Mazieres、Jeffrey Knockel、Juraj Somorovsky、klzgrad、nekohasekai、Nick Sullivan、Niklas Niere 和 Prateek Mittal。
这项工作部分得到了美国国家科学基金会（NSF）CNS-2145783 号资助的支持，但该资助因机构优先事项调整而提前终止[30]，对正在进行的研究工作产生了重大影响。
这项工作还得到了美国国家科学基金会（NSF）CNS-2319080 和 CNS-2333965 号资助的部分支持，以及斯隆研究奖学金（Sloan Research Fellowship）和国防高级研究计划局（DARPA）青年教师奖项目（Young Faculty Award program）的支持，资助编号为 DARPA-RA-21-03-09-YFA9-FP-003。文中表达的观点、意见和/或结论均属作者个人见解，不应被视为代表美国国防部或美国政府的官方观点或政策。
伦理考量
我们的工作中存在两个主要的伦理考量：实验对网络基础设施可能造成的损害，以及未发现的弱点的披露。
可用性攻击。在第 6 节中，我们证明了防火长城（GFW）可以被利用来对任意互联网主机发起可用性攻击。为了降低实验过程中意外造成附带损害的风险，我们针对自己的服务器进行了这种攻击的演示。尽管该攻击涉及伪造 IP 数据包，但我们伪装成的 IP 地址本身就已经在我们的控制之下。此次攻击的结果是，在短暂的一段时间内，我们自己的 EC2 实例无法与中国境内的服务器进行通信。
此外，我们还从先前计算机安全与伦理研究[45]提出的两种伦理框架的角度分析了我们的工作。从功利主义伦理视角来看，此次攻击造成的损害风险微乎其微。从义务论的观点来看，仅攻击我们自己的主机这一选择限制了对其他人的牵涉，从而减轻了我们对他人的责任。
GFW 降级攻击。在第 5 节中，我们介绍了一种通过发送大量 QUIC 初始数据包来降低 GFW 阻止 QUIC 连接能力的方法。本实验存在一些风险，这些风险影响了我们的实验设计。首先，我们考虑了破坏 GFW 是否符合道德标准的问题，因为 GFW 本身就是一个造成伤害的系统[28 §9.c] [28 §9.B] [3, 42]，甚至其创建者也承认这一点[71 §1]。一方面，GFW 并非我们所控制的系统，对其进行破坏可能会带来负面或未知的后果。另一方面，使 GFW 无法实施审查将为中国用户提供益处，因为他们的互联网使用受到限制，这与他们的人权相悖[60]。基于这些考量，我们得出结论：只要对 GFW 以外系统的风险最小化，破坏 GFW 本身在道德上就是合理的。
然而，考虑对其他系统造成的影响至关重要。例如，如果破坏了防火长城（GFW），导致所有流量中断，我们的实验就有可能干扰中国与世界其他地区之间的正常互联网通信。事实上，尽管我们在第 3.1 节中的分析表明，防火长城对 QUIC 协议的审查并非完全位于路径之中，但我们仍然担心其路径内部分可能会对所有流量产生影响。然而，我们对审查效果昼夜模式的观察为我们提供了有力证据，证明情况并非如此。在白天 QUIC 连接量较高的时候，防火长城仅能阻止一小部分连接（图 4），而未被审查的 QUIC 和其他类型的流量则不受影响。
最后，我们考虑到了实验可能对网络本身造成干扰的风险。由于我们发送了大量的 QUIC 数据包，有可能导致网络链路或目标服务器不堪重负。为此，我们采取了几项措施来降低这种风险。首先，我们将发送速率限制在每秒 150 万个数据包，这仅消耗不到 4 Gbps 的带宽。我们确认了与上游互联网服务提供商的连接带宽至少为 40 Gbps，而跨国链路通常为 100 Gbps 甚至多 Tbps，这意味着我们的流量仅占其容量的一小部分。其次，我们限制了数据包的 TTL（生存时间），以确保它们能够通过防火长城（GFW），但不会到达目标网络。这种方法将影响范围限制在大型核心互联网链路上，这些链路可以轻松处理相对较小的流量。第三，我们在测试的各个网络上持续监测多种健康指标，包括 ZMap 扫描和双向连通性测试。我们发现，在实验期间没有观察到任何网络性能下降的现象，表明我们的流量并未对网络造成过载。
从义务论的角度来看[60 §4.1]，我们必须考虑他人的权利（例如中国互联网用户）以及我们在研究过程中的意图。从这一观点出发，我们的研究方法在两种道德责任之间产生了直接冲突。一方面，我们有义务避免（可能）干扰他人的网络资源；另一方面，我们的实验也履行了一项防止持续损害的职责，即防止防火长城（GFW）的审查。我们认为后者构成了更高的道德准则，因此决定继续进行我们的实验。从结果论的角度来看[60 §4.1]，我们必须权衡利弊得失。我们的攻击所带来的好处是，它揭示了一种恢复用户信息访问权限的方法，同时将对其他网络和主机造成损害的风险降至最低。
披露。漏洞披露是道德安全研究的标准做法，因为它有助于改进所研究的系统，并保护受该脆弱系统影响的个人免受攻击。在我们的案例中，披露在伦理上较为复杂，因为我们研究的是一个需要被改进的有害系统（即防火长城）。另一方面，保护可能因防火长城中的漏洞而遭受攻击的互联网用户也非常重要。我们仔细考虑了是否以及哪些漏洞需要披露，以保护用户，同时不提高防火长城审查的能力。我们的目标是在“帮助”中国加强其审查制度的同时，通过保护用户来最大化利益，并将造成伤害的风险降至最低。
考虑到这些因素，我们决定向审查机构披露可用性攻击（第 6 节），因为这种攻击可能被用来损害用户。2025 年 1 月 22 日，我们将这一漏洞告知了 CNCERT，并推荐移除存在漏洞的 QUIC 审查设备。电子邮件副本见附录 C。为确保清晰起见，我们通过英文和中文两种语言发送了电子邮件联系审查人员，并提供了两个私人网页的链接（每种语言各一个），详细说明了该攻击。尽管我们没有收到任何回复或正式确认，但在 2025 年 1 月 24 日至 2 月 24 日期间，我们观察到共有 37 次访问了英文版的私人网页（而中文版则无访问记录），这表明我们的信息已被接收。CNCERT 缺乏直接回应表明了向互联网审查机构披露漏洞所面临的挑战[9 §VIII]。中国当局很少承认审查制度的存在[57]，更不用说承认其风险或考虑拆除其审查系统。
然而，自 2025 年 3 月 13 日起，我们观察到 GFW 的行为发生了一些变化：来自中国境外的 QUIC 流量不再触发封锁。这一变化在一定程度上缓解了该漏洞，因为针对中国的可用性攻击将无法再从境外发起。尽管尚不清楚这一变化是否与我们的披露有关，但过去曾有类似情况发生，即在 GFW 的 ESNI 审查被公开披露后[10]出现了类似的改变。
尽管采取了上述缓解措施，如果攻击者在中国境内发起攻击，则可用性攻击仍然可行。如果攻击者的网络路径与受害者的路径经过相同的 GFW 节点，那么位于中国的攻击者（未进行出口过滤）仍可阻止中国境内主机与任何境外目的地之间的任意 UDP 流量。由于中国审查机构不太可能移除 QUIC 审查设备，而这是完全缓解此漏洞的唯一方法，因此我们的风险缓解策略侧重于公开透明。通过发表本文，我们希望揭示并宣传这一漏洞，以提高人们对大规模审查系统安全影响和潜在危害的广泛认识[28]。
我们选择不直接向审查机构通报降级攻击（第 5 节）。相反，我们首先私下向反审查社区披露了这一漏洞，随后在本文发表时进行了公开披露。我们选择这种披露策略是因为降级攻击仅影响防火长城的基础设施，而不影响用户。如果向审查机构进行私下披露，他们将有机会在更广泛的反审查社区意识到并从该漏洞中获益之前，加强其审查机制。
虽然公开披露这一漏洞可能会促使审查者修复他们可能早已知道存在的弱点（现在他们也知道其他人也意识到了这一点），但我们认为这种公开披露的价值超过了此类风险。通过与更广泛的受众分享有关审查者弱点的这些见解，我们可以更好地为未来的协议设计和反审查策略提供信息。例如，QUIC 初始数据包被设计为加密的，尽管中间盒可以对其进行解密，部分原因是为了增加它们处理该数据包的难度。防火长城的 QUIC 审查系统难以跟上解密的速度，这表明即使略微提高处理成本的设计选择仍然可以降低审查者的整体效率[5]。
不收集个人身份信息。我们的工作不涉及人类受试者，并且在所有数据中均未收集任何个人身份信息（PII）。
开放科学
为了鼓励未来的研究工作并保持可重复性，我们已公开发布了本研究的代码和数据。为了便于更广泛的访问，本文还提供英文和中文两种语言的 HTML 格式版本。该项目主页地址为：https://gfwreport/publications/usenixsecurity25/en/。
参考文献
- D. Adrian. A new path for kyber on the web. URL: https://security.googleblog.com/2024/09/a-new-path-for-kyber-on-web.html.
-
Alice, Bob, Carol, J. Beznazwy 和 A. Houmansadr. How China detects and blocks Shadowsocks. 在互联网测量会议中。ACM，2020 年。URL：https://censorbib.nymity.ch/pdf/Alice2020a.pdf。 -
D. Anderson. Splinternet behind the Great Firewall of China：一旦中国向世界敞开大门，就再也无法关闭了。Queue，10(11)：40–49，2012 年 11 月。URL：https://queue.acm.org/detail.cfm?id=2405036，doi：10.1145/2390756.2405036。 -
匿名. 通往对“防火长城”DNS 审查的全面认识. 载于《互联网上的自由与开放通信》. USENIX, 2014. URL: https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.pdf. -
匿名和匿名. 分享一个修改后的 Shadowsocks 以及我们对猫鼠游戏的看法，2022 年 10 月. URL: https://github.com/net4people/bbs/issues/136. -
匿名, A. A. Niaki, N. P. Hoang, P. Gill 和 A. Houmansadr. 三元审查者：揭秘“防火长城”的 DNS 审查行为. 载于《互联网上的自由与开放通信》. USENIX, 2020. URL: https://www.usenix.org/system/files/foci20-paper-anonymous_0.pdf. -
M. Bishop. HTTP/3。RFC 9114，2022 年 6 月。网址：https://www.rfc-editor.org/info/rfc9114，DOI：10.17487/RFC9114。 -
K. Bock、A. Alaraj、Y. Fax、K. Hurley、E. Wustrow 和 D. Levin。利用中间盒进行 TCP 反射放大攻击。载于 USENIX 安全研讨会论文集。USENIX，2021 年。网址：https://www.usenix.org/system/files/sec21-bock.pdf。 -
K. Bock、P. Bharadwaj、J. Singh 和 D. Levin。你的审查者就是我的审查者：将审查基础设施用于可用性攻击。载于防御技术研讨会论文集。IEEE，2021 年。网址：https://www.cs.umd.edu/~dml/papers/weaponizing_woot21.pdf。 -
K. Bock、iyouport、匿名、L.-H. Merino、D. Fifield、A. Houmansadr 和 D. Levin。《揭露并绕过中国对 ESNI 的审查》，2020 年 8 月。网址：https://github.com/net4people/bbs/issues/43#issuecomment-673322409。 -
Z. Chai、A. Ghafari 和 A. Houmansadr。《加密 SNI (ESNI) 对规避审查的重要性》。载于《互联网上的自由开放通信》。USENIX，2019 年。网址：https://www.usenix.org/system/files/foci19-paper_chai_update.pdf。 -
Chrome 开发者。《Chrome 124 — 发行说明》，2024 年 4 月。网址：https://developer.chrome.com/release-notes/124。 -
R. Clayton、S. J. Murdoch 和 R. N. M. Watson。《忽略中国的防火长城》。载于《隐私增强技术》，第 20–35 页。Springer 出版社，2006 年。网址：https://www.cl.cam.ac.uk/~rnc1/ignoring.pdf。 -
Cloudflare。Cloudflare Radar – 全球采用与使用情况，2025 年。网址：https://radar.cloudflare.com/adoption-and-usage?dateStart=2024-01-01&dateEnd=2024-12-31。 -
J. R. Crandall、D. Zinn、M. Byrd、E. Barr 和 R. East。《ConceptDoppler：一种用于互联网审查的天气追踪器》。载于《计算机与通信安全》，第 352–365 页。ACM 出版社，2007 年。网址：http://www.csd.uoc.gr/~hy558/papers/conceptdoppler.pdf。 -
严重错误。在乌兹别克斯坦，带有加密客户端问候扩展的 QUIC 流被阻止。NTC 党论坛，2024 年 12 月。网址：https://ntc.party/t/13953。 -
丹·霍尔。零信任 WARP：使用 MASQUE 进行隧道传输。网址：https://blog.cloudflare.com/zero-trust-warp-with-a-masque/。 -
L. 开发者。Lantern。网址：https://github.com/getlantern。 -
dschinazi. QUIC 中的混乱保护，2025 年。网址：https://quiche.googlesource.com/quiche/+/cb6b51054274cb2c939264faf34a1776e0a5bab7。 -
H. Duan、N. Weaver、Z. Zhao、M. Hu、J. Liang、J. Jiang、K. Li 和 V. Paxson。Hold-On：防范路径上的 DNS 中毒攻击。载于《Securing and Trusting Internet Names》，英国国家物理实验室，2012 年。网址：https://www.icir.org/vern/papers/hold-on.satin12.pdf。 -
M. Duke. QUIC 版本 2。RFC 9369，2023 年 5 月。网址：https://www.rfc-editor.org/info/rfc9369。 -
A. Dunna、C. O’Brien 和 P. Gill。分析中国对未发布的 Tor 桥的封锁。载于《互联网上的自由与开放通信》。USENIX，2018 年。网址：https://www.usenix.org/system/files/conference/foci18/foci18-paper-dunna.pdf。 -
Z. Durumeric、E. Wustrow 和 J.A. Halderman。ZMap：快速的互联网范围扫描及其安全应用。载于 USENIX 安全研讨会，USENIX，2013 年 8 月。网址：https://www.usenix.org/conference/usenixsecurity13/technical-sessions/paper/durumeric。 -
L. Eggert。拉取请求 #2228：功能：随机化客户端初始加密数据。https://github.com/mozilla/neqo/pull/2228。 -
K. Elmenhorst、B. Schütz、N. Aschenbruck 和 S. Basso。QUIC 上的 HTTP/3 网络审查测量。载于《互联网测量会议》。ACM，2021 年。网址：https://dl.acm.org/doi/pdf/10.1145/3487552.3487836。 -
R. Ensafi、D. Fifield、P. Winter、N. Feamster、N. Weaver 和 V. Paxson。研究防火长城如何发现隐藏的规避服务器。载于《互联网测量会议》。ACM，2015 年。网址：https://conferences2.sigcomm.org/imc/2015/papers/p445.pdf。 -
A. L. 等人。QUIC 传输协议：设计与互联网规模部署。SIGCOMM ’17。ACM，2017 年。DOI：10.1145/3098822.3098842。 -
S. Fan、J. Sippe、S. San、J. Sheffey、D. Fifield、A. Houmansadr、E. Wedwards 和 E. Wustrow。Wallbleed：中国防火长城中的内存泄露漏洞。载于《网络与分布式系统安全》。国际互联网协会，2025 年。网址：https://gfw.report/publications/ndss25/data/paper/wallbleed.pdf。 -
O. Farnan、A. Darer 和 J. Wright。毒害井水——探索防火长城的中毒 DNS 响应。载于《电子社会中的隐私研讨会》。ACM，2016 年。网址：https://dl.acm.org/authorize?N25517。 -
美国国家科学基金会。关于 NSF 优先事项的最新消息。https://www.nsf.gov/updates-on-priorities，2025。 -
R. P. Gabriel。更糟更好。网址：https://dreamsongs.com/WorseIsBetter.html。 -
gfw-report。2020 年 8 月，ESNI 触发后迅速阻止连接。网址：https://github.com/net4people/bbs/issues/43#issuecomment-673490763。 -
P. God。带有 *.eu.org SNI 的 QUIC 连接已被阻止。Telegram 帖子，2024 年。网址：https://t.me/c/1166154022/909198。 -
J. Goldkorn. 方滨兴与防火墙。载于 G. R. Barmé 和 J. Goldkorn 主编的《中国故事年鉴 2013：文明化中国》（China Story Yearbook 2013: Civilising China），澳大利亚世界中国研究中心（Australian Centre on China in the World）。网址：https://www.thechinastory.org/yearbooks/yearbook-2013/chapter-6-chinas-internet-a-civilising-process/fang-binxing-and-the-great-firewall/。 -
Google. QUICHE：QUIC、HTTP/2、HTTP/3 及相关协议工具包。网址：https://github.com/google/quiche。 -
L. Hanson. 中国的互联网获得更强大的骨干网络。https://www.forbes.com/sites/lisachanson/2015/02/24/the-chinese-internet-gets-a-stronger-backbone。 -
N. P. Hoang、J. Dalek、M. Crete-Nishihata、N. Christin、V. Yegneswaran、M. Polychronakis 和 N. Feamster。GFWeb：大规模测量“长城防火墙”的网络审查。载于 USENIX 安全研讨会。USENIX，2024 年。网址：https://www.usenix.org/system/files/sec24fall-prepub-310-hoang.pdf。 -
N. P. Hoang、A. A. Niaki、J. Dalek、J. Knockel、P. Lin、B. Marczak、M. Crete-Nishihata、P. Gill 和 M. Polychronakis。《防火长城有多厉害？测量中国的 DNS 审查》。载于 USENIX 安全研讨会。USENIX，2021 年。网址：https://www.usenix.org/system/files/sec21-hoang.pdf。 -
Hysteria 开发者。Hysteria。网址：https://github.com/apernet/hysteria。 -
Hysteria 开发者。Hysteria 软件发布。网址：https://github.com/apernet/hysteria/releases/tag/app%2Fv2.6.2。 -
IETF。QUIC 加密上的多路复用应用基底（masque），2025 年。网址：https://datatracker.ietf.org/wg/masque/about/。 -
互联网协会。什么时候互联网不是互联网？，2023 年 12 月。网址：https://www.internetsociety.org/resources/internet-fragmentation/the-chinese-firewall/。 -
J. Iyengar 和 M. Thomson。QUIC：一种基于 UDP 的多路复用安全传输协议。RFC 9000，2021 年 5 月。网址：https://www.rfc-editor.org/info/rfc9000，doi:10.17487/RFC9000。 -
W. 贾，M. 王，L. 王和 P. 米塔尔。QUICstep：绕过基于 QUIC 的审查，2023 年。网址：https://arxiv.org/abs/2304.01073。 -
T. Kohno、Y. Acar 和 W. Loh。伦理框架与计算机安全中的电车难题：对话的基础。载于第 32 届 USENIX 安全研讨会（USENIX Security 23），2023 年。网址：https://securityethics.cs.washington.edu/。 -
madeye。QUIC 传输协议和 HTTP/3 的美味实现，2024 年。网址：https://github.com/cloudflare/quiche。 -
Mozilla 开发者。Bug 1942325 - 在 mozilla-central 中将 Neqo 更新至 v0.12.2。https://bugzilla.mozilla.org/show_bug.cgi?id=1942325。 -
Mozilla 基金会。Firefox 网页浏览器源代码。https://github.com/mozilla-firefox/firefox。 -
Mozilla 基金会。Neqo：下一代 QUIC 客户端和服务器库。https://github.com/mozilla/neqo。 -
Mozilla Neqo 团队。Neqo 0.12.0 版本发布。https://github.com/mozilla/neqo/releases/tag/v0.12.0。 -
E. Rescorla、K. Oku、N. Sullivan 和 C. A. Wood。TLS 加密客户端问候。互联网草案，2025 年 3 月。正在进行中。网址：https://datatracker.ietf.org/doc/draft-ietf-tls-esni/24/。 -
Sakamoto 和 E. Wedwards。Bleeding wall：对防火长城的血液学分析。载于《互联网上的自由与开放通信》，2024 年。网址：https://www.petsymposium.org/foci/2024/foci-2024-0002.pdf。 -
M. Seemann。quic-go：纯 Go 中的 QUIC 实现（版本 0.52.0）。https://github.com/quic-go/quic-go/releases/tag/v0.52.0。 -
Sing-box 开发者。Sing-box。网址：https://github.com/SagerNet/sing-box。 -
sing-box 开发者。sing-box 软件发布。网址：https://github.com/SagerNet/sing-box/releases/tag/v1.12.0-beta.17。 -
N. 软件。临时端口范围。网址：https://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html。 -
M. Streisand、E. Wustrow 和 A. Houmansadr。《段落都去哪儿了？检测并揭露中文翻译中的审查》。载于《互联网上的自由与开放通信》，2023 年。网址：https://www.petsymposium.org/foci/2023/foci-2023-0001.pdf。 -
M. Thomson 和 S. Turner。《使用 TLS 保护 QUIC》。RFC 9001。网址：https://www.rfc-editor.org/info/rfc9001。 -
TUIC 协议。tuic：一种轻量级的 0-RTT 代理协议。https://github.com/tuic-protocol/tuic。 -
联合国人权理事会。《在互联网上促进、保护和享有各项人权》。https://www.article19.org/data/files/Internet_Statement_Adopted.pdf，2016 年 6 月。决议 A/HRC/32/L.20。 -
V2Ray 开发者。V2Ray。网址：https://github.com/v2fly/v2ray-core。 -
V2Ray 开发者。V2Ray 核心软件发布。网址：https://github.com/v2fly/v2ray-core/releases/tag/v5.33.0。 -
ValdikSS。限制 HTTP/3 (QUIC) - post 10，ntc.party，2022 年 3 月。访问日期：2024-05-27。网址：https://ntc.party/t/1823/10。 -
Z. Wang, Y. Cao, Z. Qian, C. Song 和 S. V. Krishnamurthy。你的状态不是我的：深入研究规避有状态的互联网审查。载于互联网测量会议。ACM，2017 年。网址：https://www.cs.ucr.edu/~krish/imc17.pdf。 -
P. Winter 和 S. Lindskog。中国防火长城如何阻止 Tor。载于《互联网上的自由与开放通信》。USENIX，2012 年。网址：https://www.usenix.org/system/files/conference/foci12/foci12-final2.pdf。 -
M. Wu, J. Sippe, D. Sivakumar, J. Burg, P. Anderson, X. Wang, K. Bock, A. Houmansadr, D. Levin 和 E. Wustrow。中国防火长城如何检测并阻止完全加密的流量。载于 USENIX 安全研讨会。USENIX，2023 年。网址：https://www.usenix.org/system/files/sec23fall-prepub-234-wu-mingshi.pdf。 -
M. Wu、A. Zohaib、Z. Durumeric、A. Houmansadr 和 E. Wustrow。《墙后之墙：中国新兴的区域性审查》。载于《安全与隐私研讨会》，IEEE，2025 年。网址：https://gfw.report/publications/sp25/data/paper/paper.pdf。 -
XRay 开发者。XRay。网址：https://github.com/XTLS/Xray-core。 -
Xray 开发者。Xray 软件发布。网址：https://github.com/XTLS/Xray-core/releases/tag/v25.6.8。 -
D. Xue、B. Mixon-Baca、ValdikSS、A. Ablove、B. Kujath、J. R. Crandall 和 R. Ensafi。《TSPU：俄罗斯的去中心化审查系统》。载于《互联网测量会议》，ACM，2022 年。网址：https://dl.acm.org/doi/pdf/10.1145/3517745.3561461。 -
B. Yan、B. Fang、B. Li 和 Y. Wang。《DNS 欺骗攻击的检测与防御》，2006 年 11 月。网址：https://github.com/user-attachments/files/18172972/Yan2006a.pdf。 -
A. Zohaib。向 QUIC 握手添加鲁棒性检查。https://github.com/mozilla/neqo/pull/2613。
A. 全天的阻断延迟
图 10 显示了防火长城（GFW）的阻断延迟如何随一天的变化而变化。阻断延迟是指在观察到带有被阻止 SNI 的 QUIC 初始数据包后，防火长城阻断连接所花费的时间。它被测量为客户端发送 QUIC 初始数据包的时间与客户端发送第一个被防火长城丢弃的 UDP 数据报之间的时间差。
图 10：箱形图显示了防火长城阻断连接所需时间的分布。x 轴采用对数刻度。绿色三角形标记平均值；须线显示最小值和最大值。
全天的最小阻断延迟始终低于 100 毫秒，这可能是由防火长城内部处理和反应速度所限制的。
最大阻断延迟在一天中有所不同，这可能受到防火长城（GFW）处理的 QUIC 连接数量的影响（如第 5 节所述）。在通常人类活动较少的时段，例如凌晨（0 时至 6 时），防火长城阻断连接所需的时间相对较短，平均阻断延迟约为 150 毫秒。相比之下，在人类活动高峰时段（7 时至 23 时），平均阻断延迟可升至 800 毫秒，而在下午 3 时左右观察到的最大阻断延迟达到 7,000 毫秒。
B. 基于端口的流量过滤
为了进一步确认我们在第 3.3 节中关于 GFW 基于源端口和目的端口的过滤启发式方法的发现，我们将分析范围扩展到更广泛的端口范围。我们采用相同的方法，以 1000 为步长，检查了从 1 到 65535 的更广泛端口范围，并且在测试和分析中也包括了端口 65535。
图 11 展示了 GFW 在这一扩展端口范围内的阻断行为。这些结果证实了我们的初步发现：如果 QUIC 初始数据包的源端口小于或等于目的端口，则 GFW 不会跟踪或阻止 UDP 流量。
图 11：如果 QUIC 初始数据包的源端口小于或等于其目标端口，则审查员不会跟踪或阻止 UDP 流。此规则适用于从 1 到 65535 的所有端口号。
C. 向审查员发送漏洞披露电子邮件
如第 9 节所述，我们决定向审查机构披露可用性攻击（第 6 节），因为这种攻击可能会利用防火长城（GFW）对用户造成额外损害。2025 年 1 月 22 日，我们向 CNCERT/CC 以及被广泛称为“防火长城之父”的方滨兴发送了以下电子邮件[34]。我们建议移除存在漏洞的 QUIC 审查设备，并部署出口过滤以防止 IP 欺骗攻击。我们用英文和中文分别撰写了这封邮件，并提供了两个私人网页的链接，一个为英文版，另一个为中文版，其中详细介绍了该攻击。尽管我们没有收到任何回复或正式确认，但我们观察到，在 2025 年 1 月 24 日星期五下午 2:04（UTC+8）至 2 月 24 日星期一上午 9:35（UTC+8）期间，共有 37 次访问了该英文私人网页（而中文网页则无访问记录）。
SUBJECT: Disclose a Vulnerability in the GFW’s QUIC Filtering Mechanism FROM: gfw.report <gfw.report@protonmail.com> TO: CNCERT/CC <cncert@cert.org.cn> CC: Fang Binxing <fangbx@iie.ac.cn> DATE: Thu, 23 Jan 2025 12:01:46 +0000 Dear CNCERT Team, We are writing to disclose a vulnerability introduced by the QUIC filtering mechanism deployed on the backbone network in China, active since at least April 7, 2024. This vulnerability allows a network attacker capable of spoofing IP packets, to use the Great Firewall of China (GFW) to disrupt or block communication between hosts inside and outside of China for an extended period. Below we introduce the details, impact, and mitigation of this vulnerability. We also maintained an up-to-date version at: [The URL to the English responsible disclosure page redacted.] ## Vulnerability Details An attacker can send a QUIC Initial packet (see below example) with an SNI on the firewall’s blocklist (e.g., google.com) to a specific IP:port pair, triggering the GFW’s residual censorship for approximately 180 seconds. If the attacker spoofs the source IP address to that of a victim inside China, this mechanism can be exploited to block the victim’s IP address from connecting to the specified server IP:port for three minutes. Similarly, one can spoof the source IP address to be a victim server outside China, and send to a range of ports of a victim IP address in China. By repeatedly sending spoofed QUIC Initial packets, the attacker can sustain the block indefinitely. When the firewall’s censorship is triggered, it blocks based on three-tuple (source IP, destination IP, destination UDP port) for 3 minutes (180 seconds). Censorship can be triggered with a single UDP packet (see example below) containing a QUIC Initial packet with an SNI on the firewall’s blocklist (e.g., google.com). Normally, this will only block between a client attempting to connect and the server. However, because the blocking can be triggered from a single UDP packet, a network attacker that can spoof IP packets can easily trigger the firewall into blocking other hosts. For example, suppose there is a host in China at 19.89.5.35, and a DNS server outside China at 4.2.2.1 on UDP port 53. If an attacker sends a UDP packet (such as provided below) from 19.89.5.35:x (for any source port x) to 4.2.2.1:53, this will trigger the firewall to block 19.89.5.35 from sending any packets to 4.2.2.1:53 for 3 minutes. The attacker can continue to spoof packets from different source ports to extend the block indefinitely. ## Impact The development and deployment of the GFW, along with this identified issue, poses a severe risk to users in China and has the potential to disrupt communications on a large scale. For instance, it could be exploited to block significant portions of UDP-based DNS traffic between DNS resolvers in China and external networks, causing widespread connectivity issues. To demonstrate the impact this attack could have, we conducted an experiment using 32 Amazon EC2 instances globally distributed. We ran the attack for 30 minutes, sending a DNS request from each EC2 instance to a VPS we control in Guangzhou. At the same time, a non-egress filtering box in the US spoofed packets from each EC2 IP to the Guangzhou box with a QUIC Initial packet containing an SNI from the firewall’s blocklist. The map below shows which boxes were affected with just a single spoofing vantage point. Points in green experienced no connectivity issues, while points in red struggled to successfully send requests to the Guangzhou host. The black point in Guangzhou shows the location of our testing victim server and the black point in the US shows the location of our spoofing server.
评论
One Comment
在 4.1 节的维恩图中，我有一种感觉，这种域名黑名单是由不同的实体分散管理的，就像敏感关键词列表在不同的中国社交平台上也有所不同一样。
例如，TLS SNI 列表可能由网络安全公司 Q 管理，而 QUIC 列表则由 Z 负责……
CNCERT 的合作公司：https://web.archive.org/web/20250315145412/https://www.cert.org.cn/publish/main/32/10.html
负责任披露。我们已与中国反审查和开源社区分享了有关中国 QUIC 审查及其规避策略的发现。具体而言，我们联系了
哈哈，你唯一没有联系的实体是防火长城的领导者和运营者，中国网络空间管理局表示。不，实际上你在最后联系了他们。
你有没有注意到 CNCERT 自 2003 年以来在其网站上发布的 PGP 密钥现在太弱而无法信任？