Year: 2025, Pages: 1307-1324
DOI Bookmark: 10.1109/SP61157.2025.00152
Authors
Mingshi Wu, GFW Report
Ali Zohaib, University of Massachusetts Amherst
Zakir Durumeric, Stanford University
Amir Houmansadr, University of Massachusetts Amherst
Eric Wustrow, University of Colorado Boulder
223600b307.pdf (1000.8 KB)
== OCR 页面 1 开始 ==
一堵墙后的另一堵墙：中国新兴的区域性网络审查
Mingshi Wu*
GFW Report
gfw.report@protonmail.com
Zakir Durumeric
斯坦福大学
zakir@cs.stanford.edu
Amir Houmansadr
马萨诸塞大学阿默斯特分校
amir@cs.umass.edu
Ali Zohaib*
马萨诸塞大学阿默斯特分校
azohaib@umass.edu
Eric Wustrow
科罗拉多大学博尔德分校
ewust@colorado.edu
摘要 - 长期以来，中国通过相对集中的政策和统一的实施（即中国的防火长城，GFW）来协调其互联网审查。然而，自 2023 年 8 月以来，有轶事报告表明河南省部署了自己的区域性审查。在这项工作中，我们描述了河南省的省级审查特征，并将其与国家级的 GFW 进行了比较。我们发现河南已经建立了基于 TLS SNI 和 HTTP Host 的审查机制，用于检查和阻止离开该省的流量。虽然河南防火墙不如 GFW 复杂和健壮，无法应对典型的网络变化，但其对二级域名的不稳定和激进的封锁行为，使得其在某些时间点封锁的网站数量是 GFW 的十倍。基于观察到的解析缺陷和注入行为，我们引入了简单的客户端方法来绕过河南省的审查。我们的工作记录了中国区域性审查兴起的一个令人警惕的迹象。
- 引言
中华人民共和国开发并维护着世界上最复杂的互联网审查机器之一，俗称防火长城 (GFW)。通过 DNS 投毒 [1], [2], [3], [4], [5]，HTTP Host 头部过滤 [6], [7], [8], [9]，TLS SNI/ESNI 过滤 [2], [9], [10] [11 §3]，IP 地址封锁 [2 §4]，主动探测 [12], [13], [14] [15 §5]，以及代理流量检测 [15 §4]，中国阻止其公民访问大量的互联网内容和服务。
长期以来，中国的审查机器一直被认为在政策和实施方面都相对集中地运作。实证测量揭示了中国对审查政策 [3], [4], [9], [15]、软件更新 [16 §4.5] [5 §VII] 和基础设施 [14 §3.4] [4 §5] 的统一和协调管理。审查设备部署在国家边界 [4], [17], [18]，在那里它们检查和过滤进出国家的流量。因此，在中国境内交换的流量不会受到 GFW 的检查或阻止。
然而，最近的轶事表明，这种集中和统一的审查模式可能不再完全反映现实情况。2023 年 8 月，中国河南省——人口第三大省和关键劳动力枢纽——的用户开始报告无法访问的网站数量激增，而这些网站在中国其他地方是可以访问的 [19]。
在这项工作中¹，我们首先探讨了河南区域性审查发现后提出的一个自然问题（第 3 节）：中国其他省份是否部署了相同或类似的区域性审查？我们在中国的七个省市进行了测量研究，包括北京、上海、广东、浙江、江苏、四川和河南，以识别潜在的区域性审查。可能受到我们在中国可以访问的观测点的限制，我们在除河南外的六个省份没有发现区域性审查的证据。
然后，我们分析了河南省新兴的区域性审查，将其政策和实施与国家级 GFW 进行比较。如图 1 所示，我们的调查揭示了河南省的省级中间盒通过基于 HTTP Host 和 TLS 服务器名称指示 (SNI) 的过滤来阻止访问某些 HTTP 和 HTTPS 网站（第 4.1 节）。与监控和阻止进出国家流量的 GFW 不同，这种区域性防火墙仅审查离开该省的流量（第 4.2 节）。它在连接跟踪和解析逻辑（第 4.3 节）、注入行为和指纹（第 4.4 节）以及网络位置（第 4.5 节）方面也与 GFW 不同。
我们进行了一项纵向研究，以了解河南防火墙阻止的内容以及它与 GFW 阻止的内容有何不同（第 5 节）。在 2023 年 11 月至 2025 年 3 月期间（2024 年 3 月至 10 月之间有测量间断），我们每天测试 Tranco 排名前一百万的域名，并每周测试 CZDS 的 2.27 亿个域名。我们发现河南防火墙采用了比 GFW 更激进和不稳定的封锁政策。河南防火墙累计封锁了 420 万个域名，是 GFW 累计封锁列表规模的五倍多。
*。Mingshi Wu 和 Ali Zohaib 对这项工作做出了同等贡献。
== OCR 页面 1 结束 ==
== OCR 页面 2 开始 ==
TLS
区域防火墙
GFW
图 1：河南省已部署基于 TLS SNI 和 HTTP Host 的审查中间盒，用于检查和阻止离开该省的流量。
GFW 累积黑名单的规模。一个关键原因是它会封锁通用的二级域名（例如 *.com.au）。我们的测试还揭示了某些时期，它封锁的域名数量是 GFW 的十倍。
基于观察到的解析缺陷和注入行为，我们引入了绕过这种区域性审查的规避技术（第 6 节），这些技术已被各种流行的反审查工具实现。河南的区域性审查标志着中国首次正式记录的省份级防火墙自主运行案例之一。我们希望我们的研究能够向更广泛的审查研究社区发出警报，以识别、调查和对抗中国及其他地区区域性审查的出现。
- 背景和相关工作
2.1. 中国的防火长城 (GFW)
中国的防火长城 (GFW) 是一套部署在中国的不同审查机制和设备。GFW 利用分布在中国边境自治系统 (ASes) 的中间盒网络来检查和阻止互联网流量 [17]。GFW 不仅阻止访问特定的网站和服务，还试图识别和阻止绕过其审查的尝试。
网站审查。为了阻止访问特定的网站和服务，GFW 通常采用多种技术的组合，包括 DNS 注入 [1], [3]、HTTP Host 头部过滤 [8]、TLS SNI/ESNI 过滤 [2], [9], [10], [20] 和 IP 地址封锁 [2 §4]。
为了审查 DNS 流量，GFW 在路径上运行，注入伪造的 DNS 响应，其中包含错误的 IP 地址，以阻止访问特定域名 [3], [4], [5], [21], [22]。早在 2002 年的报告就记录到 GFW 在其伪造响应中使用单一错误 IP 地址 [23], [24]。随着时间的推移，这演变成了一个更复杂的系统，使用越来越多的假地址，并扩大了被封锁域名的列表 [3], [4], [22], [25]。研究人员在 GFW 的注入系统中发现了内存泄露漏洞 [5], [16], [26]。
为了审查 HTTP 和 TLS 流量，GFW 会有状态地检查连接中未加密的文本。一旦在 HTTP 请求的 Host 字段或 TLS ClientHello 的服务器名称指示 (SNI) 扩展中检测到被审查的域名，GFW 会向连接的两端注入 TCP RST 数据包以中断连接 [6], [7], [9], [27], [28]。图 2 显示了 GFW 对包含 TLS Client Hello 中被禁止域名的 SNI 的连接的操作。
GFW 通常双向操作，意味着进入和离开国家的流量都可能触发其审查 [4], [9], [29]。审查中间盒的双向操作使得研究人员能够从国家外部测量审查 [3], [30], [31]。
诸如 OONI [32]、Censored Planet [33] 和 ICLab [34] 等项目多年来一直在全球范围内测量审查。为了监控中国的网站审查，已经开发了几个大型项目，包括 GreatFire Analyzer [35]、Blocky [36]、GFWatch [3] 和 GFWeb [9]。虽然纵向和大规模研究在跟踪和理解 GFW 黑名单变化方面非常出色，但有时重新审视现有的审查机制仍然可以揭示审查者的新更新。例如，Bock 等人 [11] 发现在中国存在次要的 TLS 审查中间盒，这些中间盒一直未被检测到，直到深入分析揭示了它们的存在。
代理审查。仅仅阻止访问网站不足以阻止用户访问被审查的内容，因为用户可以使用规避工具绕过审查。因此，在中国，GFW 和互联网用户之间似乎展开了一场无休止的猫鼠游戏 [37]。例如，GFW 采用主动探测技术来识别和阻止规避工具，例如 Tor [12], [13], [38], [39], [40] 和 Shadowsocks [14] [15 §5]，这些工具已被成功防御 [41], [42], [43], [44]。GFW 还进行流量分析以识别和阻止完全加密的代理 [15]。
其他审查机制。中国的审查还有一些独特的组成部分，似乎与 GFW 针对网站和代理的审查分开。值得注意的是，在 2015 年，研究人员发现了中国的“大炮”(Great Cannon)，它将 Javascript 注入 HTTP 流量中，以劫持受害者浏览器参与针对特定主机的拒绝服务攻击 [30]。
2.2. 审查中的区域差异
在具有严格审查政策的国家，本地化或去中心化的审查机制很常见。在俄罗斯，数千家私营 ISP 各自实施自己的过滤机制，导致审查状况多样化 [45], [46], [47]。类似地，在印度，研究人员表明 ISP 在执行政府审查令方面存在显著差异，导致全国范围内的审查碎片化 [48]。
然而，先前的研究表明，中国的审查系统和政策在全国范围内基本上是统一和集中的。2011 年，Xu 等人 [17] 测量了
== OCR 页面 2 结束 ==
== OCR 页面 3 开始 ==
省级
防火墙
GFW
中国
美国
a) GFW
-SYN-
-SYN/ACK-
-ACK-
-PSH/ACK-
SNI/Host: youtube.com |
类型 I
RST x1
RST x1
类型 II ----
RST/ACK x3
-RST/ACK x3->
类型 III
RST/ACK x1
-*-RST/ACK x1-
b) 河南
防火墙
TCP 连接未建立 -
-PSH/ACK-
SNI/Host: 011.com
RST/ACK x1
10字节负载
图 2：河南防火墙和三种不同类型 GFW 的概述。可以通过在探测的 SNI 或 HTTP Host 字段中放入仅被各自审查机制封锁的域名来单独触发和研究每个审查机制。例如，截至 2024 年 4 月，011.com 仅被河南防火墙封锁，而 youtube.com 仅被 GFW 封锁。
中国审查设备的位置。他们发现中国的关键词审查中间盒主要位于网络边缘，并采用符合当时全国性封锁政策的规则。2012 年，Wright [18] 对中国的 DNS 审查进行了一项小规模研究，发现对查询的 DNS 响应在全国各地有所不同。然而，这项工作没有考虑 DNS 响应变化的其他可能原因（例如基于地理位置的负载均衡或 DNS 配置的变化）。2018 年，Bao 等人 [49] 测量了来自住宅和蜂窝 IP 地址的中国 DNS 注入差异。互联网范围和纵向测量揭示了中国对审查政策 [3], [4], [9], [15]、软件更新 [16 §4.5] [5 §VII] 和基础设施 [14 §3.4] [4 §5] 的统一和协调管理。
- 检测区域性审查
中国境外的反审查研究人员通常依赖本地用户的报告来了解中国新的审查动向和升级。这部分是由于研究人员难以在中国境内获得多样化的观测点，然后持续监控各种互联网服务和协议。令人鼓舞的是，在线讨论论坛，如 Net4People BBS [50]、NTC Party 论坛 [51]，以及流行的反审查工具（如 Xray [52]、V2Ray [53]、sing-box [54] 和 Hysteria [55]）的 GitHub issue 页面——使用户能够在遇到新的审查行为时立即报告，并允许研究人员迅速调查这些报告 [37]。
这种众包、协作的方法在识别和打击河南省的省级审查方面也很有效。具体来说，我们的研究始于一群河南用户报告无法访问某些网站 [19], [56], [57], [58], [59]。然后，我们在河南省获得了一台服务器，并确认了区域性防火墙的存在。特别是，如图 2 所示，我们发现河南区域性防火墙会针对某些服务器名称指示 (SNI) 和 HTTP Host 值阻止 TLS 和 HTTP 连接，但其操作方式与 GFW 不同。最显著的区别是，河南的区域性防火墙通过向客户端注入一个包含固定 10 字节负载的 TCP RST+ACK 数据包来阻止 TCP 连接。TCP RST 数据包的独特负载将河南防火墙与 GFW 注入的三种类型的数据包区分开来。
在河南省发现区域性审查引出了一个自然的问题：中国其他省份是否部署了相同或类似的区域性审查？下面，我们将通过在全国范围内的测量来探讨这个问题。
3.1. 实验
我们的目标是通过比较中国境内外各对主机之间被阻止的域名数量来量化中国 TLS 审查的区域差异。如表 1 第二行所总结，我们在中国的七个城市分别获得了两个观测点，包括上海、北京、重庆、广州（广东省）、南京（江苏省）、成都（四川省）和郑州（河南省）。我们还在中国境外的三个地点各设置了两个 VPS：西雅图（美国）、旧金山（美国）和新加坡。我们选择观测点是基于一系列伦理考虑，详见第 7 节。
对于中国境内或境外的每个地点的两个 VPS，我们使用一个作为客户端，另一个作为接收服务器。接收服务器配置为接受 1 到 65535 之间所有端口上的 TCP 握手。它们会确认发送给它们的 TCP 数据，但绝不会向客户端发送任何 TCP 负载。我们在客户端和接收服务器上都配置了 iptables 规则来丢弃任何传出的 RST 数据包。这样，任何一方收到的任何 RST 数据包都必定是由网络路径上的某些中间盒注入的。因此，我们可以通过检查 TCP 连接是否被重置来确认审查的存在。
然后，我们在 2024 年 7 月 10 日在每对客户端和接收服务器之间发送了具有不同 SNI 值的 TLS 流量。具体来说，我们使用了 Tranco 列表 [60] 5YZ7N² 中的前 10,000 个域名进行测试。为了减少因数据包丢失而导致的假阴性几率，我们在同一天重复测试了三次，并让操作系统控制数据包的重传。
局限性。理想情况下，我们希望使用多样化的观测点来识别潜在的区域审查
2. Tranco 列表 ID 5YZ7N，获取于 2023 年 8 月 15 日：Information on the Tranco list with ID 5YZ7N - Tranco
== OCR 页面 3 结束 ==
== OCR 页面 4 开始 ==
表 1：实验时间线和观测点。总共，我们使用了 14 个在中国 VPS 云（CVC, AS4837）位于郑州、河南省（HN）的 VPS，6 个在 Akamai Linode（LD, AS63949）位于旧金山（SF）、新加坡（SG）和西雅图（SE）的 VPS，12 个在腾讯云（TC, AS45090）位于北京（BJ）、上海（SH）、重庆（CQ）、广州、广东省（GZ）、成都、四川省（CD）、南京、江苏省（NJ）的 VPS，以及一个在美国大学的裸金属网络分流服务器（TAP）。
实验 时间段 持续时间 中国观测点 外部观测点 章节
识别 7/10/24 1天 12 (TC), 2 (CVC: HN) 4 (LD: SG,SE) §3
特征分析 10/2/23 - 11/12/24 13个月 2 (CVC: HN) 1 (LD: SF), 3 (TC: GZ,BJ,SH) §4
流量分析 10/31/24 1小时 1 (TAP: US) §4.3
定位 10/2/23 - 12/8/23 2个月 1 (CVC: HN), 1 (TC: GZ) 1 (LD: SF) §4.5
黑名单 11/5/23 - 3/5/24 & 10/07/24 – 3/31/25 9个月 14 (CVC: HN), 2 (TC: GZ) 2 (LD: SF) §5
在中国。然而，由于在中国获取 VPS 的困难，我们只能在有限的地点和 AS 中获得观测点。虽然使用住宅观测点可以让我们观察到中国更多网络位置的潜在中间盒，但这可能会给不知情的用户和住宅代理提供商带来潜在风险 [61]。因此，我们专注于使用中国的两大 VPS 提供商——中国 VPS 云和腾讯云，以避免对个人造成风险或迫害。我们利用了这两家 VPS 提供商提供的所有可用地点来最大化我们的覆盖范围。我们承认我们的结果仅限于测量 TLS 审查，这可能遗漏了其他协议的区域性审查。此外，由于配置错误，我们没有测试使用新加坡的客户端，可能遗漏了来自该方向的双向审查。
3.2. 结果
图 3 显示了不同地点之间被阻止的域名数量。我们首先观察到，从中国发往我们在新加坡和美国的接收服务器的连接几乎同样受到国家级防火长城 (GFW) 的影响，在 10,000 个域名中约有 479 个被阻止。最显著的阻止发生在河南省会郑州，那里的省级（河南）和国家级（GFW）审查机制共同导致了高数字。
离开河南的流量受到区域性防火墙的影响，无论接收服务器的位置如何，即使是到中国境内的其他地区。平均而言，河南防火墙阻止了 122 个域名。我们没有观察到河南内部的 TLS 连接有任何阻止；然而，由于我们的客户端和接收服务器都在同一个数据中心，我们只能谨慎地得出结论，河南防火墙不影响该数据中心内的内部流量。
当从河南省郑州连接到中国境外地点（新加坡和西雅图）时，总共有 594 个域名被阻止。这表明两个具有独立黑名单的防火墙同时运作，河南防火墙在流量到达 GFW 之前拦截流量，从而增加了被阻止域名的总数。然而，我们没有观察到
服务器
客户端
北京
上海
广东
四川
重庆
江苏
河南
新加坡
美国
北京 0 0 0 0 0 0 0 478 479
四川 0 0 0 0 0 0 0 479 479
重庆 0 0 0 0 0 0 0 479 479
广东 0 0 0 0 0 0 0 479 479
江苏 0 0 0 0 0 0 0 479 479
上海 0 0 0 0 0 0 0 479 479
河南 123 122 122 122 122 124 0 594 594
美国 411 411 411 411 411 440 411 0 0
图 3：该矩阵显示了各个地点之间主机对被阻止的域名数量。对于每个主机对，我们发送了 TLS ClientHello 消息，其 SNI 值来自 2023 年 8 月 15 日生成的 Tranco 列表 [60] 5YZ7N 中的前 10,000 个域名。结果表明：1) 河南省存在区域性审查，证据是从郑州、河南测试到中国其他地区接收服务器时，被阻止的域名数量不为零；2) 河南的审查不是双向的，因为从外部向河南发起 TLS 连接并未触发任何阻止；3) GFW 维护一个仅在从中国境内访问时才进行审查的黑名单，这从境内向外和境外向内测试时被阻止域名数量的差异中得到证明。
从中国其他客户端地点到河南或其他中国境内接收服务器区域的连接有任何阻止。这一发现表明，河南防火墙是中国第一个已知的区域性防火墙部署。
== OCR 页面 4 结束 ==
== OCR 页面 5 开始 ==
省内
河南
省外
河南
省内
中国
GFW
省外
中国
a) 省内出发
-SNI/Host:011.com-
----RST/ACK x1 →
b) 省外进入
-SNI/Host:011.com-
← 未触发 –
a) 省内出发
-SNI/Host:docker.com+
← RST/ACK x3 --X----RST/ACK x3----->
b) 省外进入
-SNI/Host:docker.com-
← 未触发 –
- 任何情况下TCP连接都未建立
(a) 河南防火墙
c) 省外进入
-SNI/Host:youtube.com
← RST/ACK x3 --X----RST/ACK x3 → - 所有情况下TCP连接都已建立
(b) GFW
图 4：(a) 河南防火墙不审查进入河南的入站 TLS 或 HTTP 流量，这与 GFW 采用的双向审查形成对比。(b) GFW 的 TLS 和 HTTP 审查机器检查进出中国的双向流量；然而，某些域名仅在从中国境内访问时才被审查。在此示例中，虽然一个 SNI 值为 docker.com 的 TLS ClientHello 在从中国境内发送时可以触发 GFW 的三个 TCP RST 数据包，但当从中国境外发送时，它不会触发任何阻止。
此外，如图 3 最后一行所示，从美国到中国不同地点的测试一致地识别出 GFW 阻止了相同的 411 个域名，只有一个例外：从美国到江苏省的测试检测到 440 个被阻止的域名。进一步分析表明，江苏在境外向内方向上额外阻止的 29 个域名是 GFW 在境内向外方向上阻止的 479 个域名的一部分。这一发现表明，这 29 个域名的额外审查可能并不反映特定于江苏的区域性审查。相反，它表明 GFW 被配置为在江苏境内双向阻止这些域名。
总的来说，这些结果特别值得注意，因为它们显示了远程测量触发区域性防火墙的不可行性，更重要的是，GFW 的非对称行为。具体来说，虽然从中国境内发起的连接平均有 479 个域名被阻止，但从中国境外发起的连接只有 411 个域名被阻止。这种差异表明 GFW 对源自中国境内的流量强制执行不同的黑名单。直到最近，人们普遍认为 GFW 是对称运行的，无论流量方向如何，都会触发并应用相同的黑名单。然而，最近的研究表明这种假设是不正确的 [9]，我们在此的发现与这一最新结果一致。
我们注意到 GFW 和河南防火墙都表现出不同程度的非对称干扰。如图 4(a) 所示，虽然离开河南的流量（境内向外）受到区域性防火墙的影响，但进入河南的入站流量（境外向内）根本不会触发区域性防火墙。这与 GFW 形成对比，后者虽然是双向的，但会根据查询的域名表现出非对称性。
图 4(b) 提供了一个清晰的例子。当一个 SNI 值为 docker.com 的 TLS ClientHello（在我们的案例中）从中国境内发送（境内向外）时，GFW 会通过三个 TCP RST 数据包触发阻止。然而，当同一个 TLS ClientHello 从中国境外发送（境外向内）时，GFW 不会触发任何阻止。另一方面，当发送一个 SNI 值为 youtube.com（在此示例中）的 TLS ClientHello 数据包时，无论数据包是从中国境内还是境外发送，GFW 都会在两种情况下触发阻止。这种行为表明存在一个明显的域名黑名单，这些域名仅在从中国境内访问时才被 GFW 审查。
在我们旨在检测任何区域性审查的实验中，我们无意中揭示了 GFW 操作机制的一个重要方面，而这一点直到最近才被记录下来 [9]。新观察到的 GFW 和区域性防火墙的非对称性凸显了进行境内向外测量以全面捕捉审查程度和细微差别的关键需求。仅仅依赖远程测量，正如许多其他研究中常见的那样，无法提供对此类审查事件的全面了解。
为了进一步证实 GFW 的非对称行为，我们提供了一个仅在从中国境内发送 TLS ClientHello 消息时才被阻止的域名列表，如表 2 所示。在我们的实验中，10,000 个域名中有 68 个在从中国境外测试时没有触发任何审查，但只有在从中国境内探测时才被阻止。这些域名包括流行的网站，如 google.com、nyt.com 和 docker.com。
== OCR 页面 5 结束 ==
== OCR 页面 6 开始 ==
表 2：仅在从中国境内发送 TLS ClientHello 消息时被 GFW 阻止的部分域名示例。这些域名在 2024 年 7 月 10 日从中国境外向境内发送时未触发审查。在我们测试的 10,000 个 Tranco 顶级域名中，有 68 个仅在境内向外被阻止，没有域名仅在境外向内被阻止。
binance.com godaddy.com note.com
cdninstagram.com google.com nyt.com
docker.com google.com.hk tiktokcdn.com
gmail.com linktr.ee torproject.org
该列表具体证明了 GFW 基于流量来源和查询域名选择性执行其黑名单。
- 描述审查设备特征
自 2023 年 10 月以来，我们进行了一系列实验来描述审查设备的特征，并了解防火长城 (GFW) 与河南区域性审查设备之间的差异。在本节中，我们回答了几个研究问题：区域性审查设备位于何处？哪些数据包可以触发河南 SNI 防火墙？河南防火墙监控哪些端口？TCP RST 注入是否有任何特定的指纹？河南防火墙是否会引起残留审查？
4.1. 方法论
我们开发了一种针对前面讨论的两种防火墙（即区域性和国家性）特定特征量身定制的方法论。为了精确评估每个防火墙的影响，我们的方法涉及单独隔离和分析这两个系统。这种基于我们初步观察设计的方法，是我们全面测量实验的基础。我们方法论的关键方面概述如下。
获取观测点。我们总共使用了 10 个位于郑州（河南）的观测点，通过中国 VPS 云（AS 4837）获取；两个位于广州、一个位于北京、一个位于上海的 VPS，通过腾讯云（AS 45090）获取；以及两个位于美国旧金山的 VPS，通过 Akamai 的 Linode（AS 63949）获取。位于广州、北京、上海和旧金山的 VPS 作为接收服务器，被编程为监听 1 到 65535 端口并接受 TCP 连接，但不向发送方回传任何其他数据。我们所有的机器都运行 Ubuntu 22.04，并使用 IP2Location [62] 数据库验证了它们宣称的位置。我们在表 1 中总结了我们实验的时间线和每个实验使用的观测点。
在 VPS 上丢弃传出的 RST。我们在客户端和接收服务器上都配置了 iptables 规则来丢弃所有传出的 RST 数据包。这种配置确保客户端收到的任何 RST 数据包都可以可靠地归因于中间盒注入。
触发基于 TLS SNI 的审查。我们通过发送包含潜在审查域名的 TLS ClientHello 的 SNI 字段来触发审查。由于接收服务器被配置为不响应任何数据包，并且在观察到 FIN 或 RST 数据包之前不会中断连接，我们预期收到的任何 RST 数据包确实是防火墙注入的数据包。如果收到包含该域名的 TLS ClientHello 的 RST 数据包，我们将该域名标记为被审查。
触发基于 HTTP Host 的审查。为了触发 HTTP 审查，我们发送了包含被禁止域名的 HTTP GET 请求，其 Host 头部如下：
GET / HTTP/1.1\r\nHost: example.com\r\n
虽然我们后来发现河南防火墙不需要完整的 TCP 握手来触发封锁，但在发送 HTTP 请求之前，我们仍然完成了 TCP 握手，使得我们针对河南防火墙和 GFW 的测试方法保持一致。如果收到包含该域名的 HTTP GET 请求的 RST 数据包，我们将该域名标记为被审查。
隔离河南防火墙。为了区分河南防火墙的响应和 GFW 的响应，我们识别了每个防火墙独有的几个指纹。先前的工作记录了 GFW 通过在观察到包含被禁止服务器名称指示字段的 TLS ClientHello 消息时向连接的两端注入最多三个 RST+ACK 来中断连接 [2], [63]。相比之下，河南防火墙仅向连接的客户端注入一个 RST+ACK 数据包。此外，河南防火墙的 RST+ACK 数据包包含一个负载，使其易于与 GFW 的响应区分。我们将在第 4.4 节对此进行扩展。
最后，我们从河南的观测点向位于广州、北京和上海的服务器发送探测，以确保我们的流量不会被路由到中国境外（在那里可能会遇到 GFW），但仍然受到河南区域性防火墙的影响。
局限性。我们在河南省的测量仅限于单一自治系统 (AS)，即中国联通 (AS 4837)，这是因为难以在中国获得可用于审查测量的多样化且符合伦理的观测点。因此，我们的实证发现仅限于这单一互联网服务提供商 (ISP)，限制了我们确认或描述河南其他 ISP 或 AS 的审查实践的能力。
虽然用户报告表明河南的 ISP 采用了区域特定的审查，但据报道审查实施方式有所不同 [64]。例如，Github 用户 5e2t 报告称，中国移动河南在其蜂窝网络上审查流量，并且能够重组间隔紧密的 TCP 数据包 [64]，这与我们在中国联通上观察到的行为（见第 4.3 节）不同。因此，我们的结果应被解释为仅反映中国联通河南的审查实施情况，而不一定代表所有 ISP 在全省范围内的实践。
== OCR 页面 6 结束 ==
== OCR 页面 7 开始 ==
4.2. 目标流量是什么
河南防火墙是否采样流量进行监控和审查？ 审查者已被观察到仅监控和审查一部分流量，这可能是为了减少其审查设备的计算负载 [15 §6.3]。然而，我们并未观察到河南防火墙有任何流量采样或概率性封锁行为。我们观察到河南防火墙始终如一地封锁其黑名单上的域名。我们发送了 1000 个连续的 ClientHello 消息，其中包含一个被禁止的域名，每个请求通过唯一的端口对进行，并有少量延迟。我们收到了我们建立的每个连接的 TCP RST 数据包，表明对于河南防火墙审查的域名，其触发率为 100%。
河南防火墙监控哪些端口？ 先前的工作表明，GFW TLS ESNI 审查中间盒监控所有端口，即 1-65535 [10]。为了测量河南防火墙，我们向位于中国广州的接收服务器的所有端口发送了包含已知被封锁 SNI 的 TLS ClientHello 消息。我们发现，与 GFW 类似，河南防火墙监控流向任何 TCP 端口号（范围在 1 到 65535 之间）的 TLS 流量。
河南防火墙是双向的吗？ 由于在被审查区域获取观测点的固有局限性，研究人员通常选择从外部进行测量，而不是从内部。特别是在中国，研究 GFW 的工作 [3], [4], [9] 使用了中国境外的观测点，因为 GFW 具有双向性。然而，如第 3 节所述，从中国境外发送探测并不会触发河南防火墙，因为它只审查离开河南的流量。如图 3 所示，我们通过在河南节点和中国其他地区节点之间发送具有 Tranco 列表 [60] 5YZ7N 中不同 SNI 值的 TLS ClientHello 消息来测试这一点。我们发现只有离开河南的流量被区域防火墙阻止。类似的不对称封锁行为在先前关于 GFW 的工作中也曾观察到 [9], [10]。
4.3. 河南防火墙如何解析连接
在本节中，我们研究河南防火墙和 GFW 的解析逻辑。我们进行实验以检查触发河南防火墙和 GFW 所需的 TCP 握手要求。我们还使用 DPYProxy [65] 来测试 TCP 和 TLS 重组能力，以及两个防火墙中是否存在残留审查。我们在表 3 中总结了我们的发现。
TCP 握手完整性要求。 中间盒设计者通常需要在解析逻辑的复杂性与流量分析操作的效率之间进行权衡。例如，由于互联网的非对称路由特性，以及河南防火墙和 GFW 并非总是客户端或服务器的直接邻居（如表 5 所示），中间盒可能只能观察到单向的流。
表 3：GFW 和河南防火墙的解析逻辑。河南防火墙似乎是无状态的，并且对典型的网络可变性不如 GFW 健壮。
GFW 河南防火墙
需要 SYN ✓ X
需要 SYN+ACK X X
TCP 重组 ✓ X
TLS 重组 X X
TCP 头部长度 任意 仅 20 字节
这种特性常常使得中间盒的设计者放弃要求完整的 TCP 三次握手来跟踪 TCP 连接并进行审查。在 2024 年 10 月 10 日，我们从河南的观测点测试了河南防火墙和 GFW 对 TCP 握手完整性的要求。我们发送了一个单独的 TCP 数据包，其负载是一个包含被禁止域名 011.com 作为 SNI 的 TLS ClientHello 消息，其前面是 1) 来自客户端的 SYN 数据包，或 2) 来自客户端的 SYN 数据包和来自服务器的 SYN+ACK 数据包，或 3) 完全没有数据包。
如表 3 所总结，虽然 GFW 需要观察到来自客户端的 SYN 数据包（但不需要服务器的 SYN+ACK 数据包）来触发审查 [9]，但河南防火墙不需要观察到任何 TCP 握手数据包即可被触发。
TCP 分割。 TCP 分割能够将较大的 TCP 负载分割成较小的部分。在规避审查的背景下，将 TLS ClientHello 消息分割成多个 TCP 段已被用来迷惑那些不重组数据包的无状态审查者。然而，我们确认 GFW 执行 TCP 重组，因此是有状态的。另一方面，我们发现河南防火墙不执行 TCP 重组，因此可以通过将 ClientHello 的 TCP 负载分割成多个 TCP 段，并将 SNI 分布在这些段之间来绕过它。我们通过从河南的观测点向广州的 VPS 发起一个包含被禁止 SNI 的 TLS 连接，并将 ClientHello 分割成两个段，第二个段包含被禁止的域名来进行测试。我们观察到，虽然完整的 ClientHello 消息被河南防火墙阻止，但如果第一个段中不包含完整的 SNI 扩展，则可以绕过河南防火墙。
TLS 分片。 虽然 TCP 分割长期以来被用于绕过无状态审查者，但 TLS 分片的使用直到最近才被 Niere 等人 [65] 分析并实现在他们的 DPYProxy 工具中。在一个 TLS 消息被封装到 TCP 段之前，它首先被封装在一个称为 TLS 记录的东西中。鉴于 TLS 消息的最大大小超过了 TLS 记录允许的最大大小，TLS 标准允许将 TLS 消息分割到多个 TLS 记录中。Niere 等人 [65] 发现 GFW 不执行 TLS 重组，因此可以通过
== OCR 页面 7 结束 ==
== OCR 页面 8 开始 ==
1.00
TCP 数据包
0.75
– TLS 数据包
0.50
0.25
0.00
0 10 20 30 40 50 60
TCP 头部长度（字节）
图 5：2024 年 10 月 31 日在大学网络上捕获的一小时内所有 TCP 和 TLS 数据包的 TCP 头部长度字段分布。总共，我们捕获了大约 231 亿个 TCP 数据包和 50 亿个 TLS 数据包。只有 22% 的 TCP 数据包头部长度为 20 字节，而只有 19% 的 TLS 数据包头部长度为 20 字节。此评估结果表明，河南防火墙可能仅能审查约 20% 的目标连接。
将 TLS ClientHello 消息分片到多个 TLS 记录中，其中 SNI 被分割到同一 TCP 负载内的多个 TLS 段。我们确认，截至 2024 年 4 月 4 日，河南防火墙和 GFW 都不执行 TLS 重组，因此可以通过 TLS ClientHello 分片绕过它们。
TCP 头部长度必须为 20 字节。 TCP 头部第 13 字节的前四位代表 TCP 数据偏移量，它以 32 位字为单位指定 TCP 头部的长度。当没有 TCP 选项时，TCP 数据偏移字段的最小值为 5 个字（20 字节），最大值为 15 个字（60 字节）。
我们发现河南防火墙要求 TCP 头部长度正好为 20 字节才能正确解析和阻止 TLS ClientHello 或 HTTP 请求消息。我们通过从河南的观测点向广州的接收服务器发送包含禁止信息（例如，带有禁止 SNI 011.com 的 TLS ClientHello 消息）的消息进行测试，测试于 2024 年 10 月 17 日进行，其 TCP 头部设置了不同的 TCP 选项。在改变 TCP 头部长度的同时，我们确保 TCP 选项始终是四字节的倍数，以符合 TCP 头部的 32 位字对齐要求。我们测试的 TCP 选项包括常见的 TCP 选项，如最大段大小 (MSS)、窗口缩放、时间戳、选择性确认允许 (SAckOk)、无操作 (NOP)、选项列表结束 (EOL)，以及不常用的自定义 TCP 选项。我们发现只要设置了任何 TCP 选项，河南防火墙就不会阻止连接。
解释这种奇怪行为的一个直观假设是，河南防火墙不解析 TCP 头部中的 TCP 头部长度字段，而是错误地假设 TCP 头部长度始终为 20 字节。这样，当 TCP 头部由于 TCP 选项而超过 20 字节时，它会将 TCP 选项视为 TCP 负载的一部分，从而无法识别完整的 TLS ClientHello 或 HTTP 请求消息。然而，我们证伪了这个假设，并确认河南防火墙确实解析了 TCP 头部长度字段。具体来说，我们发送了带有禁止 SNI 011.com 的 TLS ClientHello 消息，其 TCP 头部未设置任何 TCP 选项，确认该消息被河南防火墙阻止。如果河南防火墙不解析 TCP 头部的 TCP 头部长度字段，那么无论我们在 TCP 头部中放入什么 TCP 头部长度值，该消息都应该被阻止。我们将 TCP 头部的 4 位 TCP 头部长度字段更改为所有 24 个可能的值（从 0 到 15），并为每个 TCP 数据包重新计算了正确的 TCP 校验和，发现河南防火墙仅在其 TCP 头部长度值为 5 个字（20 字节）时才阻止连接。此实验表明，河南防火墙确实解析了 TCP 头部的 TCP 头部长度字段，但有一个条件，即只有当其 TCP 头部长度为 20 字节时才阻止连接。
虽然我们无法确定此条件背后的原因——可能是审查者的疏忽——但这引发了一个重要问题：有多少真实世界的流量因此条件而逃避了检测。我们在美国的大学网络上进行了一项测试。具体来说，我们使用 Retina [66] 在 2024 年 10 月 31 日下午 3:56:14 到 4:56:14（UTC-7）的一小时内捕获了校园网络上所有流量的 TCP 头部长度字段。总共，我们收集了 231 亿个 TCP 数据包和 50 亿个 TLS 数据包。如图 5 所示，只有 22% 的 TCP 数据包头部长度为 20 字节，只有 19% 的 TLS 数据包头部长度为 20 字节。这一结果表明，河南防火墙可能只能审查大约 20% 的目标连接。
4.4. 河南防火墙如何阻止流量
河南防火墙是否采用残留审查？ 残留审查是审查者使用的一种机制，即在两个主机之间检测到审查事件后，审查者会继续阻止这两个主机（源 IP、目标 IP、目标端口 - 三元组）之间的所有后续连接，持续一段时间，通常为 90 秒或 180 秒。这种现象已被多项先前研究 GFW 的工作记录 [6], [8], [67]。我们发现河南防火墙不执行任何残留审查。在河南防火墙注入任何重置数据包后，我们能够使用相同的三元组建立连接。
指纹化注入行为。 继续对 GFW 不断演变的注入行为进行指纹识别的工作 [68] [69] [65 §3.1] [70 §7.1.6] [7 §2.1]，我们对 GFW 和河南防火墙注入的 TCP RST 数据包进行了指纹识别。使用第 4.5 节收集的 RST 数据包，我们分析了它们的数据包特征，如 IP ID、IP TTL、TCP 标志、TCP 负载和负载长度。
== OCR 页面 8 结束 ==
== OCR 页面 9 开始 ==
表 4：河南防火墙与三种类型 GFW TCP RST 注入器的注入行为和数据包指纹比较。所有注入均由基于 TLS SNI 的审查触发。显示的 IP TTL 是观察到的值；它们的初始值应该更高。‘C’ 和 ‘S’ 指的是客户端和服务器。
GFW (I) GFW (II) GFW (III) 河南防火墙
观察到的 IP TTL 55-118 39-238 248 58
IP ID 0000 00A3-FE5F 9916-9933 0001
IP 标志 (DF) 0 1 0 0
TCP 负载长度 0 字节 0 字节 0 字节 10 字节
TCP 负载 01 02 03 04 05 06 07 08 09 00
TCP 标志 RST RST+ACK RST+ACK RST+ACK
数据包计数 x1 x3 x1 x1
目标主机 C&S C&S C&S C
残留持续时间 180 秒 180 秒 180 秒
表 4 比较了河南防火墙与来自 GFW 的三种类型（I、II、III）的重置数据包注入行为。虽然 GFW 的注入机制同时针对客户端（C）和服务器（S），但河南防火墙只向客户端注入重置数据包。
检查防火墙 RST 数据包的 IP 和 TCP 标志，我们观察到河南防火墙发送一个带有未设置 IP DF（不分片）标志的 RST+ACK 数据包。在 GFW 注入器中，类型 I 发送一个不带 ACK 且 IP DF 标志未设置的 RST 数据包，类型 II 发送三个重复且相同的 RST+ACK 数据包，IP DF 标志设置，类型 III 发送一个 RST+ACK 数据包，IP DF 标志未设置。
三种 GFW 注入器发送的 TCP RST 数据包观察到的 IP TTL 值范围不同：类型 I 为 55-118，类型 II 为 39-238，类型 III 为固定值 248。我们观察到河南防火墙发送的 RST+ACK 数据包具有固定的 IP TTL 值 58。我们注意到这些值是客户端观察到的 IP TTL 值；审查设备设置的初始 TTL 值会更高，随后会被从审查设备到客户端的网络跳数减少。
关于 IP ID 值，我们观察到类型 I GFW 注入一个具有固定 IP ID 0x0000 的 RST 数据包，类型 II GFW 注入三个 RST+ACK 数据包，其 IP ID 值范围从 0x00A3 到 0xFE5F（163–65119），类型 III GFW 注入 RST+ACK 数据包，其 IP ID 值范围从 0x9916 到 0x9933（39190–39219）。而河南防火墙的 TCP RST 数据包具有固定的 IP ID 值 0x0001。
河南防火墙 RST 数据包最独特的指纹是其 10 字节 TCP 负载模式 01020304050607080900，这一特征在任何 GFW 注入器中都未发现。虽然 RFC 9293 指出“TCP 实现应允许接收到的 RST 段包含数据 (SHLD-2)” [71 §3.5.3]，但在现实世界中看到带有负载的 RST 数据包仍然非常罕见。在第 6 节中，我们介绍了一种利用这一独特指纹绕过河南防火墙的规避技术。
4.5. 审查设备部署在何处
为了找出河南区域性防火墙设备在网络中的位置，我们使用了一种改进的方法来测量审查设备距离我们河南客户端的网络时间和 TTL 跳数距离。
首先，我们从位于河南郑州的观测点向位于广州和旧金山的接收服务器独立发送 ClientHello 数据包，并测量发送 ClientHello 和接收到任何连接的 RST 之间的时间差。我们利用 Tranco 列表中的前一百万个域名，每天进行四次实验，并记录收到的任何 RST 数据包。
100%
80%
60%
40%
GFW
河南防火墙
20%
0%
0 10 20 30 40
时间差：ClientHello 发送到 RST 接收到 (ms)
图 6：发送包含被禁止域名的 TLS ClientHello 数据包与接收到审查设备发出的第一个伪造 TCP RST 数据包之间的时间差的累积分布。
图 6 显示了发送 ClientHello 消息和接收到河南审查设备及 GFW 发出的第一个 TCP RST 数据包之间的时间差的累积分布。该分析基于 2023 年 10 月 2 日至 12 月 8 日期间从河南收到的 36,480 个 RST 数据包和从 GFW 收集的 16,649 个 RST 数据包。虽然 GFW 对于一个被阻止的连接可以注入超过三个 RST 数据包，但我们只考虑接收到的第一个 RST 数据包，因为它是启动连接中断的数据包。该图清楚地显示了延迟的差异：时间差表明河南审查设备位于更靠近客户端的位置，而 GFW 则位于国家网关。具体来说，GFW 的时间差范围从 11.52 毫秒到 445.38 毫秒（平均值为 17.98 毫秒），而河南设备的时间差范围从 2.30 毫秒到 30.49 毫秒（平均值为 2.82 毫秒）。这一证据有力地表明，河南的区域性审查是独立部署的，并且更靠近我们的观测点，意味着这些审查设备位于河南省内。
其次，为了识别审查发生的确切网络跳数，我们使用了一种基于 traceroute 的 TTL 限制探测方法。具体来说，我们发送包含已知被审查域名的 TLS ClientHello 数据包，逐渐增加
== OCR 页面 9 结束 ==
== OCR 页面 10 开始 ==
探测包的 IP TTL 值，直到观察到注入的 RST 数据包。触发 RST 的探测包的 TTL 反映了到审查设备的跳数。这种方法类似于先前工作如 CenTrace [72] 中使用的方法。
表 5：我们 TTL 限制探测实验的结果，显示河南中间盒比 GFW 距离我们的客户端近两跳。我们从河南郑州向美国旧金山的接收服务器发送 TLS ClientHello 探测，触发了位于不同跳数的两个不同中间盒。
跳数距离 ASN ISP
河南 5 4837 中国联通河南 省网
GFW 7 4837 骨干网 - 中国联通
表 5 显示了我们在郑州进行的测量结果，目标是美国的接收服务器。我们使用 011.com 触发区域性审查（河南），使用 youtube.com 触发国家级审查（GFW）。我们的发现表明，河南中间盒位于中国联通省网内的第 5 跳，而 GFW 则出现在更深的国家骨干网第 7 跳。这些结果证实了两个审查实体都作为路径上的中间盒运行，而河南设备的位置更靠近客户端。
- 理解黑名单
我们监控并分析了河南防火墙和 GFW 随时间推移所阻止的网站。我们还推断了其采用的底层封锁规则。
5.1. 分析被封锁的域名
实验设置。由于在河南获取高带宽机器的挑战，我们将测量分为两部分。首先，我们每天对 Tranco 列表 5YZ7N 中的前一百万个网站进行测试。其次，每周进行一次测试，我们测试来自超过 1000 个顶级域名（TLD）区域文件的 2.27 亿个域名，这些文件来自互联网名称与数字地址分配机构（ICANN）的集中区域数据服务（CZDS）[73]。
对于 Tranco 前一百万域名的每日测试，我们通过向我们控制的中国服务器发送相应的请求来测试 TLS SNI 和 HTTP Host 两种封锁方式。对于每个域名，针对 TLS SNI 审查，我们每天发送四个请求；针对 HTTP Host 审查，我们每天发送两个请求。对于某一天，如果某个域名针对该协议的任何请求收到了 TCP RST 响应，我们就将该域名标记为当天被该协议封锁。
由于带宽限制，对于每周测试的 2.27 亿个域名，我们每周向我们的服务器发送一个 TLS 请求，如果请求收到 TCP RST，则将该域名标记为被封锁。
被封锁域名数量
80000
GFW
河南防火墙
60000
40000
20000
0
Dec 09 Jan 28 Nov 23 Jan 12 Mar 03
2023 2024 2024 2025 2025
图 7：河南防火墙和 GFW 随时间推移封锁的域名数量。我们使用 Tranco 顶级百万域名列表 ID 5YZ7N 进行测试，时间为 2023 年 11 月 5 日至 2025 年 3 月 31 日，其中 2024 年 3 月 5 日至 10 月 7 日之间存在测量间隙。
实验时间线。表 1 总结了具体的实验时间线和观测点使用情况。特别地，我们在 2024 年 3 月 5 日至 10 月 7 日之间未能进行纵向实验。此外，也存在一些较小的数据缺口，如图 7 所示，这是由于我们在广州的 VPS 出现意外中断。由于我们使用相同的机器来测量河南防火墙和 GFW，广州接收服务器的中断影响了我们对两个防火墙的测量。因此，我们从分析中移除了这些小的测量缺口，总计约 25 天。
河南防火墙对 HTTP Host 和 TLS SNI 审查使用相同的黑名单。先前的工作表明，GFW 维护不同的基于域名的黑名单来审查不同的协议 [2 §4.1] [9 §5.2]。相比之下，我们发现河南防火墙对 HTTP Host 和 TLS SNI 两种审查都使用相同的黑名单。具体来说，我们比较了在同一天（2024 年 11 月 14 日）被河南的 HTTP Host 审查和 TLS SNI 审查封锁的域名列表。两种协议封锁的域名数量相似：HTTP Host 审查封锁了 24,795 个域名，TLS SNI 审查封锁了 24,974 个域名。这两个列表之间微小的 1% 差异可以通过测量噪声来解释：我们对有差异的域名重复进行了两次检测以减少假阴性，发现列表之间的差异消失了。
比较黑名单大小随时间的变化。我们监控了河南防火墙和 GFW 黑名单随时间的变化。图 7 显示了河南防火墙和 GFW 封锁的域名总数。直到 2025 年 3 月 4 日，河南防火墙的黑名单一直比 GFW 的黑名单大得多。
河南防火墙频繁添加和删除通用的二级域名封锁规则（例如 *.com.au, *.net.br, *.gov.co），导致被封锁域名的数量发生剧烈变化。例如，图 7 显示了一个大的
== OCR 页面 10 结束 ==
== OCR 页面 11 开始 ==
表 6：三个月内 GFW 和河南防火墙审查最多的十个 TLD。河南防火墙比 GFW 封锁了更多的国家代码顶级域名 (ccTLD)。
GFW 河南
TLD 黑名单 % TLD 黑名单 %
.com 45.8% .com 37.4%
.org 6.1% .au 11.4%
.net 5.6% .za 4.6%
.jp 2.4% .net 4.5%
.cc 2.1% .uk 4.1%
.de 1.7% .org 4.0%
.xyz 1.7% .in 2.9%
.in 1.7% .jp 2.4%
.tw 1.5% .tw 1.1%
.io 1.3% .de 1.0%
2023 年 11 月 10 日至 12 月 8 日期间，河南防火墙封锁的域名数量持续下降。这一下降主要是由于至少 112 条通用二级域名封锁规则被移除。特别是，封锁规则 *.com.au 的移除本身就导致了 2023 年 11 月 22 日超过五千个域名的解封。
我们观察到河南防火墙使用的黑名单也针对其他国家的州或市政府相关网站。例如，美国的大多数州政府网站，如 texas.gov、seattle.gov、alabama.gov、nc.gov 都在河南被封锁，但未被 GFW 封锁。与 GFW 黑名单中看到的 83 个 .gov 域名相比，我们发现河南防火墙封锁了 1002 个 .gov 域名，显示出其倾向于封锁任何展示来自世界各地的治理数据或新闻的内容。事实上，我们注意到河南防火墙倾向于比 GFW 更多地针对国家代码顶级域名 (ccTLD) 进行封锁，如表 6 所示。其中一些封锁是广泛的：2024 年，河南在 1 月 19 日和 2 月 1-2 日封锁了我们测试的所有 5,334 个 *.com.au 域名，在 2 月 15 日至 3 月 4 日封锁了所有 2,075 个 *.co.za 域名，在 2 月 8 日至 3 月 4 日封锁了所有 1,547 个 *.org.uk 域名。这些可能是过度封锁的实例，即防火墙包含了过于宽泛的规则。我们不清楚为什么河南防火墙会反复封锁和解封这些国家代码二级域名。
河南防火墙的黑名单比 GFW 的更不稳定。如图 8 所示，河南防火墙的封锁策略比 GFW 的黑名单更不稳定。虽然 75% 的被封锁域名被河南防火墙审查的时间少于 51 天，但 GFW 曾经审查过的域名中有超过 50% 在整个测量期间（256 天）都被封锁。GFW 封锁的域名审查持续时间更长（平均：173.8 天；中位数：256 天），而河南防火墙封锁的域名审查持续时间较短（平均：35.7 天；中位数：21 天）。
如上所述，河南防火墙这种不稳定的封锁策略也主要归因于频繁的
1.00
GFW
0.75
河南防火墙
0.50
0.25
0.00
0 50 100 150 200 250
被审查天数
图 8：GFW 和河南防火墙在 2023 年 11 月 5 日至 2025 年 3 月 31 日期间（其中 2024 年 3 月 5 日至 10 月 7 日有测量间隙）封锁的所有（曾经）域名的审查持续时间。与 GFW 相比，河南防火墙的封锁策略更不稳定，有更大比例的域名被封锁的时间较短。
网站数量
150k
GFW 曾审查
河南曾审查
100k
河南审查 < 21 天
河南审查 < 51 天
50k
0
2 4 6 8
网站排名 ×10⁵
图 9：GFW 和河南防火墙在 Tranco 前一百万列表 5YZ7N 中封锁的域名的累积分布。数据收集于 2023 年 11 月 5 日至 2025 年 3 月 31 日，其中 2024 年 3 月 5 日至 10 月 7 日有测量间隙。
添加和移除通用二级域名封锁规则。例如，图 7 显示了 2024 年 1 月 11 日至 12 日以及 2 月 1 日至 3 日期间，河南防火墙封锁的域名数量出现了两次峰值。这主要是由于封锁规则 *.com.au 的添加和移除。值得注意的是，即使在移除 *.com.au 规则时，例如在 2024 年 1 月 12 日和 2 月 3 日，河南防火墙仍然分别封锁了 44 个和 26 个以 .com.au 结尾的域名。这一观察表明封锁规则可以比二级域名更细粒度。
两个防火墙是否针对相似的网站？ 图 9 显示了在我们九个月的测量期间，GFW 和河南区域审查设备在 Tranco 前一百万域名中封锁的域名的累积分布。
== OCR 页面 11 结束 ==
== OCR 页面 12 开始 ==
对于 GFW，如果在我们的测量期间至少被阻止过一次，我们就将其归类为被阻止的域名。由于河南防火墙黑名单的不稳定性，我们将域名分为三类：曾经被阻止的域名、被阻止时间少于 21 天的域名以及被阻止时间少于 51 天的域名。我们根据观察到的两个防火墙的平均阻止持续时间（如图 8 所示）选择了这些阈值。
在我们的测量期间，我们累计观察到 GFW 审查了 25,441 个域名，而河南防火墙至少阻止过 175,925 个域名。在被河南防火墙审查的域名中，我们的分析确定了 104,100 个域名的阻止期少于 21 天，而 163,083 个域名的阻止持续时间短于 51 天。
观察域名的累积分布和排名，我们发现最受欢迎的域名更有可能同时被 GFW 和河南防火墙阻止。河南防火墙在阻止域名的流行度方面更均匀，而 GFW 的黑名单则表现出更异构的分布。虽然 GFW 防火墙针对更受欢迎的网站，如图所示，河南防火墙更均匀地针对网站。然而，两个黑名单的大小形成了鲜明的对比。
两个黑名单之间的重叠。为了解两个黑名单的大小和重叠情况，我们进行了一项长期实验，在 2023 年 12 月 26 日至 2025 年 3 月 31 日期间，每周测试 2.27 亿个域名。图 10 显示了 GFW 和河南防火墙的累积黑名单。在实验期间，河南防火墙阻止了 4,196,532 个域名——是 GFW 曾经阻止的 741,542 个域名的五倍多。有 479,247 个域名被两个防火墙都阻止了。两个黑名单之间的 Jaccard 指数约为 0.0885，表明它们的相似度低于 9%，因此在覆盖范围上很大程度上是独立的但又互补的。
对被阻止的域名进行分类。我们使用 whoisxmlapi.com [74] 网站分类服务对 2023 年 11 月 21 日至 2024 年 1 月 15 日期间获取的每个防火墙的黑名单进行分类。我们承认并非所有域名都能被分类，因为有些域名不活跃或没有托管内容。表 7 显示了每个防火墙审查域名的前十个类别。
这里我们注意到的一个有趣点是，河南防火墙比 GFW 更多地针对商业、经济、计算机和互联网信息域名。在河南防火墙黑名单上出现的总域名中，超过 35% 来自这两个类别。为了找出关注这些类别的原因，我们推测河南省一直是许多金融争议的中心，其中最突出的是 2022 年涉及当地贷款机构的金融丑闻引发的大规模抗议 [75]。鉴于针对国家控制的金融机构的金融丑闻，国家很可能希望限制访问与该地区经济相关的信息。另一方面，这也可能是审查国家商业和经济政策批评者的国家政策的一部分。
262,295
479,247
GFW
3,717,285
河南
图 10：GFW 和河南防火墙曾经阻止的累积域名的韦恩图。我们在 2023 年 12 月 26 日至 2025 年 3 月 31 日期间（其中 2024 年 3 月 5 日至 10 月 7 日有测量间隙）对 2.27 亿个域名进行了每周测试。河南黑名单的大小是 GFW 黑名单的五倍多。
表 7：河南防火墙和 GFW 在 Tranco 前一百万域名中阻止域名的顶级类别。未进入每个防火墙前十名的类别标记为“-”。
类别 河南 GFW
数量 比例 (%) 数量 比例 (%)
商业 4861 26.9 1183 15.3
计算机 2517 13.9 642 8.3
色情 2394 13.2 2207 28.6
赌博 1276 7.1 - -
社会 1265 7.0 459 5.9
购物 1261 7.0 288 3.7
旅游 1230 6.8 - -
娱乐 1134 6.3 548 7.1
教育 1104 6.1 - -
未分类 1057 5.8 395 5.1
新闻 - - 1378 17.9
个人网站 - - 313 4.1
流媒体 - - 305 4.0
另一方面，GFW 则更多地针对新闻和媒体，以及成人内容域名。这与长期以来对 GFW 的理解一致，即它旨在限制更多的新闻、道德敏感和政治敏感内容。
5.2. 识别封锁规则
另一种观察每个防火墙如何配置过滤规则的方法是推断可能用于黑名单匹配的正则表达式。正如 Anonymous 等人 [22 §6] 和 Hoang 等人 [3 §4.1] 在他们对 GFW 的 DNS 审查研究中指出的那样，GFW 使用可能针对二级域名、顶级域名和/或子域名的规则来阻止域名。他们开发了一种方法来涵盖 GFW 应用的阻止规则。我们使用了类似的方法
== OCR 页面 12 结束 ==
== OCR 页面 13 开始 ==
表 8：用于测试河南防火墙和 GFW 封锁规则的排列组合。占位符 {str} 代表单独或与其他组合时不会触发审查的字符串。在这项工作中，我们使用了字符串 ZZZZ。
测试 模式 测试 模式
测试 0 {str}domain{str} 测试 5 {str}.domain
测试 1 domain 测试 6 {str}.domain.{str}
测试 2 domain.{str} 测试 7 {str}.domain{str}
测试 3 domain{str} 测试 8 {str}domain.{str}
测试 4 {str}.domain
表 9：我们推断出 GFW 和河南防火墙使用的封锁规则的正则表达式等价物。总共，GFW 和河南防火墙分别使用了 24 个和 5 个独特的正则表达式模式。该表仅显示了在 GFW 中出现次数超过十次的正则表达式模式。
推断的正则表达式 命中的测试 规则计数（比例）
GFW 河南
^(..)?keyword$ 1&4 163,355 85% 248,770 64%
^keyword$ 1 17,764 9.3% 3 0.0%
^(..)?keyword 1-4&6&7 7,272 3.8%
keyword$ 1&4&5 2,483 1.3% 139,575 36%
keyword 0-8 647 0.3%
.keyword$ 4 429 0.2% 4 0.0%
^keyword 1&2&3 36 0.0% -
基于表 8 中列出的排列组合来推断河南防火墙和 GFW 的封锁规则。我们注意到，我们推断的正则表达式可能无法完全反映审查者使用的规则，因为我们的排列组合可能会错过基于二级域名或更复杂正则表达式（例如我们观察到河南防火墙封锁的 .gov）的规则。尽管如此，我们推断的规则使我们能够识别河南防火墙与 GFW 相比在黑名单结构上的差异。
如表 8 所示，我们为在我们日常测量实验（第 5 节）中识别出的每个被审查域名生成了九种排列组合，方法是在域名前面和/或后面附加一个固定的字符串。这种方法曾被 Anonymous 等人 [22 §6] 在 2014 年和 Hoang 等人 [3 §4.1] 在 2021 年使用过。我们选择模式字符串 ZZZZ 来构建本工作中的每个排列组合。然后，我们独立地将包含每个排列组合的 SNI 的 ClientHellos 发送到我们的接收服务器，并记录每次测试的结果。这个实验在我们的测量期间每天进行四次。
如表 9 所示，河南防火墙和 GFW 使用的最流行的封锁正则表达式模式是 ^(..)?keyword$。这种模式旨在用于封锁一个域名及其子域名。GFW 使用的第二种最流行的封锁正则表达式模式是 ^keyword$，它仅用于封锁域名本身，而不封锁其子域名。GFW 使用的第三种最流行的封锁正则表达式模式是 ^(..)?keyword，这很可能是在正则表达式模式中未包含末尾锚点的错误。有趣的是，与 GFW 有时使用没有末尾锚点的正则表达式模式不同，河南防火墙在其正则表达式模式中始终包含末尾锚点。这个结果可能是因为有一个更仔细和一致维护的黑名单，或者也许是审查实施本身强制使用末尾锚定的正则表达式模式以防止人为错误。
- 规避策略
基于我们在第 4.3 节中识别出的解析逻辑缺陷，以及我们在第 4.4 节中观察到的注入行为和指纹，我们引入了简单但有效的策略来绕过河南防火墙。所有策略都只需要在客户端进行更改，无需服务器端的配合，使其易于部署和采用。这些策略已在各种流行的规避工具中实现，包括但不限于 Xray [76]、GoodbyeDPI [77] 和 Shadowrocket [78]。
启用任何 TCP 选项字段。如第 4.3 节所述，河南防火墙只能解析和阻止 TCP 头部为 20 字节的 TCP 数据包。在操作系统上启用任何 TCP 选项将导致 TCP 头部长于 20 字节。虽然这种规避解决方案依赖于河南防火墙不寻常的实现，但它仍然是用户或规避工具可以轻松用来逃避审查的一个特性。例如，启用 TCP 时间戳（在某些 Windows 版本中默认禁用）将阻止河南防火墙封锁连接 [56], [59]。
丢弃具有特定负载的 TCP RST 数据包。如第 4.4 节所示，河南防火墙注入一个带有不寻常的 10 字节负载 01020304050607080900 的 TCP RST 数据包。其独特性允许客户端仅丢弃由河南防火墙注入的 RST 数据包，同时保留服务器发送的 RST 数据包。通常，仅丢弃发送给客户端的 TCP RST 数据包不足以规避 GFW 的 TCP RST 审查，因为 GFW 也会向服务器注入 RST 数据包。然而，如第 4.4 节所述，河南防火墙仅向客户端注入 RST 数据包，因此丢弃发送给客户端的 RST 数据包足以规避审查。这种规避策略可以通过 iptables 规则轻松应用，类似于 Clayton 等人 [6 §5] 引入的规则。
将 TLS ClientHello 分段或分片到多个数据包中。如第 4.3 节所述，河南防火墙不执行 TCP 重组，并且河南防火墙和 GFW 都不执行 TLS 重组 [65]。因此，客户端可以将 TCP 数据包分段或将 TLS ClientHello 消息分片到多个 TLS 记录中以规避河南防火墙 [65]。只要携带 ClientHello 消息开头部分的 TCP 数据包不包含完整的 SNI 扩展，就可以绕过河南防火墙。执行这种分片可能需要像 uTLS [79] 这样的 TLS 库，它提供对发送消息的细粒度控制，或者像 DPYProxy [77] 这样专门构建的规避工具，可以对浏览器生成的记录进行分片。
== OCR 页面 13 结束 ==
== OCR 页面 14 开始 ==
浏览器。流行的规避工具如 Xray [76] 和 Shadowrocket [78] 也实现了这种 TCP 分段策略 [80]。
- 伦理
审查测量研究，特别是在威权体制下，需要仔细的伦理考量和在整个研究过程中对潜在风险的持续评估。在这项工作中，我们所有的审查测量都是从我们控制的机器上进行的，网络流量由我们的程序自动生成。这种方法是审查测量研究中的常见做法，旨在减轻对互联网上其他主机的过载风险，并避免给用户带来任何风险 [3], [4], [9], [14], [15]。在分析大学网络分流器上的真实世界流量时，我们只收集了数据包的 TCP 头部长度字段，没有捕获任何可识别个人身份或敏感信息。由于 IRB 批准因此不适用于这项研究（因为它不涉及人类受试者），我们遵循了门洛报告 [81] 中概述的伦理准则。我们的研究团队还咨询了对中国审查及其法律问题有深入了解的专家。下面，我们讨论了我们识别出的潜在风险以及我们为减轻这些风险所采取的措施 [81 §C.3.2]。
流量分析。为了评估河南防火墙的有效性，我们在大学网络分流器上测量了所有 TCP 数据包的 TCP 头部长度字段。使用此网络分流器得到了大学隐私和安全办公室的批准。我们还与具有管理类似项目经验的校园网络和安全团队密切合作。这种批准和合作确保我们遵循标准安全程序，遵守网络使用政策，尊重用户隐私，并最小化网络的攻击面。此外，我们将分流器设计为只接收流量副本，确保在系统故障时不会影响网络用户。
我们设计了实验以避免收集任何潜在敏感信息，例如可能与个人关联的 IP 地址。具体来说，我们仅以聚合方式收集所有 TCP 头部中的 4 位数据偏移字段。我们从未检查或记录任何原始流量数据。我们通过将网络分流器的访问权限限制在我们团队的一个有限、授权的子集来实践最小权限原则。
观测点。在被审查区域内获取观测点变得越来越具有挑战性。然而，我们旨在回答的两个关键研究问题需要在中国境内有广泛的观测点覆盖：1) 河南防火墙是否也部署在中国的其他省份？2) 其他省份是否也部署了它们的区域审查机器？我们在寻找尽可能多样化的观测点与潜在风险之间寻求了额外的谨慎平衡 [81 §C.3.2]。例如，虽然使用住宅观测点可以让我们观察到中国更多网络位置的审查情况，但由于对不知情用户的潜在风险，我们决定不使用它们 [61]。
我们还探讨了从省外或中国境外远程测量河南防火墙的可能性，这将进一步降低从区域内发起连接的风险；然而，正如第 4.2 节介绍的那样，河南防火墙无法以这种方式触发。
因此，我们遵循先前工作 [14], [15] 中概述的理由和常见做法，策略性地选择了由大型商业云提供商提供的观测点，以减轻个人的潜在法律风险。我们使用我们一位既非中国公民也非中国居民的研究人员的准确身份和联系信息注册了我们的 VPS 账户。在我们的研究过程中，我们没有收到来自提供商的任何投诉。为了避免审查者封锁其他云用户资源的可能性，我们为每台机器分配了专用的 IP 地址。
探测速率和设计。为了避免给我们的观测点和探测经过的网络路径带来过重负担，我们限制了流向我们接收服务器的传输速度。对于第 3 节和第 4 节中的实验，我们将探测速率限制为每秒不超过一个连接；对于第 5 节中的实验，我们对每个客户端设置了硬性限制，即发送不超过 1 Mbps 的流量。虽然我们的探测被审查者记录的风险和潜在危害很小，但我们也设计了具有合理可否认性的实验。也就是说，由于我们的接收服务器从未回复任何 ServerHello 消息或 HTTP 响应，并且从未建立完整的 TLS 或 HTTP 连接，我们的测量行为不像用户访问被审查的网站。
- 结论
在本文中，我们揭露并记录了中国互联网审查策略中一个令人警惕的迹象：我们对中国七个不同城市和省份的测量揭示了河南省存在一个新的区域性防火墙。这个河南防火墙对离开该省的流量进行基于 HTTP Host 和 TLS SNI 的审查。与 GFW 相比，它表现出独特的特征，包括独特的数据包注入行为和指纹、不同的跟踪、解析和阻止连接的逻辑、一个曾经大十倍且更动态的黑名单，以及更靠近客户端的网络位置。这种本地化审查表明中国正在偏离其中心化的审查机制，使得地方当局能够在各自区域内施加更大程度的控制。我们提出了简单但有效的规避技术来绕过这个在河南新兴的系统，这些技术已在各种流行的规避工具中实现。我们希望我们的研究能向更广泛的审查研究社区发出警报，使其意识到并进一步研究中国及其他地区新兴的区域性审查。
== OCR 页面 14 结束 ==
== OCR 页面 15 开始 ==
可用性
为了鼓励未来的研究并促进透明度和可复现性，我们公开了代码、匿名化数据以及持续更新的黑名单。为了提高可访问性，本文也以 HTML 格式提供了英文和中文版本。项目主页位于：https://gfw.report/publications/sp25/en。
致谢
我们感谢我们的指导人 (shepherd) 和其他匿名审稿人提出的宝贵意见和反馈。我们也感谢在中国勇敢的用户们，他们立即报告并积极研究封锁事件，包括但不限于 5e2t、Hsukqi、ThEWiZaRd0fBsoD、louiesun 和 lemon99ee。我们感谢 ValdikSS、radioactiveAHM、RPRX、Fangliding、GFW-knocker、sambali9、rrouzbeh、nekohasekai、znlihk、V2Ray 开发者、Hysteria 开发者、Shadowrocket 开发者以及许多其他开发者，感谢他们的有益讨论和/或将 TCP 分段和/或 TLS 分片功能集成到他们各自的规避工具中。我们还要感谢 Jackson Sippe、Jade Sheffey、Paul Flammarion、斯坦福实证安全研究组、斯坦福大学安全和网络团队以及许多其他希望保持匿名的朋友们提供的有益讨论和支持。我们感谢 Net4People BBS、NTC Party 论坛、Xray 社区、V2Ray 社区和 sing-box 社区为审查讨论提供了在线空间。我们感谢 David Fifield 在整个项目中提供的反馈、支持和指导。
这项工作部分得到了美国国家科学基金会 (NSF) 的资助，项目号为 CNS-2145783、CNS-2319080 和 CNS-2333965，得到了斯隆研究奖学金 (Sloan Research Fellowship) 以及美国国防高级研究计划局 (DARPA) 的青年教师奖 (Young Faculty Award) 项目的支持，项目号为 DARPA-RA-21-03-09-YFA9-FP-003。文中所表达的观点、意见和/或发现仅代表作者本人，不应被解释为代表国防部或美国政府的官方观点或政策。
参考文献
[1] H. Duan, N. Weaver, Z. Zhao, M. Hu, J. Liang, J. Jiang, K. Li, and V. Paxson, “Hold-On: Protecting against on-path DNS poisoning,” in Securing and Trusting Internet Names. National Physical Laboratory, 2012. [Online]. Available: https://www.icir.org/vern/papers/hold-on.satin12.pdf
[2] Z. Chai, A. Ghafari, and A. Houmansadr, “On the importance of encrypted-SNI (ESNI) to censorship circumvention,” in Free and Open Communications on the Internet. USENIX, 2019. [Online]. Available: https://www.usenix.org/system/files/foci19-paper_chai_update.pdf
[3] N. P. Hoang, A. A. Niaki, J. Dalek, J. Knockel, P. Lin, B. Marczak, M. Crete-Nishihata, P. Gill, and M. Polychronakis, “How great is the Great Firewall? Measuring China’s DNS censorship,” in USENIX Security Symposium. USENIX, 2021. [Online]. Available: https://www.usenix.org/system/files/sec21-hoang.pdf
[4] Anonymous, A. A. Niaki, N. P. Hoang, P. Gill, and A. Houmansadr, “Triplet censors: Demystifying Great Firewall’s DNS censorship behavior,” in Free and Open Communications on the Internet. USENIX, 2020. [Online]. Available: https://www.usenix.org/system/files/foci20-paper-anonymous_0.pdf
[5] S. Fan, J. Sippe, S. San, J. Sheffey, D. Fifield, A. Houmansadr, E. Wedwards, and E. Wustrow, “Wallbleed: A memory disclosure vulnerability in the Great Firewall of China,” in Network and Distributed System Security. The Internet Society, 2025. [Online]. Available: https://gfw.report/publications/ndss25/data/paper/wallbleed.pdf
[6] R. Clayton, S. J. Murdoch, and R. N. M. Watson, “Ignoring the Great Firewall of China,” in Privacy Enhancing Technologies. Springer, 2006, pp. 20-35. [Online]. Available: https://www.cl.cam.ac.uk/~rnc1/ignoring.pdf
[7] Z. Wang, Y. Cao, Z. Qian, C. Song, and S. V. Krishnamurthy, “Your state is not mine: A closer look at evading stateful Internet censorship,” in Internet Measurement Conference. ACM, 2017. [Online]. Available: https://www.cs.ucr.edu/~krish/imc17.pdf
[8] R. Rambert, Z. Weinberg, D. Barradas, and N. Christin, “Chinese wall or Swiss cheese? keyword filtering in the Great Firewall of China,” in WWW. ACM, 2021. [Online]. Available: https://censorbib.nymity.ch/pdf/Rambert2021a.pdf
[9] N. P. Hoang, J. Dalek, M. Crete-Nishihata, N. Christin, V. Yegneswaran, M. Polychronakis, and N. Feamster, “GFWeb: Measuring the Great Firewall’s Web censorship at scale,” in USENIX Security Symposium. USENIX, 2024. [Online]. Available: https://www.usenix.org/system/files/sec24fall-prepub-310-hoang.pdf
[10] K. Bock, iyouport, Anonymous, L.-H. Merino, D. Fifield, A. Houmansadr, and D. Levin. (2020, Aug.) Exposing and circumventing China’s censorship of ESNI. [Online]. Available: Exposing and Circumventing China's Censorship of ESNI · Issue #43 · net4people/bbs · GitHub
[11] K. Bock, G. Naval, K. Reese, and D. Levin, “Even censors have a backup: Examining China’s double HTTPS censorship middleboxes,” in Free and Open Communications on the Internet. ACM, 2021. [Online]. Available: https://doi.org/10.1145/3473604.3474559
[12] R. Ensafi, D. Fifield, P. Winter, N. Feamster, N. Weaver, and V. Paxson, “Examining how the Great Firewall discovers hidden circumvention servers,” in Internet Measurement Conference. ACM, 2015. [Online]. Available: https://conferences2.sigcomm.org/imc/2015/papers/p445.pdf
[13] A. Dunna, C. O’Brien, and P. Gill, “Analyzing China’s blocking of unpublished Tor bridges,” in Free and Open Communications on the Internet. USENIX, 2018. [Online]. Available: https://www.usenix.org/system/files/conference/foci18/foci18-paper-dunna.pdf
[14] Alice, Bob, Carol, J. Beznazwy, and A. Houmansadr, “How China detects and blocks Shadowsocks,” in Internet Measurement Conference. ACM, 2020. [Online]. Available: https://censorbib.nymity.ch/pdf/Alice2020a.pdf
[15] M. Wu, J. Sippe, D. Sivakumar, J. Burg, P. Anderson, X. Wang, K. Bock, A. Houmansadr, D. Levin, and E. Wustrow, “How the Great Firewall of China detects and blocks fully encrypted traffic,” in USENIX Security Symposium. USENIX, 2023. [Online]. Available: https://www.usenix.org/system/files/sec23fall-prepub-234-wu-mingshi.pdf
[16] Sakamoto and E. Wedwards, “Bleeding wall: A hematologic examination on the Great Firewall,” in Free and Open Communications on the Internet, 2024. [Online]. Available: https://www.petsymposium.org/foci/2024/foci-2024-0002.pdf
[17] X. Xu, Z. M. Mao, and J. A. Halderman, “Internet censorship in China: Where does the filtering occur?” in Passive and Active Measurement Conference. Springer, 2011, pp. 133-142. [Online]. Available: https://web.eecs.umich.edu/~zmao/Papers/china-censorship-pam11.pdf
== OCR 页面 15 结束 ==
== OCR 页面 16 开始 ==
[18] J. Wright, “Regional variation in Chinese Internet filtering,” University of Oxford, Tech. Rep., 2012. [Online]. Available: https://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID2265775_code1448244.pdf?abstractid=2265775&mirid=3
[19] Anonymous, “Issue 2426 | XTLS/Xray-core,” 河南新上的SNI/HOST黑名单墙 · Issue #2426 · XTLS/Xray-core · GitHub, 2023, (Accessed on 02/06/2024).
[20] G. Report. (2022, Oct.) Large scale blocking of TLS-based censorship circumvention tools in China. [Online]. Available: Large scale blocking of TLS-based censorship circumvention tools in China · Issue #129 · net4people/bbs · GitHub
[21] O. Farnan, A. Darer, and J. Wright, “Poisoning the well - exploring the Great Firewall’s poisoned DNS responses,” in Workshop on Privacy in the Electronic Society. ACM, 2016. [Online]. Available: https://dl.acm.org/authorize?N25517
[22] Anonymous, “Towards a comprehensive picture of the Great Firewall’s DNS censorship,” in Free and Open Communications on the Internet. USENIX, 2014. [Online]. Available: https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.pdf
[23] B. Dong, “A report about national DNS spoofing in China on Sept. 28th,” Dynamic Internet Technology, Inc., Tech. Rep., Oct. 2002. [Online]. Available: A report about national DNS spoofing in China on Sept. 28th
[24] J. Zittrain and B. G. Edelman, “Internet filtering in China,” IEEE Internet Computing, vol. 7, no. 2, pp. 70-77, Mar. 2003. [Online]. Available: https://nrs.harvard.edu/urn-3:HUL.InstRepos:9696319
[25] G. Lowe, P. Winters, and M. L. Marcus, “The great DNS wall of China,” New York University, Tech. Rep., 2007. [Online]. Available: https://censorbib.nymity.ch/pdf/Lowe2007a.pdf
[26] Anonymous. (2020, Mar.) GFW archaeology: gfw-looking-glass.sh. [Online]. Available: GFW Archaeology: gfw-looking-glass.sh · Issue #25 · net4people/bbs · GitHub
[27] C. Tang, “In-depth analysis of the Great Firewall of China,” http://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf, 2016.
[28] K. Bock, A. Alaraj, Y. Fax, K. Hurley, E. Wustrow, and D. Levin, “Weaponizing middleboxes for TCP reflected amplification,” in USENIX Security Symposium. USENIX, 2021. [Online]. Available: https://www.usenix.org/system/files/sec21-bock.pdf
[29] Sparks, Neo, Tank, Smith, and Dozer, “The collateral damage of Internet censorship by DNS injection,” SIGCOMM Computer Communication Review, vol. 42, no. 3, pp. 21-27, 2012. [Online]. Available: https://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf
[30] B. Marczak, N. Weaver, J. Dalek, R. Ensafi, D. Fifield, S. McKune, A. Rey, J. Scott-Railton, R. Deibert, and V. Paxson, “An analysis of China’s “Great Cannon”,” in Free and Open Communications on the Internet. USENIX, 2015. [Online]. Available: https://www.usenix.org/system/files/conference/foci15/foci15-paper-marczak.pdf
[31] P. Pearce, B. Jones, F. Li, R. Ensafi, N. Feamster, N. Weaver, and V. Paxson, “Global measurement of DNS manipulation,” in USENIX Security Symposium. USENIX, 2017. [Online]. Available: https://www.usenix.org/system/files/conference/usenixsecurity 17/sec17-pearce.pdf
[32] A. Filastò and J. Appelbaum, “OONI: Open observatory of network interference,” in Free and Open Communications on the Internet. USENIX, 2012. [Online]. Available: https://www.usenix.org/system/files/conference/foci12/foci12-final12.pdf
[33] R. S. Raman, P. Shenoy, K. Kohls, and R. Ensafi, “Censored Planet: An Internet-wide, longitudinal censorship observatory,” in Computer and Communications Security. ACM, 2020. [Online]. Available: https://www.ramakrishnansr.com/assets/censoredplanet.pdf
[34] A. A. Niaki, S. Cho, Z. Weinberg, N. P. Hoang, A. Razaghpanah, N. Christin, and P. Gill, “ICLab: A global, longitudinal internet censorship measurement platform,” in Symposium on Security & Privacy. IEEE, 2020. [Online]. Available: https://people.cs.umass.edu/~phillipa/papers/oakland2020.pdf
[35] GreatFire, “GreatFire Analyzer,” Online Censorship In China | GreatFire Analyzer, n.d., accessed: 2025-04-18.
[36] GreatFire, “Blocky,” https://blocky.greatfire.org/, accessed: 2025-04-18.
[37] Anonymous and Amonymous. (2022, Oct.) Sharing a modified Shadowsocks as well as our thoughts on the cat-and-mouse game. [Online]. Available: Sharing a modified Shadowsocks as well as our thoughts on the cat-and-mouse game · Issue #136 · net4people/bbs · GitHub
[38] P. Winter. (2013, Mar.) GFW actively probes obfs2bridges. [Online]. Available: GFW actively probes obfs2 bridges (#8591) · Issues · Legacy / Trac · GitLab
[39] P. Winter and S. Lindskog, “How the Great Firewall of China is blocking Tor,” in Free and Open Communications on the Internet. USENIX, 2012. [Online]. Available: https://www.usenix.org/system/files/conference/foci12/foci12-final2.pdf
[40] T. Wilde. (2012) Knock knock knockin’ on bridges’ doors. [Online]. Available: Knock Knock Knockin' on Bridges' Doors | The Tor Project
[41] Anonymous, Anonymous, Anonymous, D. Fifield, and A. Houmansadr. (2021, Jan.) A practical guide to defend against the GFW’s latest active probing. [Online]. Available: A practical guide to defend against the GFW's latest active probing · Issue #58 · net4people/bbs · GitHub
[42] Anonymous. (2021, Jan.) How to Deploy a Censorship Resistant Shadowsocks-libev Server. [Online]. Available: How to Deploy a Censorship Resistant Shadowsocks-libev Server
[43] S. Frolov, J. Wampler, and E. Wustrow, “Detecting probe-resistant proxies,” in Network and Distributed System Security. The Internet Society, 2020. [Online]. Available: https://www.ndss-symposium.org/wp-content/uploads/2020/02/23087.pdf
[44] S. Frolov and E. Wustrow, “HTTPT: A probe-resistant proxy,” in Free and Open Communications on the Internet. USENIX, 2020. [Online]. Available: https://www.usenix.org/system/files/foci20-paper-frolov.pdf
[45] D. Xue, B. Mixon-Baca, ValdikSS, A. Ablove, B. Kujath, J. R. Crandall, and R. Ensafi, “TSPU: Russia’s decentralized censorship system,” in Internet Measurement Conference. ACM, 2022. [Online]. Available: https://dl.acm.org/doi/pdf/10.1145/3517745.3561461
[46] A. Ortwein, K. Bock, and D. Levin, “Towards a comprehensive understanding of Russian transit censorship,” in Free and Open Communications on the Internet, 2023. [Online]. Available: https://www.petsymposium.org/foci/2023/foci-2023-0012.pdf
[47] R. Ramesh, R. S. Raman, M. Bernhard, V. Ongkowijaya, L. Evdokimov, A. Edmundson, S. Sprecher, M. Ikram, and R. Ensafi, “Decentralized control: A case study of Russia,” in Network and Distributed System Security. The Internet Society, 2020. [Online]. Available: https://www.ndss-symposium.org/wp-content/uploads/2020/02/23098.pdf
[48] T. K. Yadav, A. Sinha, D. Gosain, P. K. Sharma, and S. Chakravarty, “Where the light gets in: Analyzing web censorship mechanisms in India,” in Internet Measurement Conference. ACM, 2018. [Online]. Available: https://delivery.acm.org/10.1145/3280000/3278555/p252-Yadav.pdf
[49] B. Liu, C. Lu, H. Duan, Y. Liu, Z. Li, S. Hao, and M. Yang, “Who is answering my queries: Understanding and characterizing interception of the DNS resolution path,” in USENIX Security Symposium, Aug. 2018. [Online]. Available: https://www.usenix.org/system/files/conference/usenixsecurity 18/sec18-liu_0.pdf
[50] Net4People, “Net4People BBS Issues.” [Online]. Available: https://github.com/net4people/bbs/issues
[51] NTC Community, “NTC Party: “No Thought is a Crime” — Internet Censorship Circumvention Forum.” [Online]. Available: https://ntc.party/
[52] XTLS, “Xray-core Project Issue Tracker.” [Online]. Available: https://github.com/XTLS/Xray-core/issues
[53] V2Fly, “V2Ray Core Project Issue Tracker.” [Online]. Available: https://github.com/v2fly/v2ray-core/issues
== OCR 页面 16 结束 ==
== OCR 页面 17 开始 ==
[54] SagerNet, “sing-box Project Issue Tracker.” [Online]. Available: https://github.com/SagerNet/sing-box/issues
[55] Hysteria, “Hysteria Proxy Project Issue Tracker.” [Online]. Available: https://github.com/apernet/hysteria/issues
[56] ThEWiZaRd0fBsoD,“在启用TCP Timestamp(TCP时间戳)后,GFW对obfs4的审查无效/After enabling TCP Timestamp, GFW’s censorship of obfs4 is rendered ineffective," https://github.com/net4people/bbs/issues/442, Jan 2025, (Accessed on April 18, 2025).
[57] -, “The operators in Henan Province, China, seem to have less stringent censorship regarding IPV6,” https://github.com/net4people/bbs/issues/416, Nov 2024, (Accessed on April 18, 2025).
[58] ghost,““河南新上的SNI/HOST黑名单墙”(GitHub Discussion #3601)," https://github.com/XTLS/Xray-core/discussions/3601#discussioncomment-10293992, Aug 2024, (Accessed on April 18, 2025).
[59] H. Lee,“启用TCP Timestamps解决SNI阻断,”https://blog.tsinbei.com/archives/1361/, Sep 2023, (Accessed on April 18, 2025).
[60] V. L. Pochat, T. Van Goethem, S. Tajalizadehkhoob, M. Korczyński, and W. Joosen, “Tranco: A research-oriented top sites ranking hardened against manipulation,” in Network and Distributed System Security Symposium 2019, ser. NDSS '19, 2019.
[61] X. Mi, X. Feng, X. Liao, B. Liu, X. Wang, F. Qian, Z. Li, S. Alrwais, L. Sun, and Y. Liu, “Resident Evil: Understanding residential IP proxy as a dark service,” in 2019 IEEE Symposium on Security and Privacy (SP), 2019, pp. 1185-1201. [Online]. Available: https://ieeexplore.ieee.org/document/8835239
[62] “IP2Location LITE IP address geolocation database.” [Online]. Available: https://www.ip2location.com/database/ip2location
[63] K. Bock, G. Hughey, L.-H. Merino, T. Arya, D. Liscinsky, R. Pogosian, and D. Levin, “Come as you are: Helping unmodified clients bypass censorship with server-side evasion,” in SIGCOMM. ACM, 2020. [Online]. Available: https://geneva.cs.umd.edu/papers/come-as-you-are.pdf
[64] 5e2t, “After enabling TCP timestamp, GFW’s censorship of obfs4 is rendered ineffective,” https://github.com/net4people/bbs/issues/442#issuecomment-2566913190, Jan 2025, (Accessed on April 7, 2025).
[65] N. Niere, S. Hebrok, J. Somorovsky, and R. Merget, “Poster: Circumventing the GFW with TLS record fragmentation,” in Computer and Communications Security. ACM, 2023. [Online]. Available: https://nerd2.nrw/wp-content/uploads/2024/05/3576915.3624372.pdf
[66] G. Wan, F. Gong, T. Barbette, and Z. Durumeric, “Retina: analyzing 100GbE traffic on commodity hardware,” in ACM SIGCOMM, 2022. [Online]. Available: https://zakird.com/papers/retina.pdf
[67] Κ. Bock, P. Bharadwaj, J. Singh, and D. Levin, “Your censor is my censor: Weaponizing censorship infrastructure for availability attacks,” in Workshop on Offensive Technologies. IEEE, 2021. [Online]. Available: https://www.cs.umd.edu/~dml/papers/weaponizing_woot21.pdf
[68] klzgrad, "GFW技术报告: 入侵防御系统的评测和问题,” https://www.chinagfw.org/2009/09/gfw_21.html, Aug 2009, accessed: 2025-04-11.
[69] gfwrev, "HTTP URL/深度关键词检测,” https://gfwrev.blogspot.com/2010/03/http-url.html, Mar 2010, accessed: 2025-04-07.
[70] N. Weaver, R. Sommer, and V. Paxson, “Detecting forged TCP reset packets,” in Network and Distributed System Security. The Internet Society, 2009. [Online]. Available: https://www.ndss-symposium.org/wp-content/uploads/2017/09/weav.pdf
[71] W. Eddy, “Transmission Control Protocol (TCP),” RFC 9293, Aug. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9293
[72] R. S. Raman, M. Wang, J. Dalek, J. Mayer, and R. Ensafi, “Network measurement methods for locating and examining censorship devices,” in Emerging Networking Experiments and Technologies. ACM, 2022. [Online]. Available: https://dl.acm.org/doi/pdf/10.1145/3555050.3569133
[73] “Centralized Zone Data Service,” https://czds.icann.org/home, (Accessed on 01/31/2024).
[74] “Website categorization api | domain category check | whoisxml api,” https://website-categorization.whoisxmlapi.com/api, (Accessed on 04/25/2024).
[75] “Security forces in china attack protesters seeking frozen funds - the new york times,” https://www.nytimes.com/2022/07/11/business/china-bank-protest.html, (Accessed on 04/25/2024).
[76] XRay developers. XRay. [Online]. Available: https://github.com/XTLS/Xray-core
[77] GoodbyeDPI developers. GoodbyeDPI. [Online]. Available: https://github.com/ValdikSS/GoodbyeDPI
[78] ShadowRocket developers. ShadowRocket. [Online]. Available: https://apps.apple.com/us/app/shadowrocket/id932747118
[79] S. Frolov and E. Wustrow, “The use of TLS in censorship circumvention,” in Network and Distributed System Security. The Internet Society, 2019. [Online]. Available: https://tlsfingerprint.io/static/frolov2019.pdf
[80] XRay developers. XRay pull request. [Online]. Available: https://github.com/XTLS/Xray-core/pull/3660
[81] M. Bailey, D. Dittrich, E. Kenneally, and D. Maughan, “The menlo report,” IEEE Security and Privacy, vol. 10, no. 2, p. 71-75, mar 2012. [Online]. Available: https://doi.org/10.1109/MSP.2012.52
== OCR 页面 17 结束 ==
== OCR 页面 18 开始 ==
附录 A.
元评审 (Meta-Review)
以下元评审由 2025 年 IEEE 安全与隐私研讨会 (S&P) 的程序委员会根据征稿通知中的评审流程要求准备。
A.1. 总结
这篇论文通过实证确认了轶事证据，即中国河南省已开始部署区域性审查机制，其目的在于比防火长城本身采用的机制更为严格。论文对河南防火墙在入/出和出/入方向上进行的审查进行了全面分析，揭示了其运作方式、封锁策略和残留审查机制。此外，论文还考察了中国其他省份是否也存在类似的区域性审查，但未发现除防火长城之外的额外干扰证据。
A.2. 科学贡献
• 对先前研究有限的重要结果进行了独立确认
• 在一个既有领域中迈出了有价值的一步
A.3. 接受理由
- 本文对先前研究有限的重要结果进行了独立确认。论文构建了一个测量装置，以确认（并扩展基于）关于河南省内区域性审查的轶事报告。除了对这种新型区域性审查的存在和封锁行为提供了系统的理解，本文还独立确认了防火长城封锁行为的不对称性。
- 本文通过应用不同的已知方法论，详尽地研究了中国部分地区一种新的审查现象，在一个既有领域中迈出了有价值的一步。文中所进行的测量是可靠的，并且依赖于久经考验的测量方法，为一种尚未被深入分析的审查形式提供了见解。
== OCR 页面 18 结束 ==
Last edited by @suen 2025-05-06T08:21:44Z