Great Firewall Report - GFW Report on Great Firewall Report

Geedge & MESA Leak: Analyzing the Great Firewall’s Largest Document Leak

Fri, 12 Sep 2025 00:00:00 +0000

1. Introduction

The Great Firewall of China (GFW) experienced the largest leak of internal documents in its history on Thursday September 11, 2025. Over 500 GB of source code, work logs, and internal communication records were leaked, revealing details of the GFW’s research, development, and operations.

The leak originated from a core technical force behind the GFW: Geedge Networks (whose chief scientist is Fang Binxing) and the MESA Lab at the Institute of Information Engineering, Chinese Academy of Sciences. The documents show that the company not only provides services to governments in places like Xinjiang, Jiangsu, and Fujian, but also exports censorship and surveillance technology to countries such as Myanmar, Pakistan, Ethiopia, Kazakhstan, and other unidentified country under the “Belt and Road” framework.

The significance and far-reaching implications of this leak are substantial. Due to the massive volume of data, GFW Report will continue to analyze and provide updates on the current page and on the Net4People.

2. Download Link

Enlace Hacktivista has provided the access to the leak:

BitTorrent: https://enlacehacktivista.org/geedge.torrent
Direct HTTPS download: https://files.enlacehacktivista.org/geedge/

The leaked files total about 600 GB. Among them, the file mirror/repo.tar alone, as an archive of the RPM packaging server, takes up 500 GB.

For detailed instructions on how to use the specific files, David Fifield has already provided a more thorough explanation on Net4People.

     7206346  mirror/filelist.txt
497103482880  mirror/repo.tar
 14811058515  geedge_docs.tar.zst
  2724387262  geedge_jira.tar.zst
 35024722703  mesalab_docs.tar.zst
 63792097732  mesalab_git.tar.zst
       71382  A HAMSON-EN.docx
       16982  A Hamson.docx
      161765  BRI.docx
       14052  CPEC.docx
     2068705  CTF-AWD.docx
       19288  Schedule.docx
       26536  TSG Solution Review Description-20230208.docx
      704281  TSG-问题.docx
       35040  chat.docx
       27242  ty-Schedule.docx
      111244  待学习整理-23年MOTC-SWG合同草本V.1-2020230320.docx
       52049  打印.docx
      418620  替票证明.docx
      260551  领导修改版-待看Reponse to Customer's Suggestions-2022110-V001--1647350669.docx

3. Safety Considerations

Due to the highly sensitive nature of these leaked materials, we strongly advise anyone who chooses to download and analyze them to take proper operational security precautions. It may be possible that these files may contain potentially risky content and accessing them in an insecure environment could expose you to surveillance or malware.

Please consider analyzing these files only in an isolated (virtual) machine without internet access.

4. Background

Great Firewall of China (GFW) is an umbrella term for a series of Internet censorship systems. Behind it, teams for research and development, operations, hardware, and management each play their roles and coordinate with one another. In addition to fixed government agencies (such as the CNCERT), different entities provide technical support depending on individual contracts and tenders. This leak originates from an important branch of the GFW’s R&D capacity: Geedge Networks and MESA Lab. The MESA lab is affiliated with the Institute of Information Engineering, Chinese Academy of Sciences (IIE, CAS).

The origins trace back to Fang Binxing, the “Father of the Great Firewall”, coming to Beijing. At the end of 2008, he established the National Engineering Laboratory for Information Content Security (NELIST), initially based at the Institute of Computing Technology, Chinese Academy of Sciences. Beginning in 2012, the supporting institution changed to the Institute of Information Engineering, Chinese Academy of Sciences. In January 2012, some NELIST personnel formed a team at IIE, and in June 2012 the team was officially named the Processing Architecture Team, English name MESA (Massive Effective Stream Analysis). Below is an excerpt from MESA’s self-introduction:

MESA Timeline

   January 2012: Liu Qingyun, Sun Yong, Zheng Chao, Yang Rong, Qin Peng, Liu Yang, and Li Jia formed a team at IIE;
   June 2012: The team was officially named the Processing Architecture Team, English name MESA (Massive Effective Stream Analysis);
   2012: Liu Qingyun was selected for IIE’s inaugural “Rising Star” talent program;
   2012: Yang Wei and Zhou Zhou joined the team;
   2012: The team successfully completed the cybersecurity assurance task for the 18th National Congress;
   January 2013: MESA’s first PhD trainee, Liu Tingwen, graduated successfully;
   2013: Li Shu, Liu Junpeng, and Liu Xueli joined the team;
   December 2013: The MESA team received IIE’s 2013 Major Scientific and Technological Progress Award;
   2014: Zhou Zhou was selected for IIE’s “Rising Star” talent program;
   2014: The MESA component SAPP platform began large-scale engineering deployment;
   2014: Zhang Peng, Yu Lingjing, and Jia Mengdie joined the team;
   2015: Zheng Chao was selected for IIE’s “Rising Star” talent program, and Zhang Peng was selected for IIE’s “Outstanding Talent Introduction” program;
   August 2015: MESA moved from the Agriculture Bureau to the Huayan Beili office area;
   July 2015: PhD student Sha Hongzhou trained by MESA graduated successfully, and Liu Xiaomei received Outstanding Graduate honors;
   2016: Dou Fenghu, Zhu Yujia, Wang Fengmei, Li Zhao, Lu Qiuwen, Du Meijie, Shen Yan, and Fang Xupeng joined MESA in succession, and the team expanded rapidly;
   2016: The team undertook multiple major engineering projects, with annual contracted revenue exceeding 35 million;
   December 2016: The MESA team participated in winning the National Science and Technology Progress Award (Second Prize);
   2018: Sun Yong and Zhou Zhou received the 2017 National State Secrecy Science and Technology Award (Second Prize);

By 2018, Fang Binxing had also established himself in Hainan, and Geedge (Hainan) Information Technology Co., Ltd. (Geedge Networks Ltd.) was founded in the same year. Fang served as chief scientist, and the “core R&D personnel came from universities and research institutes such as the Chinese Academy of Sciences, Harbin Institute of Technology, and Beijing University of Posts and Telecommunications.” Much of this talent came from MESA—for example, Zheng Chao served as CTO. Attentive readers will notice that many mentors and students from the MESA timeline appear in the leaked Geedge company git commits.

5. Analysis of Non–Source Code Files

The non–source-code portion of the leaked files has already been analyzed in detail by multiple professional teams, including, but not limited to, InterSecLab, Amnesty International, Justice for Myanmar, The Globe and Mail, Der Standard, and Follow the Money. David Fifield has collected and compiled these reports as follows:

InterSecLab: The Internet Coup (archive) PDF 76 pages (archive)
Amnesty International: Shadows of Control: Censorship and mass surveillance in Pakistan (archive) PDF 102 pages (archive)
Justice for Myanmar: Silk Road of Surveillance (archive) PDF 47 pages (archive)
The Globe and Mail: Leaked files show a Chinese company is exporting the Great Firewall’s censorship technology (archive)
Der Standard: Wie China seine Totalüberwachung des Internets ins Ausland exportiert (archive)
Follow the Money: China exports censorship tech to authoritarian regimes – aided by EU firms (archive)

Below are David Fifield’s notes on related media reports and technical write-ups. Please note that the source-code portion of the leak has not yet been analyzed:

6. Analysis of Source Code Files

The source-code portion of the leaked files has not yet been carefully analyzed. This leak is significant and far-reaching. Given the large volume of material, GFW Report will continue to update our analysis and findings on the current page as well as on Net4People.

6.1 Analysis of MESA Git contributors

On September 26, 2025, Dynamic Internet Technology (DIT) released a website that visualizes the contributors and contributions to the MESA Lab git repos:

https://mesaauthor.dit-inc.us/

7. Acknowledgement

We would like to thank InterSecLab, Amnesty International, Justice for Myanmar, The Globe and Mail (环球邮报), Der Standard, and Follow the Money for their extensive and rigorous work. As part of a research consortium, InterSecLab has been working on indexing, translating, analyzing, interpreting, and summarizing 600 GB of leaked data over the course of nine months — an effort that has been invaluable in shedding light on the significance of this leak. The investigations, reporting, and analysis from all of these organizations provided essential context and insights for future work.

To clarify, the GFW Report has never contributed to the analysis that forms the reports by these organizations.

8. Contact or Join Us

This report was first published on GFW Report. We also actively updated our analysis and findings on Net4People.

We encourage you to share questions, comments, analysis, or additional evidence on this topic, either publicly or privately. Our private contact information can be found in the footer of the GFW Report website.

积至公司与MESA实验室：防火长城史上最大规模文件外泄分析

Fri, 12 Sep 2025 00:00:00 +0000

1. 引言

2025 年 9 月 11 日星期四，中国防火长城（GFW）经历了其历史上最大规模的内部文件泄露事件。超过 500 GB 的源代码、工作日志和内部通信记录被泄露，揭示了 GFW 的研发和运作细节。

此次泄露源自 GFW 背后的一支重要技术力量：积至（海南）信息技术有限公司（Geedge Networks Ltd.）及中国科学院信息工程研究所（简称：中科院信工所）第二研究室的处理架构组 MESA 实验室。文件显示，该公司不仅为新疆、江苏、福建等地政府提供服务，还在“一带一路”框架下向缅甸、巴基斯坦、埃塞俄比亚、哈萨克斯坦以及一个未被识别的国家输出审查与监控技术。

该泄漏事件意义重大且深远，由于资料体量庞大，GFW Report 将在当前页面，以及 Net4People 上持续更新我们的分析与发现。

2. 下载链接

Enlace Hacktivista 提供了获取泄露数据的途径：

BitTorrent: https://enlacehacktivista.org/geedge.torrent
HTTPS 直接下载: https://files.enlacehacktivista.org/geedge/

泄漏文件总计约 600 GB。其中mirror/repo.tar单个文件，作为RPM打包服务器的存档就占了500 GB。具体的文件的使用方法，David Fifield 已经在Net4People 上提供了更详尽的说明。

     7206346  mirror/filelist.txt
497103482880  mirror/repo.tar
 14811058515  geedge_docs.tar.zst
  2724387262  geedge_jira.tar.zst
 35024722703  mesalab_docs.tar.zst
 63792097732  mesalab_git.tar.zst
       71382  A HAMSON-EN.docx
       16982  A Hamson.docx
      161765  BRI.docx
       14052  CPEC.docx
     2068705  CTF-AWD.docx
       19288  Schedule.docx
       26536  TSG Solution Review Description-20230208.docx
      704281  TSG-问题.docx
       35040  chat.docx
       27242  ty-Schedule.docx
      111244  待学习整理-23年MOTC-SWG合同草本V.1-2020230320.docx
       52049  打印.docx
      418620  替票证明.docx
      260551  领导修改版-待看Reponse to Customer's Suggestions-2022110-V001--1647350669.docx

3. 安全注意事项

鉴于这些泄露材料高度敏感，我们强烈建议任何选择下载和分析它们的人采取适当的操作安全防护措施，并假设这些文件可能包含潜在的风险内容（例如在不安全的环境中存储或分析它们可能会导致监控或恶意软件攻击）。请考虑仅在无网络连接的隔离环境中分析这些文件（如虚拟机或不联网的主机）。

4. 背景

中国的防火长城GFW是一系列互联网审查系统的统称。其背后的研发，运维，硬件，管理，各司其职、相互协作。除了固定的政府部门（如国家互联网应急中心），根据每次的合同和招标，还会有不同的单位作为技术支撑。此次泄露源自 GFW 背后研发力量中的重要一支：积至和 MESA。MESA 实验室就是中国科学院信息工程研究所（简称：中科院信工所）第二研究室的处理架构组。

这一切最早追溯到被誉为"防火长城之父“的方滨兴来到北京，先是在2008年底成立信息内容安全国家工程实验室（NELIST），依托中国科学院计算技术研究所。后在2012年起依托单位改为中国科学院信息工程研究所。2012年1月，部分NELIST的人马在信工所组建团队，并于2012年6月将团队正式定名处理架构团队，英文名称 MESA（Massive Effective Stream Analysis）。下面是 MESA 自我介绍的一段摘抄：

MESA大事记

   2012年1月，刘庆云，孙永，郑超，杨嵘，秦鹏，刘洋，李佳在信工所组建团队；
   2012年6月，团队正式定名处理架构团队，英文名称 MESA（Massive Effective Stream Analysis）；
   2012年，刘庆云入选信工所首届“青年之星”人才培养计划；
   2012年，杨威，周舟加入团队；
   2012年，团队顺利完成“十八大”网络安全保障任务；
   2013年1月，MESA培养的第一名博士柳厅文顺利毕业；
   2013年，李舒，刘俊朋，刘学利加入团队；
   2013年12月，MESA团队获得2013年度信工所重大科技进展奖；
   2014年，周舟入选信工所“青年之星”人才培养计划；
   2014年，MESA组件SAPP平台开始在工程中大规模应用；
   2014年，张鹏，喻灵婧，贾梦蝶加入团队；
   2015年，郑超入选信工所“青年之星”人才培养计划，张鹏入选信工所“引进优秀人才”培养计划；
   2015年8月，MESA从农业局搬迁到华严北里办公区；
   2015年7月，MESA培养的博士生沙泓州顺利毕业，刘晓梅获得优秀毕业生荣誉；
   2016年，窦凤虎、朱宇佳、王凤梅、李钊、陆秋文、杜梅婕、沈岩、方绪鹏陆续加入MESA，团队规模迅速扩大；
   2016年，团队承担多项重大工程项目，年收入合同额超过3500万；
   2016年12月，MESA团队参与获得国家科技进步二等奖；
   2018年，孙永、周舟荣获2017年国家保密科学技术二等奖；

到了2018年，方滨兴此时已经在海南也站稳了脚跟，积至（海南）信息技术有限公司（Geedge Networks Ltd.）就在同年诞生了。方滨兴作首席科学家，“核心研发人员来自中科院、哈尔滨工业大学、北京邮电大学等高校和科研院所“。其中大部分血液就来自 MESA，比如郑超担任CTO。细心的读者会发现，MESA 大事记中的许多导师和学生都会在泄漏的积至公司的git commit中出现。

5. 非源码文件分析

此次泄漏文件的非源代码部分已经被多个专业团队详细分析，这些团队包括但不限于 InterSecLab、国际特赦组织（Amnesty International）、Justice for Myanmar、环球邮报（The Globe and Mail）、Der Standard，以及 Follow the Money。

David Fifield 已经收集并整理了这些报告并做了笔记。请注意泄漏文件的源代码的部分还没有被分析：

InterSecLab：互联网政变（The Internet Coup） (存档) PDF 76 页 (存档)
国际特赦组织（Amnesty International）：控制的阴影：巴基斯坦的审查与大规模监控 (存档) PDF 102 页 (存档)
Justice for Myanmar：监控的丝绸之路（Silk Road of Surveillance） (存档) PDF 47 页 (存档)
环球邮报（The Globe and Mail）：泄露文件显示一家中国公司正在出口“防火长城”的审查技术 (存档)
Der Standard：中国如何将其全面的互联网监控出口到国外 (存档)
Follow the Money：中国将审查技术出口至威权政权——在欧盟公司的协助下 (存档)

5.1 对报道的摘抄

以下为 David Fifield 对报道的摘抄:

以下是三篇新闻文章的笔记和重点。

环球邮报：泄露文件显示一家中国公司正在向海外出口防火长城的审查技术

泄露的内部文件显示，Geedge 直接与各国政府和互联网服务提供商（ISP）合作，安装用于审查和监控的产品。他们提供的功能包括追踪用户位置和网络访问历史，以及封锁服务和翻墙系统。

……超过 10 万份与 Geedge Networks 有关的内部文件泄露。这是一家鲜为人知的中国公司，却悄然在开发防火长城和向世界各国政府提供类似的审查能力方面扮演了关键角色…… 这些文件不仅揭示了 Geedge 如何向专制客户出口先进的审查技术，使他们获得本来不具备的能力，也揭示了防火长城本身的演变。其中包括过滤网站和应用程序的方案、实时在线监控、对特定地区进行网络限速或断网、通过在线痕迹识别匿名用户，以及封锁包括 VPN 在内的翻墙工具。

Geedge 至少涉足五个国家：哈萨克斯坦、埃塞俄比亚、缅甸（#369）、巴基斯坦，以及一个仅以代号 A24 出现的未公开国家。哈萨克斯坦是其 2018 年成立后的早期客户。

Geedge 成立于 2018 年后不久，首批客户之一便是哈萨克斯坦政府，公司向其出售了旗舰产品「天狗安全网关」（TSG），该产品具备类似中国防火长城的功能，监控和过滤所有经过的网络流量，并检测和阻止翻墙行为。同样的工具也在埃塞俄比亚和缅甸部署，在缅甸军政府禁止 VPN 的过程中发挥了关键作用。在许多情况下，Geedge 与其他私营公司合作，包括埃塞俄比亚的 Safaricom、缅甸的 Frontiir 和 Ooredoo 等 ISP，共同实施政府审查。文件显示，这些 ISP 都未回应置评请求。

缅甸在 “正义缅甸” 报告《监控丝绸之路》中被特别提及。巴基斯坦则在国际特赦组织报告《控制的阴影》中被特别提及。

关于巴基斯坦，这篇 环球邮报 的文章指出，Geedge 在 Sandvine 撤出后，把自己的新系统（包括 TSG）安装在原有 Sandvine 留下的设备上。（Sandvine 现已更名为 AppLogic。）

Sandvine 于 2023 年在外界日益严格的审查下退出巴基斯坦，很快就被 Geedge 替代。文件显示，Geedge 不仅利用了现有的 Sandvine 安装设备，还提供了新技术，驱动巴基斯坦的“网络监控系统”（该国的国家级防火墙）。 AppLogic 在声明中表示，他们并不了解 Geedge，且任何被重新利用的硬件都是“现成设备”，不具备 Sandvine 解决方案所独有的特殊功能。

文章引用了同一份招聘广告（曾在 #369 (comment) 出现），其中提到另外四个国家：马来西亚、巴林、阿尔及利亚和印度：

Geedge 最近发布的一则招聘广告还提到了“一带一路”。该广告寻找“能说英语或其他外语”的候选人，并愿意赴“巴基斯坦、马来西亚、巴林、阿尔及利亚和印度”进行 3 至 6 个月的商务出差。

除了海外，文件显示 Geedge 也在新疆、江苏和福建省有部署。这可能意味着一种更加分布式、区域化的防火墙系统，类似河南的情况，见 #416 和《一堵墙后的墙》。

Geedge 与中国科学院大学的 MESA 实验室关系密切。我们之前在 #471 (comment) 的读书组帖子中提到过 MESA 的“SAPP”网络分析平台。Geedge 的首席技术官郑超是 MESA 2012 年 1 月的联合创始人。

Geedge 文件中自豪地称方某为“防火长城之父”。公司其他高管，如 CEO 王远地和 CTO 郑超，被列为互联网审查相关论文的合著者，以及 Geedge 提交的专利的发明人。公司与中科院 MESA 实验室保持紧密关系，文件显示双方人员有定期合作。一位 MESA 研究员曾记录 2024 年 7 月新疆会议的内容，与会者谈到利用技术“打击翻墙工具”，并建立“新疆分中心”作为“反恐先锋”和“省级能力示范”。

公司对翻墙系统和 VPN 进行专门研究，以便封锁它们。

文件显示，公司员工致力于对许多常见工具进行逆向工程，并寻找封锁方法。其中一组文件列出了九个商业 VPN 已被“解决”，并提供了识别和过滤流量的多种方式。这些功能与防火长城长期展示的能力一致，目前大多数商业 VPN 在中国境内无法访问，许多专门的翻墙工具也难以使用。

标准报：中国如何将全面网络监控出口海外

本文列出了 Geedge 技术的其他功能，除了追踪用户和屏蔽访问之外，还包括：在 HTTP 会话中注入恶意代码，以及直接发起 DDoS 流量攻击。

Geedge Networks 提供的技术极其强大，Intersec Lab 的 IT 安全专家的分析表明，它们能让当局在特定地区（如抗议期间）监控个人的数据流量。它们可以精准识别并封锁特定 VPN，而用户此前一直依赖 VPN 来绕过当局的数字审查。甚至可以向网站插入恶意代码，或发起 DDoS 攻击，使特定网站瘫痪。

文中也提到 Geedge 软件部署在巴基斯坦 Sandvine 硬件上。显然，Geedge 特别强调软硬件解耦。

后来，加拿大公司 Sandvine 向巴基斯坦提供了一套系统，使当局能够封锁不良网站。2023 年，Sandvine（后更名 Applogic Networks）退出巴基斯坦，但显然留下了部分硬件。调查显示，这些硬件至少在最初被 Geedge Networks 重新利用。Applogic Networks 告诉《标准报》，他们对此毫不知情，并强调其技术无法解密用户数据或植入间谍软件。

法国公司泰雷兹集团为 Geedge 提供许可管理。Geedge 至少使用过一个德国服务器进行软件下载分发。（或许是为了避免若服务器在中国境内会被防火长城干扰。）

一家法国公司——可能是无意中——成了 Geedge 的帮手。泰雷兹集团出售的软件可用于许可证管理。Geedge 显然利用该软件来控制其售出的产品，比如限制软件的使用时长。泰雷兹集团向《标准报》确认这家中国公司是其客户之一。但 Geedge 软件并不依赖法国产品才能运行。泰雷兹称自己与监控无关。此外，Geedge 还利用德国服务器，通过下载链接向客户分发软件。其动机尚不清楚，但众所周知，中国防火长城正日益限制海外访问中国网站。德国相关部门未对《标准报》的询问作出回应。

Follow the Money：中国向威权政权出口审查技术——欧盟企业亦有协助

本文概述了 Geedge 的多种产品，这些产品可能打包出售，也可能单独提供。“Cyber Narrator” 是一种高层监控面板，非技术用户也能直接使用。“天狗安全网关”（TSG）是实际执行网络监控和封锁的设备。TSG Galaxy 是数据存储与分析流水线。“Network Zodiac” 是一个对其他系统进行管理与监控的工具。

Geedge 的产品组合包括多种技术。InterSecLab 的数据分析显示，“Cyber Narrator”是客户的主要界面，即使非技术人员也能利用它监控特定区域的互联网用户（如示威期间）。其次是被认为是旗舰产品的“天狗安全网关”，它能封锁 VPN，还能向网站注入恶意代码或发起攻击。另一个产品是“TSG Galaxy”，用于存储收集到的用户数据；而“Network Zodiac”则监控其他所有系统，并报告错误。

Geedge 的设备（如 TSG）可能安装的范围远超此次泄露提及的国家，因为其官网声称“服务 40+ 全球运营商”：

据中国媒体报道，2024 年 Binxing 在一次演讲中宣布，公司计划“拓展国际市场”，推动中国技术全球化。文件显示，缅甸、巴基斯坦、埃塞俄比亚和哈萨克斯坦都至少持有旗舰产品 TSG 的许可证。此外，Geedge 官网宣称服务“40+ 全球运营商”，暗示其影响远超泄露文件所示。

一份 2023 年 2 月的 Geedge 工单涉及埃塞俄比亚的社交媒体封锁，与当时已知的封锁情况（#210）相符。

2023 年 2 月，全国抗议浪潮期间，Geedge 的一份工单显示其专家受召处理与 YouTube、Twitter 等社交媒体平台相关的问题。同一时间段，外界也报道了这些平台的封锁情况。

至少有一份 Jira 工单显示了电子邮件明文拦截的证据：

内部文件显示，Geedge 的工具（包括 TSG）已在[巴基斯坦]使用——至少在一起案例中，某全球航运公司与一家巴基斯坦公司的电子邮件通信被拦截。

5.2 对报告的分析

以下为 David Fifield 对报告的摘抄和分析：

InterSecLab 报告（PDF 76 页）写得非常好，包含大量具体的技术细节。它更详细地解释了 Geedge 的产品套件、其与 MESA 研究实验室的关系，以及在各国的部署时间线。

p.7

基于对一批超过 100,000 份 Geedge Networks 文档泄露材料的分析（该材料被分享给 InterSecLab），本研究揭示了 Geedge Networks 系统的功能与能力，包括深度包检测、对移动用户的实时监控、对互联网流量的精细化控制，以及可按地区定制的审查规则。泄露材料还揭示了 Geedge Networks 与学术实体 Mesalab 的关系，以及他们与客户政府之间的互动。其对数据主权的影响十分重大，我们的发现对监控与信息控制技术商品化的趋势提出了担忧。本研究审视了 Geedge Networks 在多个国家的系统的最新进展，包括其已知的部署时间线。通过分析该公司的内部文档，InterSecLab 得以记录商业化“国家防火墙”的扩张，并在这些系统扩散的背景下，推测其对全球互联网未来的影响。

Geedge 产品

天狗安全网关（Tiangou Secure Gateway）

天狗安全网关（TSG）是多用途防火墙与监控设备的名称。TSG 包含所有主要的 DPI、过滤、跟踪、限速与攻击功能。TSG 提取的数据会进入 TSG Galaxy 进行存储与分析。

p.22

TSG 的能力非常广泛，具备通过深度包检测进行监控与审查、识别并封锁 VPN 和各种翻墙工具、限速流量、监控、跟踪、标记并封锁个体互联网用户，以及以恶意软件感染用户等功能。

TSG 可以安装在称为 TSGX 的一体化硬件平台上，也可以搭配客户的现有硬件运行。（报告称在巴基斯坦，Geedge 的 TSG 安装在 Sandvine 留下的设备上。）TSG 运行名为 TSG-OS 的操作系统，其基于 Red Hat Enterprise Linux 与 Docker（参见郑超等人的《“A Flexible and Efficient Container-based NFV Platform for Middlebox Networking”》）。

可按需安装任意数量的 TSG 节点，名为 Ether Fabric 的分流设备会按 5 元组哈希在所有节点之间做负载均衡。用于管理 TSG 集群的系统称为 Central Management 或“毕方”（Bifang）。

TSG 依赖名为 MARSIO 的用户态网络系统。也就是说，它自行进行路由与报文处理，为了效率而绕过 Linux 内核。它使用了 DPDK。（再次参见 2018 年的《“A Flexible and Efficient Container-based NFV Platform for Middlebox Networking”》。）

TSG Galaxy

TSG Galaxy 是一个数据存储与汇聚系统（抽取-转换-加载的数据仓库），保存诸如 TCP 与 UDP 会话及其协议（包括 TLS、SIP、DNS、QUIC）的元数据。Galaxy 中的信息可由 Cyber Narrator 进行查询。

p.20

TSG Galaxy 是 Geedge Networks 的 ETL（抽取、转换、加载）数据仓库方案，为互联网规模的大规模监控而设计，在客户国家收集并汇聚所有互联网用户及其在互联网上传输的数据的大量信息。它构建在开源的 Apache Kafka 流处理平台之上，这是一种常见的数据处理软件，常被在线零售商和广告商用于提供客户分析。针对本研究分析的泄露数据包括一份 TSG Galaxy 的 SQL 架构，表明 TSG Galaxy 用于存储全国范围内所有 TCP 与 UDP 会话的记录——这些传输协议广泛用于宽带与移动数据——以及所有的 SIP 会话。SIP 是一种用于 VoIP（网络语音通信）的协议，是大多数现代电话网络的基础。这意味着 TSG Galaxy 不仅允许监控互联网上的网络流量与内容，也允许监控电话通话。

TSG Galaxy 采用 IP 流信息导出（IPFIX）来分析流量，并使用深度包检测（DPI）提取元数据。通过 DPI，他们可以提取详细的指纹信息，包括 TLS 与 QUIC 的 SNI、DNS 查询以及电子邮件头。TSG Galaxy 还实现了连接指纹技术，例如 JA3 哈希，使 Cyber Narrator 能识别模式以帮助判断用户使用的操作系统以及连接所用的应用。这项技术可以用于识别用户是否使用 VPN 等翻墙工具来隐藏流量或绕过审查。在 TSG Galaxy 内，所有这些信息与来自互联网服务提供商的信息相结合，通过多种标识符（包括 IP 地址、用户的订户 ID、IMEI 与 IMSI）关联到具体的互联网用户。来自 TSG Galaxy 的元数据会被发送到一个数据库，客户可以通过 Cyber Narrator 进行查询。

Cyber Narrator

Cyber Narrator 是一个为非技术用户设计的用户界面，用于查询与展示由 TSG 收集、存储在 TSG Galaxy 中的信息。可以在 Cyber Narrator 中控制对服务与协议的封锁，并提供查找访问过特定内容的用户标识符的功能。Cyber Narrator 使用名为 WebSketch 的远程服务，为 IP 地址等标识符添加来自第三方数据经纪商或 Geedge 自身研究的元数据注释。

p.19

Cyber Narrator 是一款强大的工具，能够在个体客户层面跟踪网络流量，并可通过将活动与特定小区标识（cell ID）关联起来而实时识别移动用户的地理位置。该系统还允许政府客户查看聚合的网络流量。

……Cyber Narrator 可以让客户政府与安全力量更容易地将使用翻墙工具或访问其他被其视为潜在恶意的应用或网页的个体用户标记出来。Cyber Narrator 的分析能力还可用于阻断对特定网站或 VPN 服务的访问。通过 Cyber Narrator，客户政府还可以识别在限制之前访问过相关内容或服务的个人。

网络星座（Network Zodiac）

Network Zodiac，或称哪吒（Nezha），是一个监控其他组件的系统，类似于 Grafana。看起来 Network Zodiac 的仪表板具备 SSH 到任意其他主机（如某个 TSG 节点）的能力——显然，如果某台 Network Zodiac 主机被攻陷，这将带来巨大的风险集中。

p.33

与流行的开源解决方案相比，一个显著的差异化特性是其集成的 Web 终端，使网络管理员能够通过 SSH 远程连接到任意被监控的端点。该功能为客户提供了对网络设备进行故障排查和管理的直接访问。然而，它也使客户面临重大安全风险。在最糟糕的情况下，黑客可能获取对全国范围内部署的所有安全设备的访问权。

TSG 的能力

TSG 具备典型的多协议深度包检测与封锁能力，同时还具有令人意外的限速、注入、跟踪与攻防功能。

镜像模式与在线模式

TSG 与 Ether Fabric 可以以旁路（“镜像”或“被动”）模式部署，也可以以内联（可阻断流量或“主动”）模式部署。

p.37

Geedge 系统可在两种主要模式下部署——镜像与在线——以帮助控制互联网。在镜像模式下（文档中有时称为“被动”），数据通过网络 TAP 被镜像到 Geedge 设备。具体而言，该网络 TAP 是一种光旁路开关。数据包无需等待处理即可继续前往目的地。在此模式下，即便 Geedge 系统发生故障，互联网仍可继续运作。该模式的优势在于不会因处理延迟或拥塞而增加网络时延。在镜像模式下，客户无法阻止特定流量通过，不得不依赖数据包注入来阻断连接。在线模式（文档中也称为“主动”模式）要求流量在继续前往目的地之前必须先通过 Geedge 设备……该模式的优势在于可以彻底阻止特定流量流经网络。通常，这是那些希望获得绝对控制的客户所选择的方案，但代价是可靠性与网络质量的下降。

将其与 2024 年巴基斯坦一位官员的说法对比：

但为了监控本地流量，新的防火墙将采用所谓的“内联网络”，其作用类似安检点，每个数据包都必须被检查，并被允许通过或被阻断——不同于仅观察并记录流量而不干预其流动的另一种机制。这位 ISP 官员说，使用内联网络“必然会降低网速”。

深度包检测

报告提到的协议包括 HTTP、DNS、电子邮件、TLS、QUIC 与 SIP。

可从 TLS 与 QUIC 中提取服务器名称指示（SNI）。（关于基于 QUIC SNI 的中国审查，参见《“Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China”》。）

p.20

使用 DPI，他们可以提取详细的指纹信息，包括 TLS 与 QUIC 的 SNI、DNS 查询以及电子邮件头。

若在客户端安装 MITM 证书，TLS 流量可被解密；否则 TSG 必须依赖对加密流量的分类启发式：

p.23

TSG 能通过两种主要方法分析传输层安全（TLS）流量。第一种方法是使用中间人（MITM）技术进行完全解密，这需要订户安装自签名的根 CA 证书。第二种方法采用 DPI 与机器学习技术，从加密流量中提取元数据。后者更常用，因为它对互联网用户不可见，从而无需用户安装 CA 证书或配置任何代理设置。……负责实施 TLS MITM 攻击的组件被称为 Tiangou Frontend Engine（TFE）。

流量限速

p.25

TSG 集成了流量整形能力，能够对特定服务的流量进行优先级分配或限速，从而在不直接封锁的情况下降低服务质量。这可以通过直接的流量整形来实现，也可以通过应用差分服务代码点（DSCP）标记来实现，后者是限制或优先处理流量的行业标准。

注入与修改

TSG 能够注入与修改流量。它既可以用于封锁目的，也可以用于以恶意软件感染用户，或诱使其对目标发动 DDoS 攻击，类似于“大炮”（Great Cannon）。

p.23

TSG 还能通过诸如伪造重定向响应、修改头部、注入脚本、替换文本与覆盖响应体等技术，实时修改 HTTP 会话。

p.26

TSG 配备了在线注入能力，允许在通过网络传输的文件中插入恶意代码。Geedge Networks 明确表示该功能旨在在互联网流量经过 TSG 系统时插入恶意软件。 TSG 的在线注入能力系统允许对特定用户进行精细化定向，可对多种文件格式进行“即时”修改，包括 HTML、CSS 与 JavaScript，以及 Android APK、Windows EXE、macOS DMG 镜像与 Linux RPM 包。此外，TSG 还能修改多种图像格式（如 JPG、GIF、PNG 与 SVG）以及各种归档格式（如 ZIP 与 RAR），以及办公文档、PDF、JSON 与 XML 文件。Cyber Narrator 还提供了分析功能，能够识别最合适的劫持 URL 以感染特定个体。例如，它可以针对那些未使用 TLS 的、某人的高频访问网站。

p.27

在泄露数据中识别出的 Geedge Networks 最令人困惑的产品之一是 DLL 主动防御（DLL Active Defence），这种产品通常可以在网络犯罪黑市中见到。乍看之下，它似乎是一个用于防御 DDoS 攻击的系统；然而更仔细的检视表明，它实际上是一个针对被视为政治上不受欢迎的网站与其他互联网服务发动 DDoS 攻击的平台。这看起来是 Geedge 自己实现的中国“大炮”，正如 2015 年 Citizen Lab 报告所描述的那样。13 DLL 通过利用互联网扫描来识别流量放大点（例如递归 DNS 服务器），这些放大点可作为反射式拒绝服务攻击的发射台。它使用 TSG 的在线注入能力，有效地“招募”不知情的用户计算机参与攻击，从而形成一个僵尸网络。这标志着首次有网络安全公司向客户提供本质上是“肉鸡租用”（booter）式的 DDoS 攻击服务。

将网络流量归因到真实身份

p.25

Sanity Directory（SAN）或用户信誉流量管理系统是一种订户感知系统，旨在将 TSG 与 ISP 现有的信令与 AAA（认证、授权与计费）协议（包括 RADIUS、3GPP 与 CGNAT）无缝集成。该集成有助于将流量流归因到真实身份。

p.49

Geedge 的 Sanity Directory 组件的核心特性之一是将流量归因到特定的 SIM 卡。这不仅使大规模监控成为可能，也使在巴基斯坦和 Geedge 经营的其他国家对特定个人进行高度定向的微观监控成为可能。

识别与封锁翻墙工具

Geedge 购买了 VPN 账户，并运营一个安装了 VPN 应用的移动设备集群，以研究其网络行为：

p.24

TSG 还采用 DPI 全面识别与 VPN 与翻墙工具相关的协议，如 OpenVPN 与 WireGuard。随后，它允许客户与 Geedge Networks 合作制定规则集以封锁特定服务提供商；Geedge 运营一个移动设备农场，在受控环境中安装并运行 VPN 应用。

p.63

为了创建这些封锁规则，Geedge Networks 使用逆向工程，采用静态与动态分析。静态分析涉及反编译应用源代码以找到返回服务器列表的 API，从而对其进行封锁。动态分析则是在运行 VPN 应用的同时分析其网络流量，以识别可用于封锁的模式。泄露证据显示，Geedge Networks 与流行的 VPN 提供商保持付费账户，用于分析并封锁其应用。TSG 硬件还可以识别流行的 VPN 协议，如 IPSec、OpenVPN 与 WireGuard。

有一个名为 AppSketch 的应用网络指纹数据库，包含大量具体应用（如各家 VPN 服务）的指纹。见上图截图。

关于收集 AppSketch 指纹的脚注 10 提到了我们之前讨论过的 SAPP（#471）与 Maat（#444）等技术。

为了提取这些（AppSketch）指纹，Geedge 与 Mesalab 的学生使用了他们称为 tcpdump_mesa 的开源工具 tcpdump 的修改版。随后，这些指纹被转化为规则集，使用四种 DPI 系统之一：SAPP（Stream Analyze Process Platform，一种 C 语言的数据包解析与注入库）；Stellar（一个比 SAPP 抽象层更高的有状态防火墙插件平台）；或 Maat（一个声明式系统）。与 SAPP 与 Stellar 不同，Maat 在开发新规则时不需要编程知识。Maat 能匹配常见的连接指纹，包括 IP 地址、域名、TLS SNI、JA3/JA4 指纹——这些都以 JSON 文件形式指定。通过使用 Redis 数据库，Maat 规则会在 TSG 集群的各节点之间进行同步，从而确保规则应用的一致性。

一个有趣且令人意外的能力是：通过观察既往已知 VPN 用户的行为来发现新的 VPN 端点。（让人联想到 MESA 成员参与的《“Identifying VPN Servers through Graph-Represented Behaviors”》。）

p.9

此外，Geedge Networks 的产品能够将特定个人识别为已知的 VPN 用户。一旦这些已知的翻墙工具用户转向尚未被封锁的新服务提供商，Geedge Networks 就可以观察其流量，并利用其留下的“轨迹”来识别未来要封锁的新 VPN。

p.26

进一步地，系统可以将个体订户识别为已知的 VPN 用户，随后跟踪他们的互联网使用，并将任何未来未知的高带宽流量归类为可疑。这种个体化的分类可能导致在互联网用户切换到新的 VPN 提供商时，识别并封锁先前尚未识别的服务，从而不仅牵连该用户，也牵连使用该服务的所有其他用户。

无法识别的高带宽流量也可能用于指导封锁：

p.25

即便 TSG 无法识别用户活动所对应的具体应用或服务，它也可以将任何异常的大流量标记为可疑。此后，系统可被配置为在预设时间（例如 24 小时）后封锁被标记的流量。该做法与对 GFW 的观测相对应：即便无法识别具体流量类型，GFW 也会在一定持续时间后封锁任何高带宽的加密流量9。

报告（p.63）讨论了 Tor 的桥接、Snowflake 与 WebTunnel。报告暗示 Geedge 具备枚举 Tor 桥的办法，但尚不确定是内部能力还是外包所得。Cyber Narrator 的一张宣传截图包含“Snowflake”字样。泄露材料包含 MESA 学生关于 WebTunnel 的研究，但当时尚未发现封锁技术。

Geedge 有一个专门用于枚举 Psiphon 端点的工具，称为 Psiphon3-SLOK。它与 2024 年 5 月 Geedge 进入缅甸时在当地观察到的 Psiphon 连接变化相吻合。

p.64

根据泄露数据，Geedge Networks 似乎尝试通过开发一款名为 Psiphon3-SLOK 的内部工具来绕过这一防护措施。我们与 Psiphon 团队交流得知，2024 年 5 月下旬，来自缅甸的用户数量急剧上升，客户端选择服务器的方式也发生了变化，这与服务器枚举与定向封锁的情况一致。此时段恰逢 Geedge 系统在缅甸部署。

对客户网络的远程访问

存储在 TSG Galaxy 中的客户数据竟然对 MESA 的学生与研究人员可访问，并可能被用于研究。

p.21

本研究的一个重要发现是：在政府客户现场收集到并存储于 TSG Galaxy 的全部互联网用户数据似乎对 Geedge Networks 的员工可用。数据还显示，真实客户数据的快照有时会被分享给与 Geedge Networks 关系密切的中国科学院 Mesalab。数据表明，Mesalab 的工程专业学生曾使用真实世界的客户信息开展研究，旨在更好地理解并阻断互联网审查规避。

p.24

此外，Geedge Networks 的员工似乎具备在其办公室内部创建一个 Wi-Fi 网络的能力，使任何设备都能远程连接到客户网络。该功能使他们能够在真实世界场景中验证封锁机制是否有效运行。

向中国境外国家的部署

报告对 Geedge 在哈萨克斯坦、埃塞俄比亚、巴基斯坦与缅甸的部署给出了详细的总结。关于巴基斯坦与缅甸，还有更详细的信息见 Shadows of Control 与 Silk Road of Surveillance。

部署 Geedge 设备涉及 Geedge 员工亲赴目标 ISP 的场所，与该 ISP 人员直接合作。（顺带一提，这一事实揭穿了像缅甸的 Frontiir 这样的 ISP 的谎言：当被问及时他们否认与 Geedge 有关，p.53。）

p.35

在一个新的国家或省份启动部署时，Geedge 员工会前往客户所在地，在政府与当地 ISP 所拥有的场所内安装硬件。当地 ISP 是 Geedge 系统搭建不可或缺的一环。ISP 需要在安装期间向 Geedge 员工开放其场所，并提供网络方案，说明 Geedge 硬件如何集成进 ISP 现有系统。用于采集与存储海量数据的 Geedge 硬件被安置在各个 ISP 的数据中心内。

在泄露材料中，各国以代号标识。除一个代号（A24）外，其余均已对应到具体国家。多数情况下，代号由国家名称的首字母与两位年份组成（显然并不总与首次部署年份一致）。

哈萨克斯坦（代号 K18、K24）

Geedge 成立于 2018 年。泄露材料显示，哈萨克斯坦政府是其第一位客户，始于 2019 年。报告将 Geedge 的部署与该国推动全国范围 TLS MITM 的愿景联系起来，这一点我们曾在 #6、#56 与 #339 中见到。

p.42

Geedge 的产品 Tiangou Secure Gateway（TSG）能够实施类似政府颁发根证书的攻击，这或许是 Geedge 最初接触哈萨克斯坦政府时的卖点之一。一张日期为 2020 年 10 月 16 日的图片列出了一个国家中心及其他 17 个城市的 IP 地址，这些地点运行着三种 Geedge 产品：Bifang（集中管理）、Galaxy（TSG-Galaxy 的早期名称）与 Nezha（Network Zodiac 的旧称）。Geedge 的一份不完整的网络规划文档开始于 2020 年 9 月记录与某哈萨克国家中心相关的事件。该日志记录至 2022 年 10 月，并包含一张表，列出与项目相关的修订情况，包括日期、版本号、修改内容以及负责修改的作者。

埃塞俄比亚（代号 E21）

Geedge 于 2021 年在埃塞俄比亚开展工作。

本节直接点名了郑超：

p.45

一条 2022 年 12 月的日志条目记载：Geedge CTO 郑超批准了位于亚的斯亚贝巴的两座 Safaricom 区域数据中心的相关工作。

我们已提到，TSG 可在镜像模式或在线模式下运行。报告声称，从镜像切换到在线可能先于一次断网，并将其与2023 年 2 月的社交媒体封锁联系起来。

p.46

Geedge 的修订日志显示，从镜像模式切换到在线模式与政府准备实施断网之间存在相关性。例如，切换到在线配置可能表明断网即将到来；从总体上看，镜像模式更优化于监控，而在线模式更适合断网。日志总计显示在埃塞俄比亚发生了 18 次切换为在线模式的变更，其中两次发生在 2023 年 2 月断网之前、位于 Safaricom 数据中心。

巴基斯坦（代号 P19）

Geedge 于 2023 年进入巴基斯坦，同年 Sandvine 退出该国。在 Shadows of Control 报告中，国际特赦组织将 Geedge 运营的防火墙称为 “WMS 2.0”（网络管理/监控系统 2.0），以与其所取代的早期版本 WMS 区分。

Geedge 在巴基斯坦的存在与此前关于中国参与国家防火墙的报道相一致；巴基斯坦官员的表述与 Geedge 的 TSG 已知能力相吻合：

p.48

接受半岛电视台采访的一位巴基斯坦资深 ISP 高管所使用的语言与 Geedge 的营销材料高度契合。51 这位未具名高管称，新的 WMS 不仅部署在国家互联网关口，也部署在移动服务提供商与 ISP 的本地数据中心。[52] 由于之前的系统只能监控出入境的内容，巴基斯坦无法审查由 Netflix 与 Meta 等运行的本地缓存 CDN 所托管的内容。对比 WMS 1.0 与 WMS 2.0，这位高管表示：“与 Sandvine 系统不同，新的基于 DPI 的系统现在能够监控本地互联网流量”，它使用“内联网络”，这也更可能降低用户的上网速度。该高管还指出，这项中国（Geedge）技术提供了在“细粒度层面”管理应用与网站的能力，特性优于 Sandvine。

Geedge 的 Sanity Directory 具备将网络行为归因到特定 SIM 卡的能力。在巴基斯坦，SIM 卡又与现实身份相绑定：

p.49

……自 2015 年起，该国每张发放给移动用户的新 SIM 卡都必须注册到特定用户名下，并与通过国家数据库与登记局（NADRA）登记的生物特征（包括指纹）绑定。人们需要 NADRA 档案才能获得医疗、银行与教育等基本服务。NADRA 档案还与其他数据库相连，如选民登记与税务记录，合在一起对每个公民形成一份全面记录。[57] Geedge 的 Sanity Directory 组件的核心功能之一，就是将流量归因到特定 SIM 卡。

缅甸（代号 M22）

缅甸之所以重要，是因为这是 Geedge 首次在国外的工作被公开知晓，当时由 Justice for Myanmar 报道。

除了此前报道过的 Frontiir 之外，泄露材料还列出了缅甸所有 ISP 的数据中心。此前，当被询问时，Frontiir 曾虚假否认参与任何监控项目。

p.53

该规划文档列出了该国所有 ISP（无论国营或私营）所在的数据中心。“四大” ISP（MyTel、Ooredoo、MPT 与 ATOM）在列，同时也列出了较小的服务商，如 Frontiir、Global Technology Group、Golden TMH Telecom、Stream Net、IM-Net、Myanmar Broadband Telecom、Myanmar Telecommunications Network Public Company Limited、Campana 与中国联通。文档还包含所有 ISP 的链路测试报告。这些报告提供了 2024 年不同日期进行的网站连通性测试信息。测试目标似乎是评估各 ISP 网络上的审查效果。

Frontiir 的一位发言人否认其曾“在其网络上构建、规划或设计过任何与监控相关的内容”。然而，泄露文档表明，Geedge 硬件安装在缅甸所有 ISP 的机房中，包括 Frontiir。

有关政府希望封锁的应用与 VPN 列表的信息：

p.54

泄露文档还包含关于封锁 VPN、Tor（尤其是由 Tor 驱动的移动应用 Orbot）与 Psiphon 的详细信息。与埃塞俄比亚或哈萨克斯坦等其他客户国家提供的 VPN 封锁清单相比，缅甸的“欲封锁 VPN 清单”更长。文档记录了制定“高优先级应用”封锁规则的过程，其中包含 55 款应用，包括消息应用 Signal 与 WhatsApp。

代号 A24

有一位 Geedge 客户仅以代号 A24 为人所知。在泄露发生时，这段业务关系显然还处于早期阶段。

p.55

虽然泄露文档包含与本报告中所列已知客户国家相关的具体地点和/或 ISP，但与 A24 相关的数据并不包含这些可用于识别客户的信息。关于 A24 身份的唯一线索只有首字母 A 与年份 2024。除此之外，信息显示，截至泄露发生时，A24 与 Geedge 的关系还处在早期。为向客户澄清两种模式的差异，进行了两次 Geedge 设备的概念验证部署：一次为镜像模式，一次为在线模式。

中国的区域性防火墙

报告显示 Geedge 参与了中国的区域（省级）防火墙建设，尤其是在新疆。

p.9

除与国际政府客户合作外，本研究还提供了证据，显示中国正在出现一种补充国家级“防火长城”的省级防火墙模式。Geedge Networks 正与中国多个地方政府合作构建省级防火墙，其审查规则可能因地区而异。InterSecLab 已识别出在新疆、福建与江苏的中国区域性省级防火墙项目。

新疆（代号 J24）

新疆的代号为 J24。泄露文档直接指出：新疆的区域防火墙将作为中国全国部署的样板。

p.56

泄露材料包含 2024 年 6 月 22 日在中国科学院新疆分中心的一次讲话记录。该讲话的笔记（很可能由 Geedge 员工所记）写道，Geedge 的项目“旨在将区域中心打造成反恐的先锋力量，尤其是在翻墙压制方面”。笔记提到，“国家（防火墙）正从集中式向分布式演进”，而新疆区域中心旨在“成为可复制或可借鉴的省级（防火墙）建设样板”。

与大多数其他 Geedge 部署相似，新疆的部署遵循一个由“中央指挥中心”连接“运营商”数据中心的结构。

p.57

与更早的项目相比，J24 规模更为庞大，且不再通过 ISP 作为终端用户来运转。相反，它遵循与 Geedge 在国外客户地区类似的结构：由一个“国家中心”（在新疆，Geedge 将其称为中央指挥中心）来统筹分布式的区域中心（Geedge 称之为运营商中心）。在 J24 下，这些运营商中心位于中国电信、中国移动、中国广电与中国联通的机房中。与所谓国家中心相似，中央指挥中心可以远程管理部署在运营商站点的监控设备。据一份文档显示，这些 ISP 的设施中共有 17 个运营商中心。

新疆部署的需求体现出强烈且侵入性的监控，这与我们所了解的该地区压制状况相一致。

p.57

在题为 “CBNR-J24 需求组织” 的文档中，Geedge 概述了要在 Cyber Narrator 中为新疆部署加入的一系列功能。Geedge Networks 希望在 Cyber Narrator 中支持对用户互联网行为、生活方式模式与关系的归纳与分析功能。他们还希望加入根据目标交流对象构建关系图谱的能力，并按照用户所用应用或访问网站对人群进行分组。未来开发需求还提到，加入检查连接至特定移动基站的用户能力，以通过这些基站进行位置三角定位，并检测在某一地区出现的大量人群聚集。此外，项目计划加入创建地理围栏的能力，当特定个体进入指定区域时触发告警。还强调了查询历史位置信息以追踪过往活动轨迹的功能。Geedge 希望能够标记频繁更换 SIM 卡、拨打国际电话或使用翻墙工具与境外社交媒体应用的个人。 J24 项目还包括面向特定群体的功能。这些功能将允许在地图上显示被监控群体的地理分布，并检测群体成员在特定地点的异常聚集情况。这样可使操作员追踪并预判大型抗议与示威的形成。

福建、江苏与其他省份

有一些关于 Geedge 在福建与江苏开展工作的文档，但相关信息少于其他地区。

p.58

文档显示，Geedge Networks 于 2022 年在福建开展了类似的省级防火墙试点项目——福建是位于台湾海峡对岸的一个省份。然而，与其他部署相比，关于该项目的信息相对有限。泄露文档中，该试点没有代号，仅被称为“福建项目”。

p.59

若干文档还提到江苏这个中国东部沿海省份。Geedge 与当地机关（江苏省公安厅，JPSB）合作的动机据称是打击网络诈骗。沟通记录显示，JPSB 对允许 Geedge 构建一套大数据集群持谨慎态度，更倾向于让 Geedge 将其工具部署在现有基础设施上。一个名为“江苏南京”的初始测试环境于 2023 年 2 月投入运行，“江苏反诈项目”似乎在 2024 年 3 月 15 日转入生产模式。

6. 源码文件分析

此次泄漏文件的源代码的部分还没有被仔细分析。 该泄漏事件意义重大且深远，由于资料体量庞大，GFW Report 将在当前页面，以及 Net4People 上持续更新我们的分析与发现。

这里是该段落的中文翻译，保留了原始的 Markdown 格式：

6.1 MESA Git 贡献者分析

2025 年 9 月 26 日，动态网络技术公司 (DIT) 发布了一个网站，用于可视化 MESA 实验室 Git 仓库的贡献者及其贡献详情：

https://mesaauthor.dit-inc.us/

7. 致谢

本项工作离不开多个组织和研究团体的贡献。我们特别感谢 InterSecLab、国际特赦组织 (Amnesty International)、Justice for Myanmar、环球邮报 (The Globe and Mail)、Der Standard 以及 Follow the Money 所做出的深入且严谨的工作。作为研究联盟的一部分，InterSecLab 在过去九个月中持续对 600 GB 的泄露数据进行索引、翻译、分析、解读和总结。这一努力对于揭示此次泄露的重要意义起到了不可替代的作用。这些组织的调查、报道和分析为未来的工作提供了重要的背景和洞见。

需要澄清的是，GFW Report从未对这些组织形成的报告分析作出过任何贡献。

8. 联系或加入我们

本报告最初发布于 GFW Report。我们也将在 Net4People 上积极更新我们的分析与发现。

我们鼓励您就此话题公开或私下分享问题、评论、分析或更多证据。我们的私人联系方式可以在 GFW Report 网站页脚找到。

2025年8月20日中国防火长城GFW对443端口实施无条件封禁的分析

Wed, 20 Aug 2025 00:00:00 +0000

1. 引言

2025 年 8 月 20 日北京时间（UTC+8）约 00:34 至 01:48 间，中国国家防火墙（GFW）出现异常行为：对所有指向 TCP 443 端口的连接无条件注入伪造的 TCP RST+ACK 包，导致连接中断。该事件引发了中国与世界其他地区之间的大规模互联网连通性故障（来源1 与来源2）。

本报告记录了我们对这一短暂但广泛的封禁事件的测量与分析。主要发现如下：

无条件的 RST+ACK 注入仅发生在 TCP 443 端口，未见于其他常见端口（如 22、80、8443）。
该无条件注入同时扰乱了出入境中国双方向的连接，但触发机制不对称：从中国境内向境外发起的连接，客户端的 SYN 包与服务器的 SYN+ACK 包各自触发三个 RST+ACK包；从境外向中国境内发起的连接，只有服务器返回的 SYN+ACK 会触发 RST+ACK，客户端发送的 SYN 不会触发注入。
负责注入的设备指纹与已知 GFW 设备不匹配，因此此次事件要么由新的 GFW 设备造成，要么是由已知设备以一种新的或误配置的状态运行造成的。

需注意的是，本次事件持续时间较短（约 74 分钟），对我们的测量和分析带来一定限制。我们鼓励社区成员分享各自的观测与分析，以共同完善对该事件的理解。

2. 封禁的触发

我们首先从中国境内（AS45090，腾讯云，北京）与多个境外测量点同时发起探测以确认封禁。

2.1 境内发起（inside-out）

我们使用如下命令尝试与 $NON_CN_IP 建立 TCP 三次握手：

nc -vn $NON_CN_IP 443

同时使用 tcpdump 抓包：

tcpdump -n host $NON_CN_IP

观测显示：客户端发送的 SYN 包会触发三连发伪造 RST+ACK，其相对序列号均为 0，TCP 窗口大小递增为 1980、1981、1982。服务器返回的 SYN+ACK 同样会触发三连发 RST+ACK，其相对序列号为 1，TCP 窗口大小递增为 3293、3294、3295。

sudo tcpdump -n host $NON_CN_IP

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:31:07.153262 IP $CN_IP.52596 > $NON_CN_IP.443: Flags [S], seq 3193349615, win 64240, options [mss 1460,sackOK,TS val 318868316 ecr 0,nop,wscale 7], length 0
01:31:07.159991 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 3193349616, win 1980, length 0
01:31:07.159991 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 1, win 1981, length 0
01:31:07.160021 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 1, win 1982, length 0
01:31:07.274422 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [S.], seq 2837031664, ack 3193349616, win 65160, options [mss 1424,sackOK,TS val 80839422 ecr 318868316,nop,wscale 7], length 0
01:31:07.274442 IP $CN_IP.52596 > $NON_CN_IP.443: Flags [R], seq 3193349616, win 0, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3295, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3293, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3294, length 0

2.2 境外发起（outside-in）

从境外同样可以触发 RST+ACK 注入。此处 $CN_IP 为 baidu.com 的某个 IP:

11:44:41.194853 IP (tos 0x0, ttl 64, id 48747, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.162.34500 > $CN_IP.443: Flags [S], cksum 0x418a (incorrect -> 0x252a), seq 3455861170, win 64240, options [mss 1460,sackOK,TS val 134891089 ecr 0,nop,wscale 7], length 0
11:44:41.440817 IP (tos 0x0, ttl 46, id 48747, offset 0, flags [DF], proto TCP (6), length 60)
    $CN_IP.443 > 192.168.0.162.34500: Flags [S.], cksum 0xd4a2 (correct), seq 1580408478, ack 3455861171, win 8192, options [mss 1452,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 5], length 0
11:44:41.440817 IP (tos 0x0, ttl 96, id 40305, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x515b (correct), seq 1, ack 1, win 2072, length 0
11:44:41.440817 IP (tos 0x0, ttl 97, id 39808, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x515a (correct), seq 1, ack 1, win 2073, length 0
11:44:41.440817 IP (tos 0x0, ttl 98, id 38891, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x5159 (correct), seq 1, ack 1, win 2074, length 0
11:44:41.440901 IP (tos 0x0, ttl 64, id 48748, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.0.162.34500 > $CN_IP.443: Flags [.], cksum 0x4176 (incorrect -> 0x5781), seq 1, ack 1, win 502, length 0

境外客户端仅收到三份 RST+ACK（而非六份）。相对序列号为 1 表明触发源是中国侧服务器返回的 SYN+ACK，而非客户端的 SYN。事实上，当我们向与 $CN_IP 同一 /24 子网的、未开放目标端口的境内 IP 发送 SYN（因此对端不返回 SYN+ACK）时，无法触发封禁。

2.3 受影响的端口

RST+ACK 注入被确认特定于 TCP 443 端口。我们从中国境内（AS45090，腾讯云，北京）的机器对某境外 IP 进行了部分端口扫描，确认包括 1–72、22、80、444、8443 在内的其他常见端口未受影响，未收到 RST。

nping -4 -c 0 --tcp-connect $NON_CN_IP -p 1-65535

我们亦对 1–65535 端口进行了全量扫描，但当我们在 2025-08-20 01:48 CST 运行时，封禁已结束，无法再触发：

sudo nmap -sS -p- $NON_CN_IP -oN scan_results.txt -T4 --min-rate 10000 -Pn

3. 归因与设备指纹

中国的 GFW 并非单一设备，而是由多类执行审查的网络设备构成的复杂系统。既有研究指出，负责基于 HTTP Host 与 TLS SNI 的过滤组件在注入 TCP RST 时具有独特的报文级指纹。本节旨在识别本次异常行为的具体责任组件。

为指纹比对，在这起事件结束后，我们从境内测量点向曾触发无条件 RST 的目标 IP 发送探测。复用相同目的 IP 使探测报文更可能沿相同网络路径并与同一组审查中间盒交互，从而有利于一致的指纹分析。

我们的探测结果表明：无任何捕获到的报文指纹能与事件期间的特征完全吻合——尤其是那些呈现递增关系的字段。

鉴于本次无条件注入的三份 RST+ACK 都带有 IP 标志 DF（Don’t Fragment，不可分片），它们与 Niere 等人识别的 MB-1（见图 4）相似，但并不相同；也与 Wu 等人识别的 GFW (II)（见表 4）相似，但并不相同。

然而存在关键差异：已知的中间盒注入器会发送三份完全相同的 RST+ACK；而本事件中观测到的报文在若干字段上呈明显递增。这提示该事件要么由此前未被编目的 GFW 设备引起，要么是已知设备处于一种新颖或误配置的工作状态。

3.1 GFW 无条件 `RST+ACK` 报文的指纹

该无条件 RST+ACK 以三连发形式出现，且其 IP TTL 与 TCP 窗口大小呈递增关系。受限于样本，我们未能确定其 IP ID 的稳定特征。

IP 标志	IP ID	IP TTL	TCP 相对序列号	TCP 标志	TCP 窗口大小
不可分片（DF）	40305 (0x9D71)	96	1	RST+ACK	2072
不可分片（DF）	39808 (0x9B80)	97	1	RST+ACK	2073
不可分片（DF）	38891 (0x97E3)	98	1	RST+ACK	2074

表 1：无条件注入的 TCP RST 报文特征

3.2 GFW 基于 HTTP Host 的审查设备之 RST 指纹

curl --resolve youtube.com:80:$NON_CN_IP http://youtube.com

sudo tcpdump -v port 80

tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:27:09.790274 IP (tos 0x0, ttl 64, id 12103, offset 0, flags [DF], proto TCP (6), length 60)
    $CN_IP.51506 > $NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [S], cksum 0x630f (correct), seq 3187873750, win 64240, options [mss 1460,sackOK,TS val 329430953 ecr 0,nop,wscale 7], length 0
04:27:09.919296 IP (tos 0x68, ttl 251, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [S.], cksum 0xaf88 (correct), seq 155578285, ack 3187873751, win 65160, options [mss 1424,sackOK,TS val 2237542832 ecr 329430953,nop,wscale 7], length 0
04:27:09.919331 IP (tos 0x0, ttl 64, id 12104, offset 0, flags [DF], proto TCP (6), length 52)
    $CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [.], cksum 0xda42 (correct), ack 1, win 502, options [nop,nop,TS val 329431082 ecr 2237542832], length 0
04:27:09.919414 IP (tos 0x0, ttl 64, id 12105, offset 0, flags [DF], proto TCP (6), length 127)
    $CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [P.], cksum 0x0926 (correct), seq 1:76, ack 1, win 502, options [nop,nop,TS val 329431082 ecr 2237542832], length 75: HTTP, length: 75
        GET / HTTP/1.1
        Host: youtube.com
        User-Agent: curl/7.81.0
        Accept: */*

04:27:09.923159 IP (tos 0x68, ttl 251, id 31725, offset 0, flags [none], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R], cksum 0xc7c6 (correct), seq 155578286, win 42571, length 0
04:27:09.924494 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:09.924494 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:09.924510 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:10.048400 IP (tos 0x68, ttl 251, id 34753, offset 0, flags [DF], proto TCP (6), length 52)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [.], cksum 0xd96f (correct), ack 76, win 509, options [nop,nop,TS val 2237542961 ecr 329431082], length 0
04:27:10.048426 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [R], cksum 0x90e0 (correct), seq 3187873826, win 0, length 0

3.3 GFW 基于 TLS SNI 的审查设备之 RST 指纹

curl --resolve youtube.com:443:$NON_CN_IP https://youtube.com

sudo tcpdump -v port 443

tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:25:15.234561 IP (tos 0x0, ttl 64, id 59308, offset 0, flags [DF], proto TCP (6), length 60)                                                                                    [0/966]
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [S], cksum 0x579d (correct), seq 2971216783, win 64240, options [mss 1460,sackOK,TS val 329316397 ecr 0,nop,wscale 7], length 0
04:25:15.365226 IP (tos 0x68, ttl 251, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [S.], cksum 0x4c87 (correct), seq 2839767305, ack 2971216784, win 65160, options [mss 1424,sackOK,TS val 91287507 ecr 329316397,nop,wscale 7], length 0
04:25:15.365257 IP (tos 0x0, ttl 64, id 59309, offset 0, flags [DF], proto TCP (6), length 52)
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [.], cksum 0x773f (correct), ack 1, win 502, options [nop,nop,TS val 329316528 ecr 91287507], length 0
04:25:15.428628 IP (tos 0x0, ttl 64, id 59310, offset 0, flags [DF], proto TCP (6), length 569)
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [P.], cksum 0x9a41 (correct), seq 1:518, ack 1, win 502, options [nop,nop,TS val 329316591
ecr 91287507], length 517
04:25:15.433547 IP (tos 0x68, ttl 251, id 47980, offset 0, flags [none], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R], cksum 0x7ed4 (correct), seq 2839767306, win 4547, length 0
04:25:15.434682 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.434682 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.434709 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.435139 IP (tos 0x68, ttl 251, id 42431, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xaac5 (correct), seq 1, ack 518, win 1811, length 0
04:25:15.559257 IP (tos 0x68, ttl 251, id 29047, offset 0, flags [DF], proto TCP (6), length 52)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [.], cksum 0x7435 (correct), ack 518, win 506, options [nop,nop,TS val 91287701 ecr 3293165
91], length 0
04:25:15.559269 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [R], cksum 0xc436 (correct), seq 2971217301, win 0, length 0

4. 结束时间

无条件 RST 注入在 2025-08-20 01:48（UTC+8）之前停止，事件持续约 74 分钟（00:34–01:48，UTC+8）。

sudo nmap -sS -p- $NON_CN_IP -oN scan_results.txt -T4 --min-rate 10000 -Pn

Starting Nmap 7.80 ( https://nmap.org ) at 2025-08-20 01:48 CST
Nmap scan report for $NON_CN_IP.deploy.static.akamaitechnologies.com ($NON_CN_IP)
Host is up.
All 65535 scanned ports on $NON_CN_IP.deploy.static.akamaitechnologies.com ($NON_CN_IP) are filtered

5. 感谢

我们感谢许多用户和读者向我们及时的汇报审查事件。特别是这次审查时间持续时间很短，如果没有他们的及时通知，我们不可能在短时间内进行测量。我们还感谢Eric Wustrow提供的部分由国外发往国内的测量数据。

6. 联系我们

这篇报告首发于GFW Report。我们还在net4people同步更新了这篇报告。

我们鼓励您公开地或私下地分享与报告中的发现和假设相关的问题、评论或证据。我们私下的联系方式可见GFW Report的页脚。

Analysis of the GFW's Unconditional Port 443 Block on August 20, 2025

Wed, 20 Aug 2025 00:00:00 +0000

1. Introduction

Between approximately 00:34 and 01:48 (Beijing Time, UTC+8) on August 20, 2025, the Great Firewall of China (GFW) exhibited anomalous behavior by unconditionally injecting forged TCP RST+ACK packets to disrupt all connections on TCP port 443. This incident caused massive disruption of the Internet connections between China and the rest of the world (source1 and source2).

This report documents our measurements and analysis of this temporary, widespread blocking event. Our primary findings are:

The unconditional RST+ACK injections was on TCP port 443, but not on other common ports like 22, 80, 8443.
The unconditional RST+ACK injection disrupted connections both to and from China, but the trigger mechanism was asymmetrical. For traffic originating from inside China, the SYN packet from the client and the SYN+ACK packet could each trigger three injected RST+ACK packets. For traffic to inside China, only the server’s SYN+ACK response, not the client’s SYN packet, could trigger the RST+ACK packets.
The responsible device does not match the fingerprints of any known GFW devices, suggesting that the incident was caused by either a new GFW device or a known device operating in a novel or misconfigured state.

It is important to note that our analysis was limited by the short duration of the incident (approximately 74 minutes). We encourage others in the community to share their observations to build a more complete picture of this event.

2. Triggering the blocking

We first confirmed the blocking by sending probes from a vantage points inside of China (AS45090, Tencent Cloud, Beijing), and from multiple vantage points outside of China.

2.1 Inside-out triggering

In particular, we used the following command to try to establish a TCP handshake with a $NON_CN_IP:

nc -vn $NON_CN_IP 443
nc: connect to $NON_CN_IP port 443 (tcp) failed: Connection refused

We simultaneously used tcpdump to capture traffic:

tcpdump -n host $NON_CN_IP

It appears that the SYN packet triggered three forged RST+ACK packets, each with a relative sequence number 0, as well as incremental TCP window sizes of 1980, 1981, and 1982.

And the SYN+ACK packet sent by the server also triggered three RST+ACK packets, each with a relative sequence number 1, as well as incremental TCP window sizes of 3293, 3294, and 3295.

sudo tcpdump -n host $NON_CN_IP

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:31:07.153262 IP $CN_IP.52596 > $NON_CN_IP.443: Flags [S], seq 3193349615, win 64240, options [mss 1460,sackOK,TS val 318868316 ecr 0,nop,wscale 7], length 0
01:31:07.159991 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 3193349616, win 1980, length 0
01:31:07.159991 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 1, win 1981, length 0
01:31:07.160021 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 0, ack 1, win 1982, length 0
01:31:07.274422 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [S.], seq 2837031664, ack 3193349616, win 65160, options [mss 1424,sackOK,TS val 80839422 ecr 318868316,nop,wscale 7], length 0
01:31:07.274442 IP $CN_IP.52596 > $NON_CN_IP.443: Flags [R], seq 3193349616, win 0, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3295, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3293, length 0
01:31:07.278233 IP $NON_CN_IP.443 > $CN_IP.52596: Flags [R.], seq 1, ack 1, win 3294, length 0

2.2 Outside-in triggering

Similarly, the RST+ACK packets can be triggered from outside of China. The $CN_IP is an IP address of baidu.com:

11:44:41.194853 IP (tos 0x0, ttl 64, id 48747, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.0.162.34500 > $CN_IP.443: Flags [S], cksum 0x418a (incorrect -> 0x252a), seq 3455861170, win 64240, options [mss 1460,sackOK,TS val 134891089 ecr 0,nop,wscale 7], length 0
11:44:41.440817 IP (tos 0x0, ttl 46, id 48747, offset 0, flags [DF], proto TCP (6), length 60)
    $CN_IP.443 > 192.168.0.162.34500: Flags [S.], cksum 0xd4a2 (correct), seq 1580408478, ack 3455861171, win 8192, options [mss 1452,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 5], length 0
11:44:41.440817 IP (tos 0x0, ttl 96, id 40305, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x515b (correct), seq 1, ack 1, win 2072, length 0
11:44:41.440817 IP (tos 0x0, ttl 97, id 39808, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x515a (correct), seq 1, ack 1, win 2073, length 0
11:44:41.440817 IP (tos 0x0, ttl 98, id 38891, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.443 > 192.168.0.162.34500: Flags [R.], cksum 0x5159 (correct), seq 1, ack 1, win 2074, length 0
11:44:41.440901 IP (tos 0x0, ttl 64, id 48748, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.0.162.34500 > $CN_IP.443: Flags [.], cksum 0x4176 (incorrect -> 0x5781), seq 1, ack 1, win 502, length 0

The client outside of China received only three TCP RST+ACK packets, not six. The relative sequence number 1 suggests that the GFW was triggered by the SYN+ACK packet responded by the Chinese server, and the SYN packet didn’t trigger the blocking. Indeed, we couldn’t trigger the blocking when the sending SYN packets to a Chinese IP address within the same /24 subnet as $CN_IP which didn’t have an open port (and thus did not send any SYN+ACK packet back to the client.)

2.3 Affected ports

The RST+ACK injection was confirmed to be specific to TCP port 443. We conducted a partial port scan from a machine inside China (AS45090, Tencent Cloud, Beijing) to an external IP address. We confirmed that other common ports, including 1-72, 22, 80, 444, and 8443, were not affected and did not receive a TCP RST.

nping -4 -c 0 --tcp-connect $NON_CN_IP -p 1-65535

We also ran a scan to probe all ports from 1-65535, but by the time we ran it at 01:48 CST 2025-08-20, we could no longer trigger the blocking anymore:

sudo nmap -sS -p- $NON_CN_IP -oN scan_results.txt -T4 --min-rate 10000 -Pn

3. Attribution and Device Fingerprinting

The Great Firewall of China (GFW) is not a single entity but a complex system composed of various network devices that perform censorship. Previous research has established that different components, such as those responsible for HTTP Host-based and TLS SNI-based filtering, exhibit unique packet-level fingerprints when injecting TCP RST packets. The goal of this analysis was to identify which specific GFW component was responsible for the anomalous behavior observed during the incident.

To fingerprint the responsible device, after the incident had concluded, we sent probes from the vantage point in China to the IP address that triggered the unconditional RSTs. We used the same destination IP address so that our probe packets would be more likely to traverse the same network path and interact with the same set of censorship middleboxes, allowing for a consistent fingerprint analysis.

Our analysis of the probe results revealed that no captured packet fingerprint exactly matched the characteristics observed during the incident—specifically.

Since the unconditionally injection contain three RST+ACK packets with the IP Flag DF (Don't Fragment) on, they are similar, but not identical, to MB-1 identified by Niere et al. (see Figure 4); and they are also similar to, but not identical to, GFW (II) identified by Wu et al. (see Table 4).

However, a key difference exists: the known middlebox injector sends three identical TCP RST+ACK packets. In contrast, the packets observed during this incident contained fields that were clearly incremental, not identical. This discrepancy suggests that the incident was caused by either a previously uncatalogued GFW device or a known device operating in a novel or misconfigured state.

3.1 Fingerprints of GFW’s Unconditional RST+ACK packets

The unconditional RST+ACK packets comes in three packets, with an incrementally increasing IP TTL and an incrementally increasing TCP window size. We limited data, we were not able to identify the IP ID of it.

IP Flag	IP ID	IP TTL	TCP Relative Sequence Number	TCP Flags	TCP Window Size
Don’t Fragment	40305 (0x9D71)	96	1	RST+ACK	2072
Don’t Fragment	39808 (0x9B80)	97	1	RST+ACK	2073
Don’t Fragment	38891 (0x97E3)	98	1	RST+ACK	2074

Table 1: Characteristics of Unconditionally Injected TCP RST Packets

3.2 Fingerprints of the RST packets by GFW’s HTTP Host-based censorship devices

curl --resolve youtube.com:80:$NON_CN_IP http://youtube.com

sudo tcpdump -v port 80

tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:27:09.790274 IP (tos 0x0, ttl 64, id 12103, offset 0, flags [DF], proto TCP (6), length 60)
    $CN_IP.51506 > $NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [S], cksum 0x630f (correct), seq 3187873750, win 64240, options [mss 1460,sackOK,TS val 329430953 ecr 0,nop,wscale 7], length 0
04:27:09.919296 IP (tos 0x68, ttl 251, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [S.], cksum 0xaf88 (correct), seq 155578285, ack 3187873751, win 65160, options [mss 1424,sackOK,TS val 2237542832 ecr 329430953,nop,wscale 7], length 0
04:27:09.919331 IP (tos 0x0, ttl 64, id 12104, offset 0, flags [DF], proto TCP (6), length 52)
    $CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [.], cksum 0xda42 (correct), ack 1, win 502, options [nop,nop,TS val 329431082 ecr 2237542832], length 0
04:27:09.919414 IP (tos 0x0, ttl 64, id 12105, offset 0, flags [DF], proto TCP (6), length 127)
    $CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [P.], cksum 0x0926 (correct), seq 1:76, ack 1, win 502, options [nop,nop,TS val 329431082 ecr 2237542832], length 75: HTTP, length: 75
        GET / HTTP/1.1
        Host: youtube.com
        User-Agent: curl/7.81.0
        Accept: */*

04:27:09.923159 IP (tos 0x68, ttl 251, id 31725, offset 0, flags [none], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R], cksum 0xc7c6 (correct), seq 155578286, win 42571, length 0
04:27:09.924494 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:09.924494 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:09.924510 IP (tos 0x68, ttl 251, id 45284, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [R.], cksum 0x9162 (correct), seq 1, ack 76, win 1658, length 0
04:27:10.048400 IP (tos 0x68, ttl 251, id 34753, offset 0, flags [DF], proto TCP (6), length 52)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.http > $CN_IP.51506: Flags [.], cksum 0xd96f (correct), ack 76, win 509, options [nop,nop,TS val 2237542961 ecr 329431082], length 0
04:27:10.048426 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.51506 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.http: Flags [R], cksum 0x90e0 (correct), seq 3187873826, win 0, length 0

3.3 Fingerprints of the RST packets by GFW’s TLS SNI-based censorship devices

curl --resolve youtube.com:443:$NON_CN_IP https://youtube.com

sudo tcpdump -v port 443

tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:25:15.234561 IP (tos 0x0, ttl 64, id 59308, offset 0, flags [DF], proto TCP (6), length 60)                                                                                    [0/966]
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [S], cksum 0x579d (correct), seq 2971216783, win 64240, options [mss 1460,sackOK,TS val 329316397 ecr 0,nop,wscale 7], length 0
04:25:15.365226 IP (tos 0x68, ttl 251, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [S.], cksum 0x4c87 (correct), seq 2839767305, ack 2971216784, win 65160, options [mss 1424,sackOK,TS val 91287507 ecr 329316397,nop,wscale 7], length 0
04:25:15.365257 IP (tos 0x0, ttl 64, id 59309, offset 0, flags [DF], proto TCP (6), length 52)
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [.], cksum 0x773f (correct), ack 1, win 502, options [nop,nop,TS val 329316528 ecr 91287507], length 0
04:25:15.428628 IP (tos 0x0, ttl 64, id 59310, offset 0, flags [DF], proto TCP (6), length 569)
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [P.], cksum 0x9a41 (correct), seq 1:518, ack 1, win 502, options [nop,nop,TS val 329316591
ecr 91287507], length 517
04:25:15.433547 IP (tos 0x68, ttl 251, id 47980, offset 0, flags [none], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R], cksum 0x7ed4 (correct), seq 2839767306, win 4547, length 0
04:25:15.434682 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.434682 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.434709 IP (tos 0x68, ttl 251, id 11362, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xa0ec (correct), seq 1, ack 518, win 4332, length 0
04:25:15.435139 IP (tos 0x68, ttl 251, id 42431, offset 0, flags [DF], proto TCP (6), length 40)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [R.], cksum 0xaac5 (correct), seq 1, ack 518, win 1811, length 0
04:25:15.559257 IP (tos 0x68, ttl 251, id 29047, offset 0, flags [DF], proto TCP (6), length 52)
    a$NON_CN_IP.deploy.static.akamaitechnologies.com.https > $CN_IP.35816: Flags [.], cksum 0x7435 (correct), ack 518, win 506, options [nop,nop,TS val 91287701 ecr 3293165
91], length 0
04:25:15.559269 IP (tos 0x68, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    $CN_IP.35816 > a$NON_CN_IP.deploy.static.akamaitechnologies.com.https: Flags [R], cksum 0xc436 (correct), seq 2971217301, win 0, length 0

4. Ending time

The unconditional RST appeared to stop prior to 2025-08-20 01:48 UTC+8, making the entire incident last for around 74 minutes (between 00:34 and 01:48 UTC+8).

sudo nmap -sS -p- $NON_CN_IP -oN scan_results.txt -T4 --min-rate 10000 -Pn

Starting Nmap 7.80 ( https://nmap.org ) at 2025-08-20 01:48 CST
Nmap scan report for $NON_CN_IP.deploy.static.akamaitechnologies.com ($NON_CN_IP)
Host is up.
All 65535 scanned ports on $NON_CN_IP.deploy.static.akamaitechnologies.com ($NON_CN_IP) are filtered

5. Acknowledgments

We are grateful to the many users and readers who promptly reported censorship incidents to us. In particular, this censorship event was of a very short duration, and without their timely notifications, it would have been impossible for us to conduct measurements in such a short period. We also thank Eric Wustrow for providing some of the measurement data sent from abroad to within the country.

6. Contact Us

This report was first published on GFW Report. We have also synchronously updated this report on net4people.

We encourage you to share questions, comments, or evidence related to the findings and hypotheses in this report, either publicly or privately. Our private contact information can be found in the footer of the GFW Report website.

Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China

Thu, 31 Jul 2025 00:00:00 +0000

Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China

Ali Zohaib^∗

University of Massachusetts Amherst

Qiang Zao^∗

GFW Report

Jackson Sippe

University of Colorado Boulder

Abdulrahman Alaraj

University of Colorado Boulder

Amir Houmansadr

University of Massachusetts Amherst

Zakir Durumeric

Stanford University

Eric Wustrow

University of Colorado Boulder

^* Ali Zohaib and Qiang Zao contributed equally to this work.

Abstract

Despite QUIC handshake packets being encrypted, the Great Firewall of China (GFW) has begun blocking QUIC connections to specific domains since April 7, 2024. In this work, we measure and characterize the GFW’s censorship of QUIC to understand how and what it blocks. Our measurements reveal that the GFW decrypts QUIC Initial packets at scale, applies heuristic filtering rules, and uses a blocklist distinct from its other censorship mechanisms. We expose a critical flaw in this new system: the computational overhead of decryption reduces its effectiveness under moderate traffic loads. We also demonstrate that this censorship mechanism can be weaponized to block UDP traffic between arbitrary hosts in China and the rest of the world. We collaborate with various open-source communities to integrate circumvention strategies into a leading web browser, the quic-go library, and all major QUIC-based circumvention tools.

1. Introduction

Since its standardization in 2021, QUIC has rapidly become a major Internet protocol. It now serves as the cryptographic basis of HTTP/3 [7] and in 2024, Cloudflare estimated that over 30% of web requests use QUIC [14]. QUIC’s popularity also poses a problem for censors, who must adapt their previous techniques to the new protocol. While censors have previously altogether blocked the protocol [25, 70 §5.2], for the first time, user reports began to suggest that the Great Firewall of China (GFW) had started blocking QUIC connections for specific domains [33] in April 2024, similar to their SNI-based censorship of TLS traffic [11, 37].

Censoring QUIC connections to specific websites is challenging at the state-level because QUIC encrypts all packets, unlike TLS where the destination server name is sent in plaintext. In QUIC, even the first handshake message, the QUIC client Initial, is encrypted, albeit under a key that is derivable by a passive network observer. This means that a censor that wants to block QUIC connections based on the Server Name Indication (SNI) field needs to decrypt the first packet of every QUIC connection to reveal the destination site. It is thus important for the anti-censorship community to understand the GFW’s new censorship design and implementation details to update circumvention strategies.

In this work,¹ we measure China’s new capability to inspect and block QUIC connections—the first nation-wide inspection and targeted censorship of QUIC. We confirm that China is decrypting and inspecting the first packet in QUIC connections at scale. Through several experiments, we infer the rules and high-level parsing logic of how the GFW processes QUIC connections. For instance, we discover that the GFW ignores QUIC packets with a source port lower than the destination port, likely as an optimization to inspect client-only traffic.

¹ Project homepage: https://gfw.report/publications/usenixsecurity25/en

We use traceroute-like measurements to show that the devices responsible for QUIC censorship are co-located at the same hop as existing GFW devices, indicating that they may use shared infrastructure or have similar management. However, despite this proximity, we measure the set of domains that trigger QUIC censorship, and find that the GFW’s QUIC blocklist substantially differs from blocklists used for TLS, HTTP, or DNS censorship in China. In particular, the QUIC blocklist is roughly 60% of the size of the DNS blocklist in terms of number of domains. Surprisingly, a large number of these domains do not even support QUIC, making it unclear why they ended up on a QUIC-specific censorship list.

We further demonstrate that China’s targeted QUIC censorship can be overwhelmed such that the GFW is not fully able to censor QUIC connections. This reveals an exploitable flaw in the GFW’s QUIC censorship where an attacker can send a moderate number of QUIC Initial packets—even to uncensored domains—and overwhelm the GFW such that other QUIC connections to censored domains are blocked at dramatically lower rates.

Finally, we show that the GFW’s QUIC censorship system makes the whole country vulnerable to attack. We present an availability attack that weaponizes the QUIC censorship mechanism to block any host in China from communicating over UDP with any foreign host. For example, this attack could be used to block access to all DNS servers outside of the country causing widespread Internet outages. We demonstrate this attack against ourselves using our own servers around the world, and show that a single spoofing machine can prevent the majority of these hosts from communicating with our vantage point in China. Because of the potential severity, we disclose this vulnerability to China’s CERT. We conclude with a discussion of implications for the censorship circumvention community and of the complex ethical considerations of exploiting vulnerabilities against a harmful actor, the GFW.

2. Background and Related Work

QUIC Protocol. QUIC is a UDP-based network protocol that was initially developed by Google [27] and later standardized by the IETF as RFC 9000 [43] in 2021. QUIC is akin to TLS but operates over UDP, reducing latency and enabling browser-controlled congestion control. QUIC was adopted to serve as the cryptographic basis of HTTP/3 [7] and in 2024, Cloudflare estimated that over 30% of web requests use QUIC [14]. QUIC also poses a shift for the anti-censorship community as it encrypts all packets to prevent tracking and tampering by middleboxes [27 §3].

QUIC Client Initial. The first packet in a QUIC handshake is the Client Initial packet. Since QUIC packets are encrypted from the outset but a key exchange has not occurred, initial packets are encrypted with a key derived from the Destination Connection ID (DCID) and a version-specific salt [58]. Both of these fields are sent in plaintext in the QUIC client initial packet, allowing the server (and a passive network observer) to decrypt the payload. As such, this protection does not provide confidentiality or integrity against observing parties, but protects against off-path spoofing attacks.

Once the payload of the initial packet is decrypted, it reveals a set of one or more CRYPTO frames containing a TLS 1.3 Client Hello message that lists the cipher suites and TLS extensions supported by the client. Typically, one of these TLS extensions will be the Server Name Indication (SNI), which specifies the hostname the client is attempting to connect to. Because initial keys can be computed by any network observer, the TLS Client Hello and its plaintext contents, including the SNI, can be decrypted.

QUIC Blocking. In 2021, Elmenhorst et al. found that while many QUIC websites were not accessible in Iran and China, it was not because of any SNI-based censorship. Instead, it’s because Iran blocked UDP traffic to those QUIC endhosts [25 §5.2], and China blocked both TCP and UDP traffic to those specific QUIC endhosts [25 §5.1]. Later, in March 2022, ValdikSS found that the Russian TSPU blocked all QUIC connections that used QUIC version 1 (0x00, 0x00, 0x00, 0x01), were destined to port 443, and had a payload size of at least 1001 bytes [70 §5.2, 63]. In December 2024, Uzbekistan blocked QUIC connections with Encrypted Client Hello (ECH) extensions [16]. To our best knowledge, China initiated the blocking of QUIC connections based on the SNI field in April 2024, making it the first and only country being able to do so as of June 2025.

Other Censorship Mechanisms. The GFW employs multiple methods to implement its blocking policies, including DNS poisoning [4, 6, 20, 29, 38], IP blocking [25, 66], keyword-based filtering [11, 13, 37], and active probing [2, 26, 66 §5, 65 §4.5, 22 §4.3]. For UDP-based DNS requests, the GFW injects fake responses to queries for forbidden domains. For HTTP(S) traffic, it performs stateful inspection of TCP connections and injects forged RST packets upon detecting censored domains in HTTP Host headers or TLS SNI extension fields [67]. This is followed by a brief period of “residual blocking,” primarily enforced via additional forged SYN+ACK and RST injections, though recent work has shown that packet dropping is also used [37 §5.4, 10].

3. QUIC Censorship Mechanism

In this section, we investigate how the GFW detects and blocks QUIC connections to forbidden domains. We show that the GFW blocks QUIC connections based on client Initial SNI, regardless of the server IP address. The GFW inspects the first packet in a UDP flow, and if it is a QUIC client Initial containing a domain name on China’s QUIC-specific blocklist, the GFW drops subsequent packets from the client to server for 3 minutes (Figure 1).

Figure 1: Overview of QUIC SNI Censorship, including the decision flow, initial packet decryption, SNI-based filtering, and residual blocking rules triggered for flagged connections.

Experiment Setup and Vantage Points. We used a set of vantage points inside and outside China for our experiments, which allowed us to test connections bidirectionally over the GFW. In total, we used seven vantage points in China: four in Beijing, two in Guangzhou, and one in Shanghai. We chose these regions in China since they are home to major Internet Exchange Points (IXPs) where the GFW is known to be deployed [52 §4.5, 36, 28 VI.C]. These vantage points were provisioned through Tencent Cloud (AS45090) and Alibaba Cloud (AS37963). Outside China, we utilized six vantage points located in Singapore (AS16509), San Jose (AS14618), San Francisco (AS14061), N. Virginia (AS14618), Cape Town (AS16509), and a U.S. university (AS32).

We developed a custom QUIC client using Quiche [46] that allows us to craft specific client Initial packets. As we observed blocking to be triggered by clients’ packets regardless of server response, the servers in our experiments ran tcpdump rather than a QUIC server. To ensure accurate measurements and avoid interference, we configured iptables rules on the servers to drop any outgoing ICMP packets directed to the clients.

3.1. QUIC Connection Blocking

Upon observing a QUIC client Initial message with a forbidden SNI, the GFW drops all subsequent UDP packets sharing the same source IP, destination IP, and destination port. We discovered this behavior by sending QUIC client Initial messages from the three locations of our vantage points in China to a server in the US. These messages used QUIC version 1, and google.com in the SNI. We found that while the QUIC client Initial messages reached our server, any subsequent UDP packets in the connection from client to server were dropped by the censor for 180 seconds.

During this time, if the client sent 10 byte random data packets from even a different source port to the same server endpoint (destination IP and port), these were dropped by the GFW as well. However, random data packets sent to a new destination port on the server were not blocked, indicating the GFW blocks based on the 3-tuple (source IP, destination IP, destination port) to prevent trivial circumvention attempts via source port changes. As confirmed by having the server send a Server Initial message along with additional UDP packets carrying random 10-byte payloads after receiving the QUIC client Initial message, we also observed that this blocking was only client-to-server; server-sent packets were not dropped.

A Single Packet Triggers Residual Blocking. Unlike previously documented TLS-SNI censorship by the GFW [38 §3.1], which requires the detection of at least two packets (SYN followed by a PSH/ACK), the QUIC censorship mechanism can be activated by a single QUIC client Initial packet containing a forbidden SNI. This is the first known instance of the GFW implementing residual blocking via packet dropping for a UDP-based protocol . While the GFW has historically censored DNS traffic over UDP through spoofed packet injections [4, 6, 38], it has not employed packet dropping as a method of blocking for UDP-based protocols. This may be because this type of censorship requires an in-path capability to drop packets, compared to prior injection-only censorship which can be accomplished with on-path techniques where the censoring device only sees a copy of packets. The residual packet-dropping behavior of the GFW also introduces a new vector for availability attacks, where an attacker can use the GFW to block communication between arbitrary hosts. We explore this attack in Section 6.

Inconsistent Bidirectional Blocking. While our preliminary experiments showed that traffic entering or exiting China could trigger blocking, this behavior changed on September 30, 2024. Since then, inbound traffic to most of our vantage points has no longer triggered blocking, with the exception of traffic to Beijing and Guangzhou.

Blocking Latency. Our experiments show a brief delay between detection of a QUIC client Initial packet containing a forbidden SNI and when the GFW begins to drop packets, which allows several packets to reach the server. The fact that GFW was not able to drop the QUIC client Initial with forbidden SNI shows a level of on-path deployment of the GFW [64 §2.1]. In combination with the in-path packet dropping capability, we consider its deployment architecture to be a hybrid of both on-path and in-path, which is similar to the GFW’s blocking of TLS ESNI traffic [32].

To precisely measure this blocking delay, we adopted a methodology similar to what used in a 2020 study that measured the delay in blocking of TLS traffic containing an Encrypted Server Name Indication (ESNI) extension [32]. Specifically, we measured how long we continued to receive subsequent packets after a triggering QUIC Initial packet.

We conducted a day-long experiment to determine the GFW’s blocking latency for QUIC. From our vantage point in Beijing, for the first five minutes of each hour, we initiated 25 UDP flows (unique source and destination ports) to a server we controlled in Singapore. In each connection, we continuously sent unique 10-byte payloads at a rate of 100 packets per second. Five seconds into the experiment, we sent a QUIC Initial packet with a forbidden SNI google.com to each of the 25 destination ports corresponding to the ongoing connections, but from different source ports. These QUIC Initials trigger the GFW to block each of the 25 destination ports (for our client/server pair for any source port) such that the server would stop receiving the 10-byte payloads.

On the server side, we captured packets and looked for connections in which there was at least a 120-second gap between UDP packets, indicating that the QUIC client Initial successfully triggered censorship. For these connections, we looked at the sending time on the client of the blocking QUIC Initial and the last UDP payload the server received before the censorship-induced gap. This represents the blocking latency when packets were still allowed to pass the GFW immediately following a censorship trigger to a 10 ms granularity.

Blocking latencies ranged 60 ms to 7.5 seconds (Figure 2). Over 90% of connections were blocked within one second, but there is a long tail that takes longer. We hypothesize that the variable delay in blocking corresponds to the variable volume of QUIC traffic the GFW must process (See Appendix A). We explore exploiting this property in Section 5 to degrade the performance of the GFW’s QUIC censorship.

Figure 2: The CDF shows the distribution of the time taken by the GFW to enact a blocking rule causing subsequent packet drops. In over 90% of cases, the GFW blocks the connection within one second. The observed blocking times range from a minimum of 0.06 seconds to a maximum of 7.5 seconds.

3.2. Flow Tracking Logic

Unlike TCP, which has a clear three-way handshake that marks the start of a new connection, UDP is connectionless without any explicit transport layer handshake. This makes it challenging for middleboxes to identify the beginning of a new UDP flow. Although, QUIC connections can be traced using Connection IDs (CIDs), we found that the GFW does not use CIDs to track QUIC flows. Instead, it uses the UDP 4-tuple (source IP, destination IP, source port, destination port) and employs a 60-second timeout for keeping state in its flow tracking system. To learn this, we relied on the fact that the GFW will only block a connection if the first packet in a UDP flow is a QUIC client Initial message with a forbidden SNI. If any other UDP packet precedes the Initial packet, the connection will not be blocked.

From one of our Beijing vantage points, we sent a UDP packet with a random 10-byte payload to a server in the U.S. We then waited a variable delay before sending three QUIC client Initial messages in the same connection as the 10-byte random, each spaced one second apart. We repeated this experiment, increasing the delay between the random payload packet and client Initial packets by one second each iteration, until we observed blocking (i.e. no packets received for 180 seconds).

We found that blocking occurred when the delay between the first random payload and the client Initial packet reached 60 seconds implying that the flow initiated by the random UDP payload was tracked for 60 seconds. The QUIC Initial packets sent after this 60 second window triggered blocking, indicating that the GFW had reset the state for the flow and was treating the QUIC Initial packets as a new flow.

No UDP Reassembly. We found that the GFW does not reassemble QUIC Initial packets that are split across more than one UDP datagram. This design choice may be reasonable at the time of its deployment on April 7, 2024, considering that there had been few QUIC clients sending large QUIC Initial packets that do not fit in a typical UDP datagram. However, as detailed in Section 7, since September 13, 2024 [1], Chrome introduced a series of changes to its QUIC Initial packets, making them too large to fit into a single UDP datagram. These changes to the widely used browser render the GFW less effective, as it can only block if the SNI extension appears in the first UDP datagram.

3.3. Source Port Must Exceed Destination Port

We found that sending a QUIC client Initial packet with a forbidden SNI to the server in the U.S. did not always trigger blocking. To further investigate this behavior, we conducted multiple experiments aimed at determining the specific rules the censor uses to filter QUIC connections.

We selected a range of ports from 401 to 450 with a step size of 1. We sent QUIC client Initial messages with SNI google.com from our vantage point in Beijing to our U.S. server, enumerating all possible source and destination port pairs in the range. After sending each QUIC client Initial message, we waited one second, then sent five additional UDP packets–each with a unique 10-byte payload–spaced one second apart. This process was repeated ten times, using a different destination IP address (from the /28 subnet assigned to our server) in each iteration. We waited for five minutes between iterations to avoid any residual blocking from previous connections. For each port pairing, we then recorded the number of connections that were successfully received and the number that were blocked (i.e. no follow-up UDP packets received).

As shown in Figure 3, the GFW does not block connections where the source port number is less than or equal to the destination port number. However, blocking is not uniform, which suggests variability in how consistently connections are blocked. We also conducted the same experiment for the full range of ports (1 to 65535) with a step size of 1,000 and found this filtering rule to be consistent across all ports (Appendix B).

Figure 3: GFW exempts connections where the source port of the QUIC Initial packet is equal to or lower than the destination port. The experiment was conducted on December 2, 2024, from a vantage point in Beijing, China.

The GFW Limits the Number of Connections to Inspect. The censor applies this heuristic port checking rule to limit the number of connections it needs to inspect. Since most clients will choose a (high) ephemeral port ² and connect to lower well-known port numbers (e.g., 443), the GFW can discard likely server-to-client traffic by ignoring packets that have a source port lower than destination port.

² Linux hosts typically use an ephemeral port range of 32768 to 60999, while macOS and Windows Vista or later use the range 49152 to 65535. [56]

Two questions arise when the censor employs this rule: 1) how much traffic does the censor quickly rule out? 2) how many QUIC client Initials does the censor miss? To evaluate the efficiency and false negative rate of this rule, we collected UDP flows from a tap in a US university and analyzed the distribution of source and destination port numbers.

Table 1 shows the distribution of QUIC client Initial packets (Inits) and UDP datagrams based on source and destination ports, observed on a tap in a US university between 8:00 and 9:00 local time (Pacific Standard Time, UTC-8), on January 22, 2025. The censor only processes a packet where UDP sport > dport, meaning they capture more than 90% of all QUIC client Initial packets, while looking up flow table for only 30% of all UDP packets. The actual percentage of UDP payloads attempted for decryption is even lower: as detailed in Section 3.2, the GFW only parses the payload of the first UDP datagram in a flow, defined as a five-tuple (source IP, destination IP, source port, destination port, UDP protocol), that has not been seen in the last 60 seconds.

TABLE 1: Distribution of packet counts based on source and destination ports, observed on a tap in a US university between 8:00 and 9:00 local time (Pacific Standard Time, UTC-8), on January 22, 2025. The censor only further considers flow tracking if a UDP header has sport > dport, making it possible to capture more than 90% of all QUIC client Initials while looking up flow table for only 30% of all UDP packets.


	QUIC Client Inits	UDP datagrams

sport > dport	6.7 M	(92.3%)	3.7 B	(29.8%)

sport < dport	0.6 M	(7.6%)	8.4 B	(68.0%)

sport = dport	4.6 K	(0.06%)	27.7 M	(2.2%)

3.4. Diurnal Blocking Pattern

The variability in Figure 3 indicates that connections are not consistently blocked and that blocking is non-deterministic. To explore this, we ran a week-long experiment from different vantage points to observe the frequency of QUIC connection blocking throughout the day and across all destination ports. We used our three locations in China to establish a connection to a U.S.-based server. We sent a 1,000 concurrent probes (i.e. a QUIC client Initial packet containing SNI google.com, followed by 1 second delay and 5 subsequent UDP packets containing unique 10-byte payloads, every 5 seconds from our three China vantage points to 10 IPv4 addresses and all ports of our server in the U.S.) In all cases, we ensured that the source port was greater than the destination port per Section 3.3. We mark a connection as censored if none of the 10-byte follow-up UDP payload packets are received by the server, after the QUIC client Initial. We then calculate the percentage of blocked connections by aggregating the data for each hour for each client location.

Blocking Rate Is Influenced by the Time of the Day. As can be seen in Figure 4, there is a clear diurnal pattern across all three cities, with blocking percentages peaking during early morning hours and dropping to the lowest levels during the day. Beijing consistently shows the highest levels of blocking, followed by Shanghai and Guangzhou. This pattern suggests that the blocking rate is influenced by the Internet usage patterns in China, with the highest blocking rates observed during periods of low network traffic.

Figure 4: Percentage of blocked QUIC connections over time for clients sending connections from three major cities in China to a server in the US. The timestamps shown are in China Standard Time (CST, UTC+8) and span from November 15 to 22, 2024.

We hypothesize that this behavior occurs because the GFW can only handle a limited volume of traffic at any given time. The operational cost of decrypting QUIC Initial packets is substantial at scale, making the blocking rate sensitive to network load, which varies during the day. Diurnal patterns of blocking have also been observed in prior studies on GFW’s keyword filtering and DNS injection mechanisms [4 §7, 15 §3.2], suggesting computational limitations that render the GFW less effective during peak hours. We note that this becomes increasingly relevant in the context of QUIC connections, as parsing QUIC traffic is computationally expensive compared to other plaintext protocols like HTTP and DNS. In Section 5, we present further evidence that increasing the number of QUIC Initial packets past the GFW can overwhelm it, leading to a degradation in its censorship effectiveness.

3.5. Locating the Censorship Devices

We performed an incremental IP TTL measurement to locate the censorship devices. We set a fixed IP TTL value in the QUIC client Initial messages, starting from 1 and incrementing by 1 in each experiment. In the first second of each experiment, we sent 10 QUIC client Initial messages with the SNI of google.com to port 53 of our server in the US, ensuring that the blocking would be triggered as long as it reaches the censor. After 5 seconds, we then sent 100 UDP datagrams with the same 4-tuple as the QUIC client Initial message. The payload of these UDP packets consisted of 10-bytes that included the encoded TTL value used in the QUIC client Initial packets. We inferred if a QUIC Initial message reached the censor by observing if the 100 UDP datagrams were dropped. This measurement was performed from three vantage points in China: Beijing, Shanghai, and Guangzhou, with each experiment repeated 10 times.

As shown in Table 2, we found the QUIC blocking is not triggered until the IP TTL value is 9, 11, and 12 for our clients Shanghai, Beijing and Guangzhou, respectively. The hop triggering the blocking is located in the backbone network of ChinaNet for Shanghai and Guangzhou, and in the backbone network of China Unicom for Beijing.

Similarly, we sent DNS queries for google.com using the same 4-tuple with incrementing IP TTLs to port 53 of the server, We observed that DNS injection was not triggered until the IP TTL value matched those observed for QUIC blocking, suggesting that the new devices are co-located at the same hop as the existing GFW devices.

TABLE 2: Traceroute results identifying GFW’s UDP censorship points: path to devices performing QUIC and DNS blocking, including the final uncensored hop from three different client locations.


City	Hops Away (QUIC/DNS)	Blocking Hop -1 (ISP/AS)	Blocking Hop (ISP/AS)

Shanghai	9/9	ChinaNet Shanghai Province Network (AS4812)	ChinaNet Backbone (AS4134)

Beijing	12/12	China Unicom Backbone (AS4837)	China Unicom Backbone (AS4837)

Guangzhou	11/11	ChinaNet Guangdong Province Network (AS4134)	ChinaNet Backbone (AS4134)

3.6. QUIC Parsing Idiosyncrasies

The GFW’s QUIC censorship does not strictly follow the QUIC specifications [43, 58] in several ways. We crafted and sent several modified QUIC payloads that should be rejected by RFC-compliant implementations, to see if they would still trigger the GFW’s censorship. If they do, it indicates that the GFW does not properly ignore non-compliant QUIC payloads, potentially presenting an opportunity for circumvention methods or other vulnerabilities. Our modified QUIC payloads are described in Table 3, and Figure 5 shows the results of sending these over the GFW. For each payload, we sent 20 connections in both directions—from vantage points in China to servers outside the country, and vice versa—to determine whether they would trigger censorship.

TABLE 3: Description of each experiment we run to characterize the GFW’s QUIC parsing mechanism. For each, we mark if the payload is ever observed to be blocked (Section 3.6), and if it can be used to degrade the GFW (Section 5).


Exp. No.	Descriptions of the Tested QUIC Initial Packets	Blocked?	Degrades?

1	Packet number is one-byte.	✓	✓

2	Remove last byte from QUIC packet.	✕	✓

3	Bad version number with incorrect auth tag. Version Number: 0x00000002.	✕	✕

4	Both connection IDs have a length of 0x00.	✓	✓

5	Source connection ID has a length of 0xff.	✕	✓

6	CRYPTO frame has a length of 0x00 but still contains a payload.	✓	✓

7	Sensitive domain in an extension other than the SNI extension (e.g. ALPN contains google.com).	✕	✓

8	QUIC payload contains a single CRYPTO frame along with multiple PING and PADDING frames.	✕	✓

9	A QUIC Initial packet whose TLS Client Hello contained an Encrypted Client Hello extension with an outer SNI of cloudflare-ech.com.	✕	✓

10	A QUIC Version 2 packet.	✕	✕

Figure 5: Percentage of blocked QUIC-like packets for each experiment run. For each payload, we created 20 connections and measured how many were received by the destination host. Each payload, described in Table 3, tests a modification to the standard QUIC client Initial and provides insight into the parsing logic of the GFW QUIC censor.

No Need for Padding. While the QUIC specification requires that Initial packets must be padded to a minimum of 1200 bytes, we found that the GFW does not enforce this requirement. We were able to trigger censorship with payloads as small as 137 bytes. However, since the GFW does not inject responses, there is not a risk of amplification attacks.

Length Field Ambiguity. Connection ID lengths are defined in the specification to be between 8 and 20 bytes; however, the field supports lengths up to 255 bytes. We find that setting both source and destination connection IDs to a length of 0x00 (too short) is blocked, though this should be ignored as per the specification. On the other hand, a length of 0xff is not blocked, indicating that the GFW correctly checks the upper limit. Curiously, we find that the GFW will block a payload even if the CRYPTO frame has a specified length of 0x00, as long as the actual payload contains a forbidden SNI. The GFW appears to assume the CRYPTO frame length from the rest of the payload, meaning it cannot correctly handle split CRYPTO frames (such as used by Google Chrome browsers).

Version Specific Blocking. Only QUIC version 1 packets containing the plaintext byte pattern 0x00000001 in the version field are subject to blocking. The recently standardized QUIC version 2 [21], which uses a different salt value for initial encryption keys, remains unblocked. This suggests the GFW either has not updated its filtering mechanisms for new version salt values or relies on version 1-specific plaintext byte pattern matching for packet inspection.

4. Monitoring the Blocklist over Time

In this section, we investigate the websites that are blocked by the GFW’s QUIC-SNI censorship mechanism. We consider currently blocked sites, how the blocklist has changed over time, and how the QUIC blocklist compares to blocklists used by other censorship methods like TLS-SNI, HTTP, and DNS. As noted in Section 3.4, the GFW’s QUIC censorship mechanism is non-deterministic, which requires an experimental methodology that minimizes false negatives. For each name that we test, we send QUIC client Initial messages carrying the SNI from several vantage points and repeat the process over multiple trials. Additionally, to avoid inaccuracies from residual censorship on a specific destination port, we do not send connections to the same 3-tuple (source IP, destination IP, destination port) within any 180 second window.

We monitor the GFW’s QUIC blocklist over a period of more than three months. Because of the inconsistency in bidirectional blocking—specifically, that most of our vantage points stopped experiencing bidirectional blocking after September 30, 2024—we adopted an inside-out measurement approach. We deployed ten vantage points in Beijing (AS45090) to run the client-side script and a vantage point in a US university (AS32) for the server. The server was assigned a /28 IPv4 subnet. For each name to test, the client sends a QUIC client Initial message to the server, waits for one second, and then sends 5 unique 10-byte UDP payload packets spaced 1 second apart. We mark an SNI as blocked if none of the follow-up UDP payload packets are received.

We use the full Tranco list (ID: 664NX) ³ obtained on October 2, 2024, which consists of approximately seven million fully qualified domain names (FQDNs) for testing. We acknowledge that this list may not exhaustively capture all censored names. However, we argue that a reasonably large list of popular names provides a representative sample of the GFW’s QUIC blocklist.

³ The list available at: https://tranco-list.eu/list/664NX/full

In each test, for each name, each of the ten client vantage points in Beijing sends a QUIC client Initial message to a distinct IP address of our US server. Based on our finding in Section 3.3, we always use source ports greater than destination port to trigger blocking. We run these experiments as cronjobs between 3 AM and 6 AM CST. This is because we observed the highest rate of blocking during these hours (Section 3.4).

Since the blocking rate during this time is observed to be at least 50% for our connections, we repeat each QUIC client Initial test ten times to ensure that the accuracy of our blocklist extraction is above 1− (1 − 50% ) ¹⁰ = 99.9%. On the server side, we aggregate the data for each SNI that is blocked for each day. These experiments have been running for over three months, starting from October 8, 2024, to January 15, 2025.

Figure 6: Number of FQDNs blocked by the GFW’s QUIC SNI censorship for the full Tranco list (ID: 664NX), between October 8, 2024 and January 15, 2025. The number of blocked domains are aggregated weekly. The bar chart shows weekly churn in the blocklist over time.

QUIC Blocklist. On a weekly basis, we found that the GFW blocked an average of 43.8K FQDNs from the Tranco list (Figure 6). Over the full duration of our experiments, we observed that the GFW blocked 58,207 unique FQDNs from the Tranco list (Table 4).

TABLE 4: Number of Fully Qualified Domain Name (FQDNs) supporting QUIC, blocked by QUIC-SNI censorship, and their intersection. QUIC censorship test was conducted between October 8, 2024 and January 15, 2025.


Fully Qualified Domain Name	Count

Total Tested (Tranco List)	6,955,968

Supporting QUIC	1,489,967

Ever Blocked over QUIC	58,207

Blocked & Supporting QUIC	38,451

Domains Blocked Over QUIC May Not Support QUIC. We tested domains for QUIC support by making direct HTTP/3 requests rather than relying on Alt-Svc headers, because some servers support HTTP/3-over-QUIC without advertising it. From our measurements, we identified 58,207 FQDNs that were blocked over QUIC, of which 38,451 actually support HTTP/3-over-QUIC (see Table 4). Within this larger set of blocked names, 9,345 popular second-level domains (e.g., google.com, hrw.org, youtube.com, tiktok.com) were found blocked, although only 3,233 of them actually support QUIC. Notably, a substantial number of googlevideo.com subdomains (35,443) appeared on the blocklist, suggesting a broader blocking rule targeting *.googlevideo.com and resulting in an increase the number of QUIC-supporting domains. Since not all QUIC-blocked domains actually support QUIC, it is difficult to determine the exact logic behind the GFW’s blocklist. The GFW may be blocking these domains preemptively, anticipating potential future QUIC support or it may be using other criteria unrelated to QUIC for its blocking decisions.

4.1. Comparison with Other Blocklists

We conducted a comparative analysis of the GFW’s QUIC-SNI blocklist against other established GFW censorship mechanisms, including TLS-SNI, HTTP Host, and DNS-based blocking. To evaluate TLS-SNI blocking, we employed a methodology based on prior work [11, 37]. We established a client in Beijing and a sink server in the U.S. to perform inside-out measurements, maintaining consistency with our QUIC-SNI blocking analysis. Our sink server was configured to accept TCP connections but not respond with any data. In each test, after completing the TCP handshake, the client transmitted TLS Client Hello messages containing test domain SNI values. We monitored the connection for TCP RSTs packets—a characteristic signature of SNI blocking. For HTTP Host testing, we applied a similar approach but replaced the TLS Client Hello with HTTP GET requests containing the test domain in the Host header field.

For DNS censorship testing, we followed established methodologies from previous research [6, 38]. We configured our Beijing-based client to send DNS queries to a controlled US-based IP address where no DNS server was running. This configuration allowed us to definitively attribute any received DNS responses to GFW injection, as our server was configured to ignore all queries. To ensure consistent comparison across all three testing methods (TLS-SNI, HTTP Host, and DNS), we utilized domains from the same Tranco list. We performed these measurements and collected blocklisted domains over a one-week period from January 9, 2025, to January 15, 2025.

Figure 7 illustrates the overlap between the blocklists for TLS-SNI, HTTP Host, DNS, and QUIC protocols. For our tested Tranco list domains, DNS blocking affected the largest number of domains (106,973), followed by HTTP (105,488) and HTTPS (102,216). The QUIC blocklist was notably smaller, containing approximately 55 percent the number of domains compared to the other three blocklists. Among the 58,207 domains that were ever blocked over QUIC, 11,854 were exclusively blocked through this protocol. Notably, of these QUIC-exclusive blocked domains, we found only 2,329 domains that actually supported QUIC.

Figure 7: Venn diagram showing the overlap between the blocklists for HTTPS, HTTP, DNS, and QUIC. The blocklists for each protocol are aggregated over a period of 1 week from January 9, 2025 to January 15, 2025.

We found 40,447 domains common to all four blocklists, representing a 24.4% overlap (measured as intersection divided by union). When comparing QUIC blocking against the other three protocols individually, we found the highest overlap (intersection over union) with HTTPS at 46,251 domains (40.51%), followed by HTTP with 43,191 domains (35.84%), and DNS with 41,484 domains (33.54%). These findings indicate that each censorship mechanism operates with distinct but overlapping blocklists, creating a complementary system that maximizes the GFW’s censorship coverage. For instance, an HTTP/3-over-QUIC browsing session in a modern browser typically starts with a DNS query, followed by request over HTTP/2 (or earlier) and then upgrades to HTTP/3 over QUIC. The GFW’s censorship strategy is designed to affect each stage either exclusively or in combination, ensuring that the user is unable to access the forbidden content on the web.

Table 5 shows 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 FQDNs.

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	Support QUIC	Sample 500

DNS	-	-	-	-	-	-

HTTP	0.57	-	-	-	-	-

TLS	0.67	0.43	-	-	-	-

QUIC	0.19	0.20	0.26	-	-	-

Support QUIC	0.19	0.20	0.13	0.05	-	-

Sample 500	0.03	0.03	0.03	0.01	0.05	-

5. GFW Degradation Attack

In Figure 4, we observed that the GFW’s QUIC censorship was less effective during times corresponding to high traffic volume in China. This led us to hypothesize that the GFW’s effectiveness could be purposefully degraded by sending QUIC packets that the GFW would need to process. While our experiments provide valuable insights into the design of China’s censorship system, they also raise several ethical concerns which we carefully considered and discuss in Section 9. We designed our experiments to ensure that users and other Internet devices were not impacted, and specifically ensured our tests only degraded the GFW.

In this experiment, we use three vantage points. The first is in China (Beijing, Alibaba, AS37963) which we refer to as ChinaVP, the second is in the US (East, Digital Ocean, AS14061) which we refer to as USVP, and the third is in a research institution in the US (University of Michigan, AS36375) which we refer to as StressVP. Our goal is to measure the effectiveness of the GFW’s QUIC censorship in the presence of moderate volumes of QUIC traffic. This experiment consists of two parts that are run simultaneously: a measurement part and a stressing part.

In the measurement part, we configure our three vantage points to do the following: the ChinaVP sends a QUIC Initial packet (267 bytes of payload) containing a forbidden domain name, namely google.com in the SNI field, to USVP where the destination port is less than the source port (to trigger censorship as shown in Section 3). After a 1-second pause, we send 100 UDP packets in the same flow containing a fixed innocuous payload of 1,111 bytes. This process is repeated for 1000 different source-destination port pairs. We mark a connection as permitted (evaded censorship) if the server (USVP) receives the QUIC Initial packet and 95% or more of the packets that follow.

In the stressing part, we use the StressVP to send two types of traffic in varying sending rates (from 100kpps to 1500kpps, in 100kpps increments for seven minutes each and spaced by a three-minute pause) towards the IPv4 addresses in the /14 network prefix in which the ChinaVP is hosted. Our goal is to send enough traffic to stress the GFW without impacting the network link or routers. By choosing a large network to send over, the impact of our traffic is diluted for individual hosts.

Furthermore, to avoid having our stressing packets reach end-hosts, we estimate the hop-distance between the IPs in the /14 and StressVP. We run TTL-limited DNS scans using ZMap to resolve example.com on the entire /14. We approximate the hop-distance of each IP from StressVP by the cessation of DNS resolutions we receive from the 164 DNS servers in the /14. We then set our TTL value for our stressing packets we send from the StressVP to one less than the smallest (closest) hop-distance DNS server in the /14.

During the stressing part, we send two types of (TTL-limited) traffic past the GFW: QUIC Initial packets, and UDP packets with a fixed payload generated at random. For QUIC packets, we use the same QUIC Initial payload sent between ChinaVP and USVP containing a forbidden SNI to trigger the GFW’s censorship. For the random payload we use innocuous bytes with the same length as the QUIC payload. We use ZMap [23] to send each of these payloads and configure the sending rate such that we send on average no more than 6 pps to each IP in the /14.

Our experiment consists of sending (TTL-limited) QUIC Initial packets from our StressVP to the /14 of ChinaVP. This is repeated three times on different days, once in an ascending order and twice in a shuffled order of sending rates. Simultaneously, we measure from ChinaVP to USVP the fraction of permitted connections. We then repeat the experiment three times (not coinciding with QUIC stressing), but send a random payload instead of QUIC Initial packets and measure the fraction of permitted connections. Figure 8 shows the impact of our experiment (averaged) on the GFW. As we increase the rate of QUIC Initial packets, the GFW is less able to censor connections between ChinaVP and USVP. We also do not see this pattern when sending random payloads, meaning that the degradation is only due to processing QUIC payloads, and not due to network volume degrading the network, as further supported by our network monitoring. Note that all the experiments were conducted in the early morning hours in China, during which the GFW is more effective at censoring QUIC traffic (see Figure 4).

Figure 8: We stress-test the GFW by sending two types of equal-length packets at 0–1500 Kpps: QUIC Initial packets containing a forbidden SNI (Censored Stressing) and UDP packets containing a random payload (Random Stressing). We measure the effectiveness of QUIC censorship during this test by sending (at a fixed rate) QUIC Initial packets followed by 100 data packets, mimicking 1000 QUIC connections from a vantage point in China to a vantage point in the US and calculating the fraction of connections the GFW fails to censor (Censored Traffic). The GFW is less effective at censoring our measurement QUIC connections as we increase the number of QUIC Initial packets we stress-test with, increasing the difficulty on the GFW to process QUIC packets. We ensure our test impacts only the GFW and not the network by measuring the rate of uncensored QUIC traffic (Egress/Ingress Control Traffic) to and from both vantage points during our test.

Network Monitoring. While we run our experiment, we monitor the network between ChinaVP and USVP in two ways. First, we send uncensored QUIC connections in both directions, and monitor the fraction of packets received by both ends. Second, we use ZMap to scan the /14 network on tcp/443 at a slow rate (650 pps), and measure the response rate in the network. If either of these metrics decreases significantly during our experiments, it may be due to a saturated network link, indicating we must halt the experiment. Since we never observed a decrease in either metric during our experiments, we believe our experiments had negligible impact on networks and devices beyond the GFW.

Reverse Engineering. In addition to helping users evade censorship, the degradation attack is also helpful in understanding the GFW’s processing. For example, if a particular QUIC payload can be used to degrade the GFW’s censorship effectiveness, we know it has been processed at some level by the GFW, even if that same payload is not blocked. On the other hand, if a payload has no influence on the GFW, then it is likely discarded prior to a computationally expensive step.

Table 3 shows if each payload was successful in degrading the GFW’s effectiveness to censor. We tested this by sending each payload at 1200 Kpps, and observing if the fraction of permitted censored connections exceeded 60%, indicating that the payload had an impact on the GFW. These results suggest the GFW processes all payloads with the default QUIC version, and that even payloads that do not decrypt or have invalid authentication tags can degrade the GFW. However, a valid tag is necessary to trigger censorship, implying that the “slow” part of the GFW is likely the cryptographic operations in decrypting the payload.

6. Availability Attack

Prior work has shown that residual censorship can sometimes be “weaponized” by attackers to conduct availability attacks [8, 9]. In this type of attack, attacker sends a censorship-triggering request to Destination B, spoofing the source IP address to be from Victim A. If the request triggers residual blocking in a firewall between A and B, then the two hosts will be unable to communicate, as the firewall believes that Victim A sent a forbidden request. Residual censorship is commonly on the order of 1–3 minutes [9, 10, 11, 37, 64, 66], and an attacker can simply spoof additional triggering packets during or after the residual censorship expires to keep the victim and destination blocked.

Our study represents the first known instance of the GFW implementing residual blocking for a UDP-based protocol. While the GFW has historically censored DNS traffic over UDP through spoofed packet injections, it has not employed packet dropping as a method of blocking for UDP-based protocols. However, the GFW’s new QUIC blocking mechanism employs packet-dropping in a way that introduces a new vector for availability attacks, impacting all of China. In particular, an attacker could use this availability attack to block UDP connections from hosts inside China from communicating with servers outside. For example, this attack could block all open or root DNS resolvers outside of China from being accessed from within China, leading to widespread DNS failures in the country.

In this section, we investigate the practicality of this attack by performing it against our own hosts and servers.

Attack Setup. This attack requires the ability to spoof IP packets, which requires a server that is not limited by egress filtering. We obtained such a host from a public VPS provider, and verified that we can spoof IP packets and have them received within China. Inside China, we used a VPS under our control in Guangzhou, as this host experienced QUIC censorship both incoming and outgoing, meaning clients from outside China connecting to this server also experienced QUIC censorship. To simulate “victim” hosts, we acquired an AWS EC2 instance in each of the 32 regions that AWS operates in outside of China.

For each EC2 instance, we sent a DNS query to our VPS in Guangzhou. We then measured if this request was received by our VPS, indicating that the connection was initially available.

Next, from our attack machine capable of spoofing packets, we spoofed ten censored QUIC client Initial packets for each EC2 instance to our VPS in China. These packets are designed to trigger the GFW’s residual censorship, between the EC2 instances’s IP address and the IP:Port of the VPS in China. The path that these packets take to the VPS in China may differ significantly from the path that packets from the EC2 machine would take, meaning they may pass different GFW nodes, rendering the attack ineffective. We sent these spoofed packets every second.

Meanwhile, we measured the attack effectiveness from each EC2 instance, sending a DNS request to the VPS in China every five seconds. If the residual censorship was active on the path between instance and VPS, the request would be blocked, indicating a successful availability attack.

Figure 9: The map shows the locations of the EC2 instances that were affected by the availability attack. Hosts that are most affected are shaded in red, while hosts that are less affected are shaded in green. The black point in China is the location of the victim server and the black point in the US is the location of the spoofing attack server.

Table 6 and Figure 9 show the locations of the EC2 instances and the effects of the attack. Over half (17) of the 32 EC2 instances were heavily impacted by our attack. While some packets still get through for heavily impacted hosts, we find this is largely due to the timing of when the 3-minute residual censorship expires. When it does, there is up to one second before the next spoofing packet arrives to reblock the instance. Sending faster or timing with the expiration improves the blocking rate. We also observed that seven hosts were affected approximately half the time, indicating that there may be multiple network paths between a given instance and VPS, and only some of those paths experienced the residual censorship.

TABLE 6: Shows how many packets were received by the server from each AWS region. The availability attack ran for 30 minutes and a packet was sent by the real client every five seconds. The spoofing server was in the U.S. and the victim server was in Guangzhou, China. For each AWS host, the attack server sent ten spoofed QUIC client Initial packets, each in a new connection, every second.


Continent/Region	City/Area	# Packets Received	% of 360

Africa	Cape Town	110	30.56%

Asia Pacific	Hong Kong	360	100.00%

Asia Pacific	Hyderabad	13	3.61%

Asia Pacific	Jakarta	360	100.00%

Asia Pacific	Malaysia	360	100.00%

Asia Pacific	Melbourne	360	100.00%

Asia Pacific	Mumbai	360	100.00%

Asia Pacific	Osaka	145	40.28%

Asia Pacific	Seoul	246	68.33%

Asia Pacific	Singapore	360	100.00%

Asia Pacific	Sydney	360	100.00%

Asia Pacific	Thailand	360	100.00%

Asia Pacific	Tokyo	229	63.61%

Canada	Calgary	26	7.22%

Canada	Central	13	3.61%

Europe	Frankfurt	244	67.78%

Europe	Ireland	16	4.44%

Europe	London	12	3.33%

Europe	Milan	17	4.72%

Europe	Paris	10	2.78%

Europe	Spain	15	4.17%

Europe	Stockholm	14	3.89%

Europe	Zurich	17	4.72%

Israel	Tel Aviv	18	5.00%

Mexico	Central	13	3.61%

Middle East	Bahrain	201	55.83%

Middle East	UAE	22	6.11%

South America	Sao Paulo	12	3.33%

US East	N. Virginia	195	54.17%

US East	Ohio	21	5.83%

US West	N. California	21	5.83%

US West	Oregon	19	5.28%

The remaining eight instances were not affected at all, largely in the Pacific region, suggesting that the spoofing location did not share a network path with these hosts. We confirm that all 32 hosts were capable of triggering censorship when the censored QUIC client Initial packet was sent directly from the real client.

Defense. Defending against this attack while still censoring is difficult due to the stateless nature and ease of spoofing UDP packets. One potential mitigation approach involves only triggering censorship after detecting a corresponding QUIC Server Hello and later client packets, ensuring that the connection is live and not being spoofed from one end. However, this approach has significant limitations. First, it necessitates stateful tracking of connections, which imposes substantial overhead on middleboxes. Furthermore, the inherent challenges of asymmetric routing—where the client-to-server (C2S) and server-to-client (S2C) paths differ—complicate the feasibility of accurately tracking connections. If the paths are asymmetric, a middlebox might fail to observe the Server Hello entirely, potentially leaving the connection uncensored and vulnerable to exploitation. Finally, an attacker could still spoof both sides of the connection to trigger the blocking, making it an ineffective defense.

Alternatively, the censor may employ an injection-based blocking mechanism, avoiding packet-dropping based residual censorship. However, this approach also has risks and constraints. For instance, with the current latency associated with decryption (shown in Figure 2), a QUIC Server Initial could reach the client and establish a shared secret, before the injected packet arrives, rendering the injection ineffective.

Defending against this attack is uniquely challenging in QUIC, because the protocol is designed to resist injection-based teardown attacks, motivating the need for residual censorship. At the same time, the connectionless nature of UDP makes spoofing the client Initial trivial, opening the door for availability attacks when residual censorship is employed. Careful engineering will be needed to allow censors to apply targeted blocks in QUIC, while simultaneously preventing availability attacks.

7. Circumvention

As described in Section 3.2, the GFW makes several simplifying assumptions to efficiently parse and block QUIC traffic at line speed. These design choices again demonstrate that the designers and developers of the GFW follow the “worse-is-better” philosophy [31]. Such assumptions come at the cost of reducing the censorship system’s accuracy and robustness, which opens up opportunities for circumvention. We responsibly disclosed circumvention strategies we identified to the anti-censorship and open-source communities.

Use Source Port <= Destination Port. As detailed in Section 3.4, the GFW focuses on client-to-server traffic by ignoring UDP datagrams whose srcport <= dstport. A stopgap solution to bypass this blocking is to use destination ports that are higher than or equal to the source port. For the case of circumvention proxies, one may run the server on a port higher than or equal to the client’s ephemeral port range. Web services could also be run on non-standard higher ports, and provide these to web clients via Alt-Svc fields in HTTP headers or in DNS HTTPS records. An easy and application-independent way to listen on a higher port is to use iptables rules to redirect all traffic sent to a higher port (e.g. 65535) to the current listening port (e.g. 443) using iptables -t nat -A PREROUTING -p udp --dport 65535 -j REDIRECT --to-port 443. This is especially useful for software that cannot change its listening port or cannot listen on multiple ports.

Precede QUIC Client Initial With Any UDP Datagram. The GFW’s QUIC censorship mechanism relies on the assumption that the QUIC client Initial is the first packet in a new flow. A simple way to bypass this is to precede the client Initial with a UDP datagram with a random payload. For a real QUIC server, the first UDP datagram will be ignored, but the GFW will not be able to parse the SNI value from the first packet and exempt the flow. The subsequent client Initial packets will not be inspected and the connection will be established. We confirmed this defense works against the GFW to exempt connections from blocking by sending a UDP datagram with random payload before the QUIC client Initial. We also tested against the Chromium Quiche [35] QUIC server implementation to verify it ignores random UDP payloads.

Connection Migration. QUIC’s connection migration capability leverages connection IDs to maintain sessions across network changes. The GFW employs a selective filtering strategy: it permits the initial QUIC packet but blocks subsequent packets from client to server, while not monitoring connection IDs. Since server-to-client packets remain unblocked, clients that complete 1-RTT handshakes before the blocking is activated and then migrate to a different network 4-tuple (source IP, source port, destination IP, destination port) can bypass the GFW.

A related approach is presented in QUICstep [44], which introduces a connection migration technique designed to circumvent QUIC censorship. This method exploits QUIC’s connection migration capability by performing the QUIC handshake over a secure channel, which may have low bandwidth and high latency. After successfully completing the handshake, the connection migrates to a regular communication channel so that all data is fully encrypted.

QUIC Client Initial Fragmentation. A QUIC client Initial message can be sent either as multiple UDP datagrams or as a single UDP datagram containing multiple QUIC frames. As of January 2025, the GFW does not reassemble a TLS Client Hello when it is split across multiple UDP datagrams or fragmented into multiple QUIC frames within a single UDP datagram. This behavior can be leveraged to circumvent the GFW’s QUIC censorship by splitting the SNI across multiple QUIC CRYPTO frames in the client Initial message.

Notably, Chrome’s Chaos Protection mechanism [19], introduced in 2021, disperses the QUIC client Initial message into multiple QUIC frames that are shuffled across the UDP datagrams. Additionally, Chrome (since version 124 [12]) supports post-quantum key agreement in TLS 1.3, that enables the use of ML-KEM and Kyber keys. Enabling this feature fragments the QUIC client Initial into multiple UDP datagrams due to the larger key size exceeding the maximum QUIC packet size. These features happen to exploit the GFW’s inability to reassemble fragmented QUIC client Initial packets, allowing Chrome packets to bypass the GFW’s QUIC censorship.

Encrypted Client Hello (ECH). ECH [51] allows a client to encrypt part of their TLS Client Hello message to a server with a key obtained via DNS HTTPS record. The SNI extension is thus encrypted, allowing a client to hide it from a censor. Unlike QUIC’s client Initial encryption, ECH encryption is asymmetric and cannot be decrypted by a network observer.

A censor could choose to block all ECH-containing payloads. However, modern browsers have started to send “dummy” ECH payloads in TLS, even when a server does not support it. As of January 2025, the GFW does not block QUIC payloads that contain ECH, unless the outer (decryptable) SNI is to a blocked domain.

Version Negotiation. QUIC’s version negotiation [43 §6] mechanism presents an interesting circumvention opportunity. This process typically begins when a server receives an Initial packet with an unsupported version number. In response, the server sends a Version Negotiation packet and waits for the client to submit a new Initial packet using a supported version. A client can strategically exploit this mechanism by deliberately sending an Initial packet with an unknown version, making the payload of the first packet undecryptable. As a result, subsequent packets in the connection flow are able to bypass the GFW’s filtering mechanisms. The client can then proceed with the handshake using a supported version, effectively circumventing the censorship measures.

Are “Stopgap” Solutions Worth Deploying? While many of these solutions opportunistically exploit implementation details in the GFW, it may not be trivial for China to patch all of these, due to resource constraints and other priorities [5]. In past work, we have seen similar stopgap solutions work for multiple years against censors [66 §8.3]. On the other hand, many of these circumvention strategies can be easily deployed by QUIC-using proxies and circumvention tools, who do not face the same kinds of bureaucratic constraints [5].

Responsible Disclosure. We shared our findings on China’s QUIC censorship and the circumvention strategies with the anti-censorship and open-source communities. In specific, we contacted the developers of Mozilla Firefox [48], Mozilla Neqo library [49], quic-go library [53], Lantern [18], Hysteria [39], TUIC [59], sing-box [54], V2Ray [61], and Xray [68].

Prior to our responsible disclosure to Mozilla, the SNI-slicing feature (implemented through client Initial Fragmentation) had already been included in the Neqo v0.12.0 release on January 27, 2025 for protocol greasing [24, 50]. Mozilla Firefox integrated this feature and enabled it by default in version 137 on April 30, 2025 [24, 47] (configurable via the network.http.http3.sni-slicing parameter in the about:config page), leading to an inadvertent bypass of the GFW's QUIC SNI-based censorship.

TABLE 7: Integration timeline for quic-go v0.52.0 [53]. Following its release on May 23, 2025, popular circumvention tools updated their dependency, which enables SNI slicing by default to bypass GFW’s QUIC SNI-based censorship.


Project	Version	Release Date

sing-box	1.12.0-beta.17	May 22, 2025 [55]

V2Ray	5.33.0	May 26, 2025 [62]

Xray	25.6.8	June 6, 2025 [69]

Hysteria	2.6.2	June 7, 2025 [40]

The quic-go library introduced SNI-slicing in its v0.52.0 release [53] on May 23, 2025 [53]. As summarized in Table 7, this update allows circumvention tools that depend on quic-go to bypass the GFW’s QUIC SNI-based censorship.

As of June 2025, we are working with a major open-source web browser to integrate a complementary circumvention technique (prepending dummy payload before the handshake) for more resilience against the GFW.

8. Discussion

Our findings raise two crucial questions about the GFW’s blocking of QUIC connections: (1) its impact on regular web traffic, and (2) its implications for QUIC-based proxying. When accessing websites, browsers will first connect to servers using HTTP(S)-over-TCP, and only attempt to use QUIC if the server announces to support it (via the Alternate Service header). Consequently, the HTTP Host-based and TLS SNI-based blocking are still the primary mechanisms for blocking web traffic, and only when a website is not censored by these two mechanisms will the GFW’s QUIC blocking come into play. The GFW’s QUIC blocking essentially acts as a secondary censorship mechanism for web traffic.

Focusing on QUIC-based proxies, the growing popularity of tools like Hysteria [39] and ongoing standardization efforts—particularly by the IETF’s MASQUE [41] working group—shows the protocol’s future potential for VPNs and proxies. QUIC’s flow-controlled and multiplexed streams, rapid connection establishment, and support for connection migration offer significant performance gains. By using unprompted authentication in HTTP/3 servers, QUIC tunnels can reside in mainstream HTTP/3 traffic and potentially elude detection even through active probing. However, our results show that the GFW’s SNI-based filtering undermines these advantages early in the handshake process, effectively blocking many QUIC proxies at the outset.

A clear example is Cloudflare’s WARP VPN, which recently started using MASQUE [17] (HTTP/3-over-QUIC proxying) to tunnel traffic. We discovered that the subdomain used for MASQUE was blocked by the GFW, disrupting the VPN client’s startup handshake. This pattern signals an explicit targeting of MASQUE proxies by the GFW. Similarly, Hysteria faces a situation where not only its main project domain v2.hysteria.network is blocked, but users’ custom domains used for Hysteria proxies are also blocked.

9. Conclusion

In response to the GFW’s QUIC SNI-based censorship from April 7, 2024, we conducted measurement experiments to characterize, monitor, expose, and bypass it. We show this new blocking mechanism can be exploited to block arbitrary UDP traffic between hosts inside and outside China. We also propose an off-path circumvention strategy which reduces the GFW’s effectiveness with moderate traffic loads. We collaborate with various open-source communities to integrate circumvention strategies into a major web browser, the quic-go library, and all major QUIC-based circumvention tools.

Acknowledgments

We thank the anonymous shepherd and reviewers for their valuable feedback. Our research was initiated by brave Chinese users who first reported the QUIC censorship, and we are deeply grateful for their courage. We extend our special thanks to the anonymous RQWDKM, who conducted initial measurements and investigation with us, participated in discussions, and provided detailed feedback on this paper.

We are indebted to the many people at Mozilla Neqo and Firefox teams for their invaluable discussions and support.

We also thank the developers and contributors of Hysteria, Lantern, sing-box, TUIC, V2Ray, and Xray, for providing online discussion spaces and for their rapid adoption of circumvention strategies.

Finally, we are grateful to the following individuals, along with many others who prefer to remain anonymous, for their support, feedback, and insightful discussions: Bill Marczak, David Fifield, Jeffrey Knockel, Juraj Somorovsky, klzgrad, nekohasekai, Nick Sullivan, Niklas Niere, and Prateek Mittal.

This work was partially supported by the U.S. National Science Foundation (NSF) under grant number CNS-2145783, until the award was prematurely terminated as part of the agency’s shift in priorities [30], significantly impacting ongoing research efforts.

The work was also supported in part by the NSF under grant numbers CNS-2319080 and CNS-2333965, by a Sloan Research Fellowship, and by the Young Faculty Award program of the Defense Advanced Research Projects Agency (DARPA) under the grant DARPA-RA-21-03-09-YFA9-FP-003. The views, opinions, and/or findings expressed are those of the authors and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.

Ethics Considerations

There are two major ethical considerations in our work: the potential harm of our experiments on network infrastructure and the disclosure of uncovered weaknesses.

Availability Attack. In Section 6, we demonstrated that the GFW could be co-opted to conduct an availability attack against arbitrary Internet hosts. We demonstrated this attack against our own servers to limit the risk of unforeseen collateral harm during our experiments. While the attack does involve spoofing IP packets, the only IP addresses we pretended to be were under our control already. The result of this attack is that for a brief duration, our own EC2 instances were unable to communicate with our server in China.

We also analyze our work under the lens of two ethical frameworks suggested by prior work on computer security and ethics [45]. From a consequentialist ethical perspective, there is negligible risk of harm from this attack. From a deontological view, the choice of attacking only our own hosts limits the involvement of others, and thus our duty to others.

GFW Degradation Attack. In Section 5, we introduced a method to degrade the GFW’s ability to block QUIC connections by sending a large number of QUIC Initial packets. There are several risks associated with this experiment that influenced our experiment design. First, we considered whether it is morally justified to disrupt the GFW, a system that is itself a source of harm [28 §9.c] [28 §9.B] [3, 42], as acknowledged even by its creators [71 §1]. On the one hand, the GFW is not a system we control and disrupting it could have negative or unseen consequences. On the other hand, causing the GFW to fail to censor provides a benefit to Chinese users, as their Internet is otherwise restricted in opposition to their human rights [60]. These considerations led us to conclude that as long as the risk to systems beyond the GFW was minimal, disrupting the GFW itself was morally justified.

However, it is vitally important to consider the risk to other systems. For example, if disrupting the GFW caused all traffic to be dropped, our experiment would risk interfering with normal Internet communications between China and the rest of the world. Indeed, while our analysis in Section 3.1 suggests that the GFW’s QUIC censorship is not purely in-path, we still worried that its in-path element might impact all traffic. However, our observation of the diurnal pattern of censorship effectiveness gave us strong evidence that this was not the case. During the day when QUIC connection volumes are high, the GFW is able to block only a small fraction of connections (Figure 4), but uncensored QUIC and other types of traffic remain unaffected.

Finally, we considered the risk that our experiments could disrupt the network itself. Since we send a large number of QUIC packets, there was the possibility of overwhelming a network link or destination. We took several steps to mitigate this risk. First, we limited our sending rate to 1.5 million packets/second, which consumes under 4 Gbps of bandwidth. We confirmed that our connection to upstream Internet providers was at least 40 Gbps, and transnational links are typically 100 Gbps or multi-Tbps, meaning our traffic would be only a small fraction of their capacity. Second, we limited the TTL of packets to ensure that they would pass the GFW but not reach the destination network. This approach limits the impact to only large core Internet links which can easily handle this relatively minor traffic volume. Third, we continuously monitored several health metrics across the networks we tested, including ZMap scans and bidirectional connectivity tests. We observed no network degradation during our experiments, indicating that we did not overwhelm the network.

From a deontological perspective [60 §4.1], we must consider the rights of others (e.g. Internet users in China), as well as our intentions during the study. From this view, our research methodology confronts a direct conflict between two moral duties. On the one hand, we are obligated to avoid (potentially) interfering with the network resources of others. On the other hand, our experiments also fulfill a duty to prevent an ongoing harm: namely, the censorship of the GFW. We argue that the latter constitutes a higher moral imperative and thus decide to proceed with our experiments. From a consequential perspective [60 §4.1], we must weigh the benefits against the harms. The benefits are that our attacks reveal a way to restore users’ access to information, while minimizing the risk of harm to other networks and hosts.

Disclosure. Vulnerability disclosure is a standard practice for ethical security research, as it helps improve the system under study and to protect individuals impacted by the vulnerable system from attacks. In our case, disclosure is ethically complex because we are studying a system that would be harmful to improve (the GFW). On the other hand, it is important to protect Internet users that may be subject to attacks through vulnerabilities in the GFW. We carefully considered what—if any—vulnerabilities to disclose to protect users, but not improve the GFW’s ability to censor. Our goal is to maximize benefits by protecting users, while minimizing the risk of harm in “helping” China strengthen their censorship.

Given these considerations, we decided to disclose the availability attack (Section 6) to the censor, as it can be used to harm users. On Jan. 22, 2025, we disclosed this vulnerability to CNCERT and Fang Binxing—widely recognized as “the father of the GFW” [34]—and recommended that the vulnerable QUIC censorship device be removed. A copy of the email is included in Appendix C. To ensure clarity, we contacted the censors via an email in both English and Chinese, and provided links to two private webpages (one in each language) that detailed the attack. Although we did not receive any response or formal acknowledgment, we observed a total of 37 visits to the private English webpage (and none to the Chinese version) between Jan. 24 and Feb. 24, 2025, suggesting that our message was received. This lack of direct engagement from CNCERT shows the challenge of vulnerability disclosure with Internet censors [9 §VIII]. Chinese authorities rarely admit the existence of censorship [57], let alone acknowledge its risks or consider dismantling their censorship systems.

However, starting Mar. 13, 2025, we observed a change in the GFW’s behavior: QUIC traffic originating from outside China could no longer trigger the blocking. This change partially mitigates the vulnerability, as the availability attack can no longer be launched from outside China. It’s unclear whether this change was due to our disclosure, though a similar change has been observed in the past following a public disclosure of the GFW’s ESNI censorship [10].

Despite the mitigation, the availability attack remains viable if launched within China. An attacker operating a machine in China (without egress filtering) can still block arbitrary UDP flows between a host in China and any destination outside China, if the attacker’s network path traverses the same GFW node as the victim’s. Since the Chinese censor is unlikely to remove the QUIC censorship devices, which is the only way to fully mitigate this vulnerability, our risk mitigation strategy centers on public transparency. By publishing this paper, we hope to disclose and publicize the vulnerability to raise broader awareness about the security implications and potential harms of large-scale censorship systems [28].

We chose not to inform the censor directly about the degradation attack (Section 5). Instead, we first privately disclosed the vulnerability to anti-censorship communities, followed by a public disclosure with this paper’s publication. We chose this disclosure strategy because the degradation attack affects only the GFW’s infrastructure, not users. A private disclosure to the censor would have afforded them an opportunity to strengthen their censorship mechanisms before the broader anti-censorship community could become aware of and learn from this vulnerability.

While publicizing this vulnerability might motivate the censor to fix a weakness they likely already knew existed (now knowing others are also aware), we believe the value of this public disclosure outweighs such risks. By sharing these insights on the censor’s weaknesses with a broader audience, we can better inform future protocol designs and anti-censorship strategies. For example, the QUIC Initial packet is designed to be encrypted, despite being decryptable by middleboxes, partly to complicate their ability to process it. The GFW’s QUIC censorship system struggled to keep pace with the decryption, demonstrating that even design choices that slightly raise the processing cost can still reduce a censor’s overall effectiveness [5].

No Collection of PII. Our work does not involve human subjects, and we did not collect any personally identifiable information (PII) in any of our data.

Open science

To encourage future work and maintain reproducibility, we have publicly released the code and data from our study. For broader accessibility, this paper is also available in HTML format in both English and Chinese. The project homepage is at: https://gfw.report/publications/usenixsecurity25/en/.

References

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, and A. Houmansadr. How China detects and blocks Shadowsocks. In Internet Measurement Conference. ACM, 2020. URL: https://censorbib.nymity.ch/pdf/Alice2020a.pdf.
D. Anderson. Splinternet behind the Great Firewall of China: Once China opened its door to the world, it could not close it again. Queue, 10(11):40–49, November 2012. URL: https://queue.acm.org/detail.cfm?id=2405036, doi:10.1145/2390756.2405036.
Anonymous. Towards a comprehensive picture of the Great Firewall’s DNS censorship. In Free and Open Communications on the Internet. USENIX, 2014. URL: https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.pdf.
Anonymous and Anonymous. Sharing a modified Shadowsocks as well as our thoughts on the cat-and-mouse game, October 2022. URL: https://github.com/net4people/bbs/issues/136.
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. URL: https://www.usenix.org/system/files/foci20-paper-anonymous_0.pdf.
M. Bishop. HTTP/3. RFC 9114, June 2022. URL: https://www.rfc-editor.org/info/rfc9114, doi:10.17487/RFC9114.
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. URL: https://www.usenix.org/system/files/sec21-bock.pdf.
K. 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. URL: https://www.cs.umd.edu/~dml/papers/weaponizing_woot21.pdf.
K. Bock, iyouport, Anonymous, L.-H. Merino, D. Fifield, A. Houmansadr, and D. Levin. Exposing and circumventing China’s censorship of ESNI, August 2020. URL: https://github.com/net4people/bbs/issues/43#issuecomment-673322409.
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. URL: https://www.usenix.org/system/files/foci19-paper_chai_update.pdf.
Chrome Developers. Chrome 124 — release notes, April 2024. URL: https://developer.chrome.com/release-notes/124.
R. Clayton, S. J. Murdoch, and R. N. M. Watson. Ignoring the Great Firewall of China. In Privacy Enhancing Technologies, pages 20–35. Springer, 2006. URL: https://www.cl.cam.ac.uk/~rnc1/ignoring.pdf.
Cloudflare. Cloudflare Radar – Adoption and Usage Worldwide, 2025. URL: https://radar.cloudflare.com/adoption-and-usage?dateStart=2024-01-01&dateEnd=2024-12-31.
J. R. Crandall, D. Zinn, M. Byrd, E. Barr, and R. East. ConceptDoppler: A weather tracker for Internet censorship. In Computer and Communications Security, pages 352–365. ACM, 2007. URL: http://www.csd.uoc.gr/~hy558/papers/conceptdoppler.pdf.
critical_error. QUIC streams with encrypted_client_hello extensions in QUIC initials are being blocked in Uzbekistan. NTC Party Forum, 12 2024. URL: https://ntc.party/t/13953.
Dan Hall. Zero Trust WARP: tunneling with a MASQUE. URL: https://blog.cloudflare.com/zero-trust-warp-with-a-masque/.
L. developers. Lantern. URL: https://github.com/getlantern.
dschinazi. Chaos Protection in QUIC, 2025. URL: https://quiche.googlesource.com/quiche/+/cb6b51054274cb2c939264faf34a1776e0a5bab7.
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. URL: https://www.icir.org/vern/papers/hold-on.satin12.pdf.
M. Duke. QUIC Version 2. RFC 9369, May 2023. URL: https://www.rfc-editor.org/info/rfc9369.
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. URL: https://www.usenix.org/system/files/conference/foci18/foci18-paper-dunna.pdf.
Z. Durumeric, E. Wustrow, and J. A. Halderman. ZMap: Fast internet-wide scanning and its security applications. In USENIX Security Symposium. USENIX, August 2013. URL: https://www.usenix.org/conference/usenixsecurity13/technical-sessions/paper/durumeric.
L. Eggert. Pull request #2228: feat: Shuffle the client Initial crypto data. https://github.com/mozilla/neqo/pull/2228.
K. Elmenhorst, B. Schütz, N. Aschenbruck, and S. Basso. Web censorship measurements of HTTP/3 over QUIC. In Internet Measurement Conference. ACM, 2021. URL: https://dl.acm.org/doi/pdf/10.1145/3487552.3487836.
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. URL: https://conferences2.sigcomm.org/imc/2015/papers/p445.pdf.
A. L. et al. The quic transport protocol: Design and internet-scale deployment. SIGCOMM ’17. ACM, 2017. doi:10.1145/3098822.3098842.
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. URL: https://gfw.report/publications/ndss25/data/paper/wallbleed.pdf.
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. URL: https://dl.acm.org/authorize?N25517.
N. S. Foundation. Updates on nsf priorities. https://www.nsf.gov/updates-on-priorities, 2025.
R. P. Gabriel. Worse is better. URL: https://dreamsongs.com/WorseIsBetter.html.
gfw-report. Rapid blocking of connections following ESNI triggers, August 2020. URL: https://github.com/net4people/bbs/issues/43#issuecomment-673490763.
P. God. QUIC connection with SNI of *.eu.org has been blocked. Telegram post, 2024. URL: https://t.me/c/1166154022/909198.
J. Goldkorn. Fang Binxing and the Great Firewall. In G. R. Barmé and J. Goldkorn, editors, China Story Yearbook 2013: Civilising China. Australian Centre on China in the World. URL: 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 and related protocol toolkit. URL: https://github.com/google/quiche.
L. Hanson. The chinese internet gets a stronger backbone. 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, and N. Feamster. GFWeb: Measuring the Great Firewall’s Web censorship at scale. In USENIX Security Symposium. USENIX, 2024. URL: 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, and M. Polychronakis. How great is the Great Firewall? Measuring China’s DNS censorship. In USENIX Security Symposium. USENIX, 2021. URL: https://www.usenix.org/system/files/sec21-hoang.pdf.
Hysteria developers. Hysteria. URL: https://github.com/apernet/hysteria.
Hysteria Developers. Hysteria software release. URL: https://github.com/apernet/hysteria/releases/tag/app%2Fv2.6.2.
IETF. Multiplexed Application Substrate over QUIC Encryption (masque), 2025. URL: https://datatracker.ietf.org/wg/masque/about/.
Internet Society. When is the Internet not the Internet?, December 2023. URL: https://www.internetsociety.org/resources/internet-fragmentation/the-chinese-firewall/.
J. Iyengar and M. Thomson. QUIC: A UDP-Based Multiplexed and Secure Transport. RFC 9000, May 2021. URL: https://www.rfc-editor.org/info/rfc9000, doi:10.17487/RFC9000.
W. Jia, M. Wang, L. Wang, and P. Mittal. QUICstep: Circumventing QUIC-based censorship, 2023. URL: https://arxiv.org/abs/2304.01073.
T. Kohno, Y. Acar, and W. Loh. Ethical frameworks and computer security trolley problems: Foundations for conversations. In 32nd USENIX Security Symposium (USENIX Security 23), 2023. URL: https://securityethics.cs.washington.edu/.
madeye. Savoury implementation of the QUIC transport protocol and HTTP/3, 2024. URL: https://github.com/cloudflare/quiche.
Mozilla Developers. Bug 1942325 - update Neqo to v0.12.2 in mozilla-central. https://bugzilla.mozilla.org/show_bug.cgi?id=1942325.
Mozilla Foundation. Firefox Web Browser Source Code. https://github.com/mozilla-firefox/firefox.
Mozilla Foundation. Neqo: Next Generation QUIC Client and Server Library. https://github.com/mozilla/neqo.
Mozilla Neqo Team. Neqo version 0.12.0 release. https://github.com/mozilla/neqo/releases/tag/v0.12.0.
E. Rescorla, K. Oku, N. Sullivan, and C. A. Wood. TLS Encrypted Client Hello. Internet-draft, March 2025. Work in Progress. URL: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/24/.
Sakamoto and E. Wedwards. Bleeding wall: A hematologic examination on the Great Firewall. In Free and Open Communications on the Internet, 2024. URL: https://www.petsymposium.org/foci/2024/foci-2024-0002.pdf.
M. Seemann. quic-go: A QUIC implementation in pure Go (version 0.52.0). https://github.com/quic-go/quic-go/releases/tag/v0.52.0.
Sing-box developers. Sing-box. URL: https://github.com/SagerNet/sing-box.
sing-box Developers. sing-box software release. URL: https://github.com/SagerNet/sing-box/releases/tag/v1.12.0-beta.17.
N. Software. The ephemeral port range. URL: https://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html.
M. Streisand, E. Wustrow, and A. Houmansadr. Where have all the paragraphs gone? detecting and exposing censorship in Chinese translation. In Free and Open Communications on the Internet, 2023. URL: https://www.petsymposium.org/foci/2023/foci-2023-0001.pdf.
M. Thomson and S. Turner. Using TLS to Secure QUIC. RFC 9001. URL: https://www.rfc-editor.org/info/rfc9001.
TUIC Protocol. tuic: Delicately-tuiced 0-rtt proxy protocol. https://github.com/tuic-protocol/tuic.
United Nations Human Rights Council. The promotion, protection and enjoyment of human rights on the Internet. https://www.article19.org/data/files/Internet_Statement_Adopted.pdf, June 2016. Resolution A/HRC/32/L.20.
V2Ray developers. V2Ray. URL: https://github.com/v2fly/v2ray-core.
V2Ray Developers. V2Ray Core software release. URL: https://github.com/v2fly/v2ray-core/releases/tag/v5.33.0.
ValdikSS. Restriction HTTP/3 (QUIC) - post 10. ntc.party, Mar 2022. Accessed: 2024-05-27. URL: https://ntc.party/t/1823/10.
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. URL: https://www.cs.ucr.edu/~krish/imc17.pdf.
P. Winter and S. Lindskog. How the Great Firewall of China is blocking Tor. In Free and Open Communications on the Internet. USENIX, 2012. URL: 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, and E. Wustrow. How the Great Firewall of China detects and blocks fully encrypted traffic. In USENIX Security Symposium. USENIX, 2023. URL: https://www.usenix.org/system/files/sec23fall-prepub-234-wu-mingshi.pdf.
M. Wu, A. Zohaib, Z. Durumeric, A. Houmansadr, and E. Wustrow. A wall behind a wall: Emerging regional censorship in China. In Symposium on Security & Privacy. IEEE, 2025. URL: https://gfw.report/publications/sp25/data/paper/paper.pdf.
XRay developers. XRay. URL: https://github.com/XTLS/Xray-core.
Xray Developers. Xray software release. URL: https://github.com/XTLS/Xray-core/releases/tag/v25.6.8.
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. URL: https://dl.acm.org/doi/pdf/10.1145/3517745.3561461.
B. Yan, B. Fang, B. Li, and Y. Wang. Detection and defence of DNS spoofing attack, November 2006. URL: https://github.com/user-attachments/files/18172972/Yan2006a.pdf.

A. Blocking Latency Across the Day

Figure 10 shows how the GFW’s blocking latency varies across the day. Blocking latencies are the time taken for the GFW to block a connection after observing a QUIC Initial packet with a blocked SNI. It is measured as the time difference between the time the client sends the QUIC Initial packet and the time the client sends the first UDP datagram that gets dropped by the GFW.

Figure 10: The box plot shows the distribution of the time taken for the GFW to block a connection. The x-axis is in log scale. The green triangle marks the mean value; and the whiskers shows the minimum and maximum values.

The minimum blocking latencies are consistently below 100 ms during the day, likely bounded by the GFW’s internal processing and reaction speed.

The maximum blocking latencies vary throughout the day, potentially influenced by the number of QUIC connections being processed by the GFW (as also hinted in Section 5). During periods of generally lower human activity, typically in the early morning hours (12 AM to 6 AM), it takes relatively less time for the GFW to block connections, with a mean blocking latency of approximately 150 ms. In contrast, during peak human activity hours (7 AM to 11 PM), the mean blocking latency can go up to 800 ms, with a max blocking latency of 7,000 ms observed at around 3 PM.

B. Port-based Traffic Filtering

To further confirm our findings from Section 3.3 regarding the GFW’s filtering heuristic based on the source and destination ports, we extended our analysis to a wider range of ports. Using the same methodology, we examined a wider range of ports, from 1 to 65535, with a step size of 1,000. We also included the port 65535 in our test and analysis.

Figure 11 illustrates the GFW’s blocking behavior across this expanded port range. These results corroborate our initial findings: the GFW does not track or block UDP flows if the source port of the QUIC Initial packet is less than or equal to its destination port.

Figure 11: The censor does not track or block UDP flows if the source port of the QUIC Initial packet is less than or equal to its destination port. This rule applies to all port numbers, ranging from 1 to 65535.

C. Vulnerability Disclosure Email to the Censors

As introduced in Section 9, we decided to disclose the availability attack (Section 6) to the censor, as this attack may exploit the GFW to cause additional harm to users. On January 22, 2025, we sent out the following email to CNCERT/CC and Fang Binxing who has been widely known as “the father of the GFW” [34]. We recommended removing the vulnerable QUIC censorship device and deploying egress filtering to prevent IP spoofing attacks. We wrote this email in both English and Chinese, and provided links to two private webpages, one in English and one in Chinese, with details of the attack. Although we did not receive any response or formal acknowledgment, we observed a total of 37 visits to the private English webpage (and zero visits to the Chinese one) between 2:04 PM (UTC+8) on Friday, January 24 and 9:35 AM (UTC+8) on Monday, February 24, 2025.

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.


## Mitigation

Due to the potential harm from this attack, we urge taking immediate action to address this issue. As UDP is a connectionless protocol, it is difficult to prevent spoofing attacks. Therefore, the most complete mitigation against this attack is to disable the censorship middlebox responsible for blocking UDP connections. In addition to enabling these harmful attacks, the GFW also violates human rights by preventing access to information.

A less complete mitigation is to deploy egress filtering to prevent IP packet spoofing, but as long as an attacker can find one location where they can spoof packets, even outside of China, this attack will still be feasible. Given this, we recommend 1) immediately and permanently disabling the QUIC censorship national firewall and 2) deploy protections such as egress filtering to edge networks to limit IP spoofing.

Thank you for your attention to this critical matter. We remain available to provide additional technical details or answer follow up questions to ensure this issue is addressed promptly.

Sincerely,
Team

---
[The Chinese translation of the email above redacted.]
[The URL to the Chinese responsible disclosure page redacted.]
---
Example command:
nc -s $SRC_IP -p $SRC_PORT -vnu $DST_IP $DST_PORT <<<$(xxd -r -p \
<<< "c600000001104ebdf7c473c1c15db3ffa4534f5b3158102154b19e765d7a3caa33a20b92c56da30040e182
dcfd47c61c7fff552b8c61053c0c91ab148d199277a3b459519768aa6c79533eecd2d2e678dbac45dadef121d1d
3f5f56454c6b9305c45d919053fea8c1c1bd950d1fd14ee770d8312d10c03a18aea463538d721af70b4e732037e
ac620f361d0435114eea55204caa685dd33f8b2cb1dac6568b320e2d348f77e72a4c150ed5ac27a9ce9edf696ea
929baf34f28598320b0baa993fbdeddf7c45b724eee8f6fa9c7860a973f0138777422347161743bc6d36e519951
47d7f6d2cf4a398b7ea1066f77bcdee89e760d2568bc3c9bb8f7d5c43482a11a7d696c7dc62fe6ecade80000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000")

揭示并绕过中国防火长城基于SNI的QUIC封锁机制

Thu, 31 Jul 2025 00:00:00 +0000

揭示并绕过中国防火长城基于SNI的QUIC封锁机制

Ali Zohaib^∗

University of Massachusetts Amherst

Qiang Zao^∗

GFW Report

Jackson Sippe

University of Colorado Boulder

Abdulrahman Alaraj

University of Colorado Boulder

Amir Houmansadr

University of Massachusetts Amherst

Zakir Durumeric

Stanford University

Eric Wustrow

University of Colorado Boulder

^* Ali Zohaib 和 Qiang Zao 对本工作贡献相当。

摘要

尽管 QUIC 握手数据包是加密的，中国防火长城（GFW）自2024年4月7日起，已开始封锁针对特定域名的 QUIC 连接。在此次研究中，我们对 GFW 针对 QUIC 的审查行为进行了测量与分析，以理解其封锁方式以及封锁对象。我们的测量结果显示，GFW 能够大规模解密 QUIC Initial 数据包，应用启发式过滤规则，并采用与其他审查机制不同的封锁名单。我们揭示了这一新系统的一个关键缺陷：解密带来的计算开销在中等流量负载下即会削弱其封锁效果。我们还展示了该审查机制如何被滥用，以阻断中国与全球任意主机之间的 UDP 流量。我们与多个开源社区合作，将绕过封锁的策略集成进一款行业领先的浏览器、quic-go 库以及所有基于 QUIC 的主流翻墙工具中。

1. 引言

自 2021 年标准化以来，QUIC 已迅速成为主流互联网协议。它现在是 HTTP/3 [7] 的加密基础，并且在 2024 年，Cloudflare 估算超过 30% 的网页请求使用了 QUIC [14]。QUIC 的流行也给审查者带来了新挑战，他们必须调整以往的技术来适应这一新协议。此前，审查者通常会直接封锁整个QUIC协议 [25, 70 §5.2]，但 2024 年 4 月，用户首次报告中国的防火长城（GFW）开始针对特定域名封锁 QUIC 连接 [33]，类似于其基于 SNI （服务器名称指示）的 TLS 流量审查 [11, 37]。

对特定网站的 QUIC 连接进行审查，在国家层面极具挑战性，因为 QUIC 加密了所有数据包，而相较之下 TLS 协议则会以明文发送目标服务器名称。在 QUIC 中，即使是第一个握手消息（QUIC client Initial）也是加密的，尽管被动网络观察者可以推导出密钥。这意味着，若审查者希望基于 SNI 字段封锁 QUIC 连接，就必须解密每个 QUIC 连接的首个数据包以获取用户的目标站点。因此，反审查社区亟需了解 GFW 的新审查设计与实现细节，以便及时更新绕过策略。

在本工作中，¹我们测量了中国针对 QUIC 的新型检测与封锁能力——中国是全球首个对 QUIC 进行全国范围的检测与定向审查的国家。我们证实中国能够大规模解密并检测 QUIC 连接的首个数据包。通过一系列实验，我们推断出 GFW 处理 QUIC 连接的规则和高层解析逻辑。例如，我们发现 GFW 会忽略源端口小于或等于目标端口的 QUIC 数据包，这很可能是为了仅检测客户端发起的流量而作的优化。

¹ 项目主页：https://gfw.report/publications/usenixsecurity25/en

我们通过类似 traceroute 的测量方法，发现进行 QUIC 审查的设备与现有 GFW 设备位于网络的同一跳，表明它们可能共用基础设施或有类似的管理体系。尽管如此，我们测量了会触发 QUIC 审查的域名集合，发现 GFW 的 QUIC 封锁名单与中国用于 TLS、HTTP 或 DNS 审查的名单有显著不同。具体来说，QUIC 封锁名单的域名数量大约是 DNS 封锁名单的 60%。令人惊讶的是，其中大量域名甚至并不支持 QUIC，原因尚不明确。

我们进一步证明，中国的定向 QUIC 审查可以被“压垮”，导致 GFW 无法完全封锁 QUIC 连接。这揭示了 GFW QUIC 审查机制的一个可被利用的缺陷：攻击者只需发送适量的 QUIC Initial 数据包（即使目标是未被封锁的域名），就能让 GFW 忙于处理，从而大幅降低对被封锁域名的拦截率。

最后，我们展示了 GFW 的 QUIC 审查系统是如何置全国范围的主机于被攻击的风险之中的。我们提出了一种可用性攻击，利用GFW的 QUIC 审查机制阻断中国任意主机与境外任意主机之间的 UDP 通信。例如，该攻击可用于阻断中国全境对境外所用 DNS 服务器的访问，导致大范围的互联网中断。我们以位于全球各地的我们自己的服务器为目标，进行了攻击实验，结果显示，攻击者仅需一台处于不对伪造源IP的数据包进行过滤的网络中的主机，即可阻止全球大多数主机与我们在中国的观测点主机间的通信。鉴于该漏洞的严重性，我们已向中国国家互联网应急中心（CERT）进行了披露。最后，我们讨论了该发现对反审查社区的意义，以及在对抗有害行为者（如 GFW）时，进行漏洞利用的复杂伦理问题。

2. 背景介绍与相关工作

QUIC 协议。QUIC 是一种基于 UDP 的网络协议，最初由 Google 开发 [27]，后由 IETF 于 2021 年标准化为 RFC 9000 [43]。QUIC 类似于 TLS，但建立在 UDP 之上，能够降低延迟，并支持由浏览器控制的拥塞控制。QUIC 被采纳为 HTTP/3 [7] 的加密基础。2024 年，Cloudflare 估算超过 30% 的网页请求使用了 QUIC [14]。QUIC 也为反审查社区带来了新的变化，因为它对所有数据包进行加密，以防止中间盒的跟踪和篡改 [27 §3]。

QUIC Client Initial。QUIC 握手的第一个数据包是 Client Initial 数据包。由于 QUIC 数据包从一开始就被加密，但尚未完成密钥交换，初始数据包使用从目标连接 ID（DCID）和特定版本的 salt 派生出的密钥加密 [58]。这两个字段都以明文形式出现在 QUIC client initial 数据包中，使得服务器（以及网络观察者）能够解密其载荷。因此，这种加密并不能提供机密性或完整性，但可以防止路径外的数据包伪造攻击。

一旦初始数据包的载荷被解密，就会暴露出一个或多个 CRYPTO 帧，帧中包含 TLS 1.3 Client Hello 消息，其中列出了客户端支持的密码套件和 TLS 扩展。通常，其中一个 TLS 扩展就是服务器名称指示（SNI），用于指定客户端试图连接的主机名。由于初始密钥可以被任何网络观察者计算出来，TLS Client Hello 及其中的明文内容（包括 SNI）都可以被解密。

QUIC 封锁。2021 年，Elmenhorst 等人发现，虽然伊朗和中国的许多 QUIC 网站无法访问，但这并非由于基于 SNI 的审查。实际上，伊朗是通过封锁这些 QUIC 终端的 UDP 流量 [25 §5.2]，而中国则同时封锁了这些终端的 TCP 和 UDP 流量 [25 §5.1]。2022 年 3 月，ValdikSS 发现俄罗斯 TSPU 封锁了所有使用 QUIC 版本 1（0x00, 0x00, 0x00, 0x01）、目标端口为 443 、且载荷长度至少为 1001 字节的 QUIC 连接 [70 §5.2, 63]。2024 年 12 月，乌兹别克斯坦封锁了带有加密 Client Hello（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 请求，GFW 会向被封锁域名的查询注入伪造响应包。对于 HTTP(S) 流量，GFW 会对 TCP 连接进行有状态的检测，并在检测到被审查域名（出现在 HTTP Host 头或 TLS SNI 扩展字段中）时，注入伪造的 RST 包 [67]。随后会GFW有一段“封锁残留”期(residual censorship)，其间主要通过注入伪造的 SYN+ACK 和 RST 数据包阻断连接，最新研究表明GFW也可能在此期间采用丢包手段阻断连接 [37 §5.4, 10]。

3. QUIC 封锁机制

本节我们探讨 GFW 如何检测并封锁包含特定域名的 QUIC 连接。我们发现，GFW 会基于 client Initial 包中的 SNI 字段进行封锁，无论服务器 IP 地址为何。GFW 检查 UDP 流的首个数据包，如果该数据包为QUIC client Initial，且其中的SNI在 QUIC 专用封锁名单上，那么GFW会在之后的 3 分钟内丢弃从客户端到服务器相应端口的后续所有UDP数据包（见图 1）。

图 1：QUIC SNI 审查机制概览，包括决策流程、首包解密、基于 SNI 的过滤，以及针对被标记连接触发的残留封锁。

实验设置与测量点。我们在中国境内外部署了一组测量点，支持双向测试穿越 GFW 的连接。中国境内共部署了 7 个测量点：北京 4 个，广州 2 个，上海 1 个。选择这些地区是因为它们是中国主要的互联网交换点（IXP），GFW 也被证实部署于此 [52 §4.5, 36, 28 VI.C]。这些测量点分别托管于腾讯云（AS45090）和阿里云（AS37963）。境外测量点分布于新加坡（AS16509）、圣何塞（AS14618）、旧金山（AS14061）、弗吉尼亚北部（AS14618）、开普敦（AS16509）以及一所美国大学（AS32）。

我们基于 Quiche [46]开发了可灵活构造特定的 client Initial 包的QUIC 客户端。由于我们观察到无论服务器是否响应，只要客户端发的数据包经过GFW就会触发封锁，因此实验中服务器仅运行 tcpdump，而非真正的 QUIC 服务端。为确保测量准确且避免干扰，服务器端配置了 iptables 规则，丢弃所有发往客户端的 ICMP 包。

3.1. QUIC 连接封锁

在检测到包含应被禁止的 SNI 的 QUIC Client Initial 消息后，GFW 会丢弃后续所有与触发包具有相同源 IP、目的 IP 及目的端口的 UDP 数据包。我们通过从中国三个测量点向美国服务器发送 QUIC 版本 1 且 SNI 为 google.com 的 Initial 消息发现，该消息能够到达服务器，但随后客户端到服务器方向的任何 UDP 数据包在 180 秒内均被该审查系统丢弃。

在此期间，即便客户端从不同源端口向相同服务器端点（相同目的 IP 与端口）发送 10 字节随机数据包，GFW 也会同样丢弃。然而，若将随机数据包发送至服务器上的新的目的端口，则不会被丢弃，这表明 GFW 基于三元组（源 IP、目的 IP、目的端口）进行封锁，以防止客户端仅通过更改源端口就可以简单地绕过审查。我们通过让服务器在接收 QUIC Client Initial 消息后发送 Server Initial 消息及携带10 字节随机负载的 UDP 数据包，进一步确认了该封锁仅发生在客户端到服务器的方向；而服务器发送到客户端的数据包并不会被丢弃。

一个数据包即可触发残留封锁。与此前文献中记录的 GFW 对 TLS‑SNI 的封锁 [38 §3.1] 需要至少检测到两个数据包（SYN包后跟 PSH/ACK包）不同，QUIC 的封锁机制仅需单个包含被封锁 SNI 的Client Initial 数据包即可激活。这是已知首例 GFW 针对基于 UDP 协议实施的残留封锁。尽管 GFW 早前通过注入伪造数据包来审查 UDP 上的 DNS 流量 [4, 6, 38]，但此前并未以丢包方式阻断 UDP 协议流量。这或许因为如要具备丢弃数据包的能力，审查设备须串联部署在链路中，而先前基于注入伪造数据包的审查方式则仅需让审查设备并联部署在链路上，并复制一份数据流到审查设备的链路上即可。GFW残留丢包的行为引入了新的可用性攻击漏洞，攻击者可利用 GFW 阻断国内外任意主机间的通信。我们将在第 6 节深入讨论此攻击。

双向不一致封锁。我们起初的实验结果显示，进出中国的流量均可触发QUIC封锁，但GFW的这一特征在 2024 年 9 月 30 日后发生了变化。此后，从国外发往中国大多数测量点的QUIC流量已不再触发封锁，发往北京和广州的流量除外。

封锁延迟。我们的实验显示，GFW从检测到包含被封锁 SNI 的 QUIC Client Initial 数据包到其开始丢弃数据包之间存在短暂延迟，这使得一些数据包能够到达服务器。GFW 未能即时丢弃触发封锁的 Initial 包，反映出其具有并联部署设备的特征 [64 §2.1]。结合其串联部署才会拥有的丢包能力，我们认为其部署架构为混合型，类似于 GFW 在封锁 TLS ESNI 流量的时采用的部署架构 [32]。

为精确测量此封锁延迟的时长，我们采用了与 2020 年一项研究相似的方法，该项研究测量了GFW对 TLS ESNI流量封锁的延迟 [32]。具体而言，我们测定在QUIC Initial 数据包触发封锁后，服务器还能在后续的多长时间里接收到客户端发来的数据包。

我们在北京测量点进行了为期一天的实验，以确定 GFW 对 QUIC 的封锁延迟。在每小时头五分钟内，我们向位于新加坡的控制服务器发起 25 条 UDP 流（每条流的的源端口和目的端口均不同），我们在每条连接中以 100 包/秒的速率持续发送独特的 10 字节负载。实验进行至第 5 秒时，我们从不同源端口向这 25 个目的端口分别发送带有被封锁 SNI google.com 的 QUIC Initial 包，从而触发 GFW 对这 25 个目的端口（无论源端口如何）的封锁，进而使持续发往服务器的 10 字节负载被GFW丢弃。

在服务器端，我们捕获数据包并寻找在 UDP 数据包间存在至少 120 秒间隔的连接，以判定 QUIC Client Initial 包成功触发了封锁。对于这些触发了封锁的连接，我们对比了触发封锁的Client Initial包的发送时间与服务器收到的最后一个 UDP 负载包的发送时间，该时间差即为封锁延迟（精确到 10 毫秒）。

如图 2所示，封锁延迟范围在 60 毫秒至 7.5 秒之间。超过 90% 的连接在一秒内被阻断，但仍有少数存在较长延迟。我们假设延迟差异源于 GFW 需处理的 QUIC 流量的大小（详见附录 A）。我们在第 5 节探讨如何利用GFW的此特性来削弱其封锁 QUIC 流量的能力。

图 2：CDF 显示 GFW 从观察到需要被审查的QUIC流量到开始丢弃后续数据包所需时间的分布。在超过 90% 的情况下，连接在一秒内被封锁；实验中观测到的延迟的最小值为 0.06 秒，最大值为 7.5 秒。

3.2. 流追踪逻辑

与具有明确三次握手以标志新连接开始的 TCP 不同，UDP 是无连接的，且无任何明显的传输层握手，这使得中间盒难以识别新的 UDP 流的起始。虽然可通过连接 ID（CID）跟踪 QUIC 连接，但我们发现 GFW 并未使用 CID。相反，GFW 使用 UDP 四元组（源 IP、目的 IP、源端口、目的端口），并在其流追踪系统中采用60 秒超时的设定以维护连接状态。我们的结论基于这样一个事实：只有当 UDP 流的首个数据包是带有被封锁 SNI 的 QUIC 客户端 Initial 消息时，GFW 才会封锁该流；若有其他 UDP 包先行，则不会触发封锁。

在北京的一个测量点，我们向美国服务器发送了一个带有10 字节随机负载的 UDP 包。然后等待一定的时间后，在同一UDP流中每隔一秒发送三个 QUIC 客户端 Initial 消息。我们重复该实验，每次将发送随机负载包与发送客户端 Initial 包之间的延迟增加一秒，直至触发封锁（即 180 秒内没有数据包到达服务器）。

我们发现，当首次随机负载包与客户端 Initial 包之间的延迟达到 60 秒时就封锁就会被触发，这表明该随机 UDP 流的状态被追踪了 60 秒。超过此超时窗口后发送的 QUIC Initial 包可以触发封锁，说明 GFW 已重置该流状态，并将之后的 Initial 包视为新流。

无 UDP 重组。我们发现 GFW 不会重组跨多个 UDP 数据包分片的 QUIC Initial 包。鉴于该设计于 2024 年 4 月 7 日部署时，很少有 QUIC 客户端发送大于单个 UDP 数据包的 Initial 包，此设计可能合理。然而，如第 7 节所述，自 2024 年 9 月 13 日 Chrome 引入一系列对 Initial 包的更改后，这些包变得过大，无法装入单个 UDP 数据包，进而使 GFW 只能在首个数据包中出现 SNI 扩展时才能够封锁QUIC流，从而降低了GFW封锁的有效性。

3.3. 源端口须大于目的端口

我们发现向美国服务器发送带被封锁 SNI 的 QUIC Client Initial 包并不总会触发封锁。为进一步调查，我们进行了多次实验以确定审查器过滤 QUIC 连接的具体规则。

我们选择 401 至 450 的端口范围，端口间间隔为 1。从北京测量点向美国服务器发送带 SNI值为 google.com 的 QUIC Initial 消息，枚举该端口范围内所有源端口与目的端口的组合。每次发送后，等待 1 秒，然后每隔 1 秒发送五个带独特 10 字节负载的 UDP 包。该过程重复 10 次，每次使用分配给服务器的 /28 子网中的不同目的 IP，并在重复每次测量时等待 5 分钟以避免前次连接的残留封锁依旧存在。对于每个端口对，我们记录被封锁（即无后续 UDP 包到达）和未被封锁的连接数量。

如图 3 所示，当源端口号 ≤ 目的端口号时，GFW 不会封锁连接。但如果封锁封锁能被触发，其封锁情况并不一致，表明GFW执行规则时存在变动。我们对 1 至 65535 全端口范围以 1000 为间隔重复实验，发现该规则在所有端口范围内均保持一致（详见附录 B）。

图 3：当 QUIC Initial 包的源端口 ≤ 目的端口时，GFW 不予封锁。该实验于 2024 年 12 月 2 日在中国北京测量点进行。

GFW 限制需检查的连接数量。 GFW应用此基于端口的启发式规则，来减少其需要检查的连接数量。由于大多数客户端会选择较高的临时端口 ² 并连接至较低的知名端口（如 443），GFW 可通过忽略源端口低于目的端口的数据包，以快速忽略可能的服务器到客户端流量。

² Linux 主机的临时端口范围通常为 32768–60999，macOS 与 Windows Vista 及更高版本为 49152–65535。[56]

了解到GFW采用了此规则后，我们自然的产生了两个疑问：1）采用此规则能够帮助GFW快速地忽略多少网络流量？2）采用此规则会导致GFW漏检了多少 QUIC Initial 包？为评估GFW的效率与漏报率，我们从美国某大学网络 TAP 收集 UDP 流，并分析源/目的端口分布。

表 1 显示了 2025 年 1 月 22 日 8:00–9:00（太平洋标准时间，UTC-8）期间，美国某大学 TAP 上观察到的 QUIC Initial 包和 UDP 数据包按源/目的端口的分布。审查器仅在 UDP header 的 sport > dport 时进一步考虑流追踪，使其仅需为约 30% 的 UDP 数据包查表，就可以捕获超过 90% 的 QUIC Initial 包。GFW 实际需要尝试解密的 UDP 包的比例则比30%更低：如第 3.2 节所述，GFW 仅解析 60 秒内未见的流（五元组：源 IP、目的 IP、源端口、目的端口、UDP 协议）的首个 UDP 数据包的负载。

表 1：2025 年 1 月 22 日 8:00–9:00（太平洋标准时间，UTC-8）期间，美国某大学 TAP 上按源/目的端口统计的包计数分布。GFW仅在 UDP 包的 sport > dport 时进行流追踪，使其能捕获超过 90% 的 QUIC Initial 包，却仅查表约 30% 的 UDP 数据包。


	QUIC Initial 包	UDP 数据包

sport > dport	6.7 百万	(92.3%)	37 亿	(29.8%)

sport < dport	0.6 百万	(7.6%)	84 亿	(68.0%)

sport = dport	4.6 千	(0.06%)	27.7 百万	(2.2%)

3.4. 日间封锁模式

图 3 中的封锁情况表明，连接并非始终被封锁，封锁具有非确定性。为探究此现象，我们从不同测量点进行了为期一周的实验，观察全天及所有目的端口的 QUIC 连接封锁频率。我们从中国的三个测量点向美国服务器每次并发 1000 条QUIC连接（即每 5 秒从三个不同地点向美国服务器的 10 个 IPv4 地址的所有端口发送一个 SNI 值为google.com 的 QUIC Client Initial 包，随后等待 1 秒后发送 5 个带特定 10 字节负载的 UDP 包）。我们在所有情况下均确保源端口大于目的端口（参见第 3.3 节）。若在 QUIC Initial 后服务器未收到任何 10 字节后续负载包，则将该连接标记为被封锁。我们随后按小时汇总各地客户端的数据，计算封锁连接的百分比。

封锁概率受日间不同时段的影响。如图 4 所示，对来自三座城市的流量的封锁均呈现明显的日间模式：封锁率在凌晨时段达到峰值，白天下降至最低。北京的封锁率始终最高，其次为上海和广州。该模式表明，封锁率受中国网络流量使用情况的影响，在网络流量低峰期封锁最为严重。

图 4：来自中国三大城市的客户端到美国服务器的 QUIC 连接封锁百分比随时间的变化（中国标准时间 CST，UTC+8），实验日期为 2024 年 11 月 15 日至 22 日。

我们在此假设此现象源于 GFW 在任意时刻仅能处理有限流量。由于大规模解密 QUIC Initial 包的运行成本很高，使得封锁率对网络负载敏感，而负载随时段波动。先前研究也在 GFW 的关键词过滤和 DNS 注入中观察到日间封锁模式 [4 §7, 15 §3.2]，表明GFW受计算能力限制而在网络流量高峰期审查效率下降。鉴于解析 QUIC 流量较解析 HTTP 和 DNS 等明文协议更耗费资源，我们将在第 5 节进一步展示，通过持续向 GFW 发送大量 QUIC Initial 包可导致其审查性能下降。

3.5. 审查设备定位

我们使用递增 IP TTL 值的方法进行测距，以定位审查设备。在 QUIC Client Initial 消息中设置特定的 IP TTL值，从 1 开始每次 +1。在每次实验的第一秒，向美国服务器的 53 端口发送 10 个 SNI 值为 google.com 的 QUIC Initial 包，这样只要数据包到达审查设备即可触发封锁。5 秒后，我们再发送 100 个与 Initial 包相同四元组的 UDP 数据包，其负载为 10 字节，包含所用到的 TTL 的初始值。若这 100 个 UDP 包均被丢弃，则表明 Initial 包已到达审查设备。该测量在北京、上海和广州三个测量点各重复 10 次。

如表 2 所示，我们发现上海、北京和广州的 QUIC 封锁分别在 IP TTL 初始值为 9、11 和 12 时触发。触发封锁的那一跳位于上海和广州的中国电信骨干网，及北京的中国联通骨干网。

类似地，我们对 google.com 发起 DNS 查询，使用相同四元组和递增 IP TTL，发送至服务器 53 端口。DNS 注入同样在与 QUIC 封锁拥有相同的IP TTL 初始值时触发，表明这些新QUIC审查设备与现有 GFW 设备位于网络的同一跳。

表 2：traceroute 结果揭示 GFW UDP 审查节点的位置：QUIC 和 DNS 封锁设备所在跳点的信息，及从三个客户端出发的最后一个未被审查跳点的信息。


城市	跳点计数 (QUIC/DNS)	触发封锁前的一跳 (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 Initial 数据包的描述	能否触发封锁？	能否削弱GFW性能？

1	QUIC包packet编号为 1 字节。	✓	✓

2	从 QUIC 数据包中移除最后一个字节。	✕	✓

3	使用错误的版本号和不正确的认证标签。版本号：0x00000002。	✕	✕

4	源连接 ID 和目的连接 ID 的长度均设置为 0x00。	✓	✓

5	源连接 ID 长度为 0xff。	✕	✓

6	CRYPTO 帧长度为 0x00，但仍包含有效载荷。	✓	✓

7	在非 SNI 扩展中包含敏感域名（例如在 ALPN 中包含 google.com）。	✕	✓

8	QUIC 负载仅包含 1 个 CRYPTO 帧，以及多个 PING 和 PADDING 帧。	✕	✓

9	在 TLS Client Hello 中使用带有外部 SNI cloudflare-ech.com 的 Encrypted Client Hello 扩展。	✕	✓

10	QUIC 版本 2 的数据包。	✕	✕

图 5：各实验中QUIC 数据包触发封锁的比例。对每种负载，我们创建 20 个连接，并统计到达目标主机的数量。表 3 中描述的每种负载都对标准 QUIC Initial 包进行了修改，从而揭示了 GFW QUIC 封锁器的解析逻辑。

无需填充。尽管 QUIC 规范要求 Initial 数据包的长度至少为 1200 字节，但我们发现 GFW 并未强制执行此要求。我们发送仅 137 字节的负载就能触发封锁。但由于 GFW 不会注入伪造的数据包，因此不存在放大攻击的风险。

长度字段歧义。规范中定义连接 ID 长度应在 8 到 20 字节之间；但该字段实际支持最多 255 字节。我们发现，将源连ID和目的连接ID的长度均设为 0x00（过短）仍会触发封锁，尽管规范中规定应当在此情况下忽略数据包；而设为 0xff（过长）则未触发封锁，表明 GFW 正确检查了上限。有趣的是，即使 CRYPTO 帧的长度字段为 0x00，只要实际负载中包含被封锁的 SNI，GFW 仍会封锁该负载。这表明 GFW 根据剩余负载推断 CRYPTO 帧长度，因此无法正确处理分片的 CRYPTO 帧（例如 Google Chrome 浏览器所用）。

仅封锁特定版本的QUIC。GFW仅对QUIC版本 1 的数据包（即明文的版本字段为 0x00000001 ）进行解析和封锁。新标准化的 QUIC 版本 2 [21]（其初始加密密钥使用不同的 salt 值）仍然不受封锁。这表明 GFW 要么未更新其对新版本 salt 值的封锁机制，要么仅依赖针对版本 1 的明文字节模式匹配进行检测。

4. 监测封锁名单随时间的变化

在本节中，我们调查 GFW QUIC‑SNI 封锁机制所屏蔽的网站，考察当前被封锁站点、封锁名单随时间的变化，以及 QUIC 封锁名单与 TLS‑SNI、HTTP 和 DNS 等其他审查方式使用的封锁名单的对比。如第 3.4 节所述，GFW 的 QUIC 封锁机制具有非确定性，因此需采用能最小化漏报的实验方法。对每个待测域名，我们从多个测量点发送携带该 SNI 的 QUIC Client Initial 数据包，并进行多次试验。此外，为避免目的端口上的可能的残留封锁，我们不会在180 秒的窗口内重复使用相同的三元组（源 IP、目的 IP、目的端口）进行测试。

我们对 GFW 的 QUIC 封锁名单进行了超过三个月的监测。由于双向封锁的不一致性——具体而言，大多数测量点在 2024 年 9 月 30 日后不再采用双向封锁——我们采用“由内到外”的测量方式。我们在北京（AS45090）部署 10 个测量点并运行客户端的测试程序，在美国某大学（AS32）部署 1 个测量点作为服务器。该服务器分配了一个 /28 IPv4 子网。对每个待测域名，客户端发送一个 QUIC Client Initial 消息至服务器，等待 1 秒后再发送 5 个间隔 1 秒的包含独特 10 字节负载的UDP包。若所有后续 UDP 包均未到达服务器，则将该 SNI 标记为被封锁。

我们使用 2024 年 10 月 2 日获取的完整 Tranco 列表（ID: 664NX）³用于测试，该列表包含约 700 万条完全限定域名（FQDN）。我们承认该列表或无法穷尽所有被封锁域名，但认为基于此类流行域名的大规模测试得出的样本，能代表 GFW 的 QUIC 封锁名单。

³ 该列表可通过以下链接获取：https://tranco-list.eu/list/664NX/full

在每次测试中，北京的 10 个客户端测量点分别向美国服务器的不同 IP 地址发送一个 QUIC Client Initial 消息。基于第 3.3 节的发现，我们使用的源端口始终大于目的端口以触发封锁。实验通过 cronjob 在中国标准时间（CST）凌晨 3 点至 6 点间运行，因为我们观察到此时段的封锁率最高。

由于该时段我们测得的封锁率至少为50%，我们对每个 QUIC Client Initial 测试重复 10 次，以确保封锁名单提取准确率高于 1−(1 − 50%)¹⁰≈ 99.9%。服务器端按天聚合各被封锁 SNI 的数据。实验自 2024 年 10 月 8 日至 2025 年 1 月 15 日持续运行超过三个月。

图 6：2024 年 10 月 8 日至 2025 年 1 月 15 日期间，GFW QUIC‑SNI 封锁 Tranco 列表（ID: 664NX）中的 FQDN 数量。柱状图展示了每周封锁名单的增减情况。

QUIC 封锁名单。按周统计，我们发现 GFW 平均封锁 43.8K 个Tranco 列表中FQDN（见图 6）。在整个实验期间，共观测到 58,207 个不同的 FQDN 被封锁（见表 4）。

表 4：支持 QUIC 的 FQDN 总数、被 QUIC‑SNI 封锁的 FQDN 数量及两者交叉情况。QUIC 封锁测试时间为 2024 年 10 月 8 日至 2025 年 1 月 15 日。


完全限定域名（FQDN）	数量

测试总数（Tranco 列表）	6,955,968

支持 QUIC	1,489,967

曾被GFW QUIC 封锁	58,207

曾被封锁且支持 QUIC	38,451

被 QUIC 封锁的域名可能并不支持 QUIC。我们通过直接发起 HTTP/3 请求以测试域名的 QUIC 支持情况，而非依赖 Alt-Svc 头，因为部分服务器虽支持 HTTP/3‑over‑QUIC，却并未宣告该支持。测量结果显示，58,207 个 FQDN 曾被 QUIC 封锁，其中仅 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 的QUIC封锁名单的。GFW 可能是为了预防这些域名未来会支持 QUIC 而进行了提前封锁，或基于与 QUIC 无关的其他标准做出封锁决策。

4.1. 与其他封锁名单的比较

我们对 GFW 的 QUIC‑SNI 封锁名单与其他既有审查机制的封锁名单（包括 TLS‑SNI、HTTP Host 及基于 DNS 的封锁）进行了对比分析。为评估 TLS‑SNI 封锁名单，我们采用了基于先前工作的实验方法 [11, 37]。我们在北京部署客户端，并在美国部署接收服务器以执行“由内到外”的测量，与 QUIC‑SNI 的测量方向保持一致。我们将服务器配置为接受 TCP 连接但不返回任何数据。每次测试中，完成 TCP 握手后，客户端发送包含测试域名 SNI 的 TLS Client Hello 消息。我们通过监测 TCP RST 包（SNI 封锁的典型特征）来判断封锁情况。相似地，在对于 HTTP Host 的测试中，我们将测试域名包含在HTTP GET 请求的 Host 头字段。

在 DNS 审查测试中，我们遵循先前研究中的成熟方法 [6, 38]。我们将北京客户端配置为向美国受控 IP（无 DNS 服务运行）发送 DNS 查询，从而任何收到的 DNS 应答均可归因于 GFW 注入，以确保准确性。为保证三种测试方法（TLS‑SNI、HTTP Host、DNS）结果的可比性，我们使用了相同的 Tranco 列表域名，并于 2025 年 1 月 9 日至 15 日进行为期一周的测量，收集各封锁名单域名。

图 7 显示了 TLS‑SNI、HTTP Host、DNS 与 QUIC 封锁名单的重叠情况。对于我们测试的 Tranco 域名，DNS 封锁域名数量最多（106,973），其次是 HTTP（105,488）和 HTTPS（102,216）。QUIC 封锁名单显著较小，仅为其他三种名单规模的约 55%。在 58,207 个曾被 QUIC 封锁的域名中，有 11,854 个仅在该协议下被封锁；在这些 QUIC 专属封锁域名中，只有 2,329 个实际支持 QUIC。

图 7：展示 HTTPS、HTTP、DNS 与 QUIC 封锁名单重叠的 Venn 图。各协议封锁名单汇总自 2025 年 1 月 9 日至 15 日一周的测量数据。

我们发现共有 40,447 个域名同时出现在四个封锁名单中，交并比 24.4%。逐一与其他三种协议比较，QUIC 与 HTTPS 的交并比最高，为 46,251 个域名（40.51%），其次是 HTTP 43,191 个（35.84%），以及 DNS 41,484 个（33.54%）。这些结果表明，各审查机制虽各自独立，却存在重叠，共同构成互补体系，最大化 GFW 的封锁覆盖。例如，现代浏览器中的 HTTP/3‑over‑QUIC 会话通常先进行 DNS 查询，再发送 HTTP/2（或更早）请求，最终升级到 HTTP/3 over QUIC。GFW 的审查策略设计在各阶段或组合阶段进行干预，确保用户无法访问被禁止内容。

表 5 显示了 GFW 针对 Tranco 前 10k 域名的 DNS、HTTP、TLS 与 QUIC 封锁名单的 Jaccard 指数（交并比），并与支持 QUIC 的网站以及随机抽取的 500 个 FQDN 样本进行了对比。

表 5：GFW 针对 Tranco Top 10k 域名的 DNS、HTTP、TLS 与 QUIC 封锁名单的 Jaccard 指数（交并比），以及支持 QUIC 网站与 500 个随机 FQDN 样本的比较。


	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 中，我们观察到 GFW 对 QUIC 的封锁在中国网络流量高峰期时效果较差。这使我们假设，我们或许可以发送需要GFW处理的 QUIC 数据包，来有意地降低其封锁效果。尽管我们的实验为了解中国审查系统的设计提供了重要见解，但也引发了多项伦理考量，我们在第 9 节中作了详细的讨论。我们设计实验时确保不会影响用户或其他互联网设备，仅针对 GFW 进行性能降级。

本实验使用三个测量点：一个在中国（北京，阿里云，AS37963），简称 ChinaVP；一个在美国东部（Digital Ocean，AS14061），简称 USVP；另一个在美国密歇根大学（AS36375），简称 StressVP。我们的目标是在中等量级的 QUIC 流量干扰下，测量 GFW 对 QUIC 封锁的有效性。实验分为同时运行的两部分：测量部分与施压部分。

在测量部分，三个测量点按如下配置：ChinaVP 向 USVP 发送一个负载 267 字节的 QUIC Initial 包，其 SNI 字段为被封锁域名 google.com，且目的端口小于源端口（参见第 3 节，以触发封锁）。暂停 1 秒后，在同一流中发送 100 个固定无害载荷（1,111 字节）的 UDP 包。该过程针对 1,000 个不同的源-目的端口对重复执行。若服务器（USVP）收到了 Initial 包以及随后的 95% 以上的数据包，则认为该连接未被封锁。

在施压部分，StressVP 向 ChinaVP 所在 /14 网段内的所有 IPv4 地址发送两类流量，发送速率从 100 kpps 增加至 1500 kpps，每 100 kpps 增量持续施压 7 分钟，每次施压间隔 3 分钟。因选择大网段，单个主机受到的流量冲击被稀释，从而避免影响网络链路或路由器。

为避免施压流量到达终端主机，我们先通过 ZMap 对 /14 网段运行控制 TTL 的 DNS 扫描，解析 example.com，并根据接收到的 164 个 DNS 服务器的响应终止情况，估算各 IP 的距离扫描服务器的跳数。随后将 StressVP 发送的数据包 TTL 设置为最小跳点距离减 1，以保证流量仅到达 GFW。

施压过程中，我们发送两种（使用较小TTL的）流量：QUIC Initial 包和固定长度的随机 UDP 包。QUIC 包使用与 ChinaVP→USVP 相同的 Initial 负载及被封锁的 SNI 以触发 GFW；随机包使用等长的无害随机字节。流量发送由 ZMap 执行，该配置平均对 /14 内的每个 IP 的发送速率不超 6 pps。

本实验在不同日子重复三次（一次按升序速率进行测试，另两次按乱序速率进行测试），期间 StressVP 向 ChinaVP /14 网段发送（TTL 较小的）QUIC Initial 包，同时测量ChinaVP→USVP可通过封锁的连接比例。随后再独立进行三次实验（与 QUIC 施压不同时进行），将 QUIC Initial 包替换为随机载荷，测量相同指标。图 8 显示了实验结果的平均值：随着 QUIC Initial 包速率提升，GFW 对 ChinaVP→USVP 连接的封锁效率下降；而使用随机载荷施压时则不存在该趋势，表明降级效应来自 GFW 处理 QUIC 包的开销，而非处理所有网络流量时的影响。所有实验均在中国凌晨封锁更高效的时段进行（见图 4）。

图 8：我们以 0–1500 Kpps 的速率向 GFW 施加两类等长包：包含被封锁 SNI 的 QUIC Initial 包（审查压力）和随机负载 UDP 包（随机压力）。期间，我们通过发送固定速率的 QUIC Initial 包及 100 个数据包，模拟 1000 条来自中国到美国的 QUIC 连接，计算 GFW 未能封锁的连接比例（审查失败率）。结果表明，随着 QUIC Initial 包速率上升，GFW 的封锁能力下降。我们通过监测出入境双向的非敏感 QUIC 连接的丢包率，以确保压力测试只影响 GFW 而不影响网络链路。

网络监测。实验期间，我们从两方面监测 ChinaVP↔USVP 网络：其一，双向发送非敏感 QUIC 连接，监测两端数据包接收率；其二，使用 ZMap 以 650 pps 速率扫描 /14 网段的 tcp/443 端口，测量响应率。两项指标在实验中均无显著下降，表明我们的施压流量仅对 GFW 产生了降级效果，而对网络链路和路由器的影响可忽略。

逆向分析。除帮助用户绕过审查外，性能降级攻击还能揭示 GFW 的数据处理流程。例如，某 QUIC 负载能导致封锁效率下降，则表明 GFW 至少对该负载执行了部分处理；若某负载对GFW性能无任何影响，则可能表示该负载在触发GFW高开销操作前便被忽略。

表 3 显示了各负载对 GFW 审查效率的降级效果。我们以 1200 Kpps 的速率发送每种负载，并在可绕过封锁的连接比例超过 60% 时判定该负载具备降级作用。结果表明，GFW 会处理所有 QUIC 版本为 1 的数据包，即使该数据包的负载无法被解密或其认证标签无效，也能造成性能降级；但仅有有效认证标签（可以被成功解密）的负载才能触发封锁，由此可推测GFW最“慢”的部分在于解密负载时的密码学运算。

6. 可用性攻击

先前研究表明，残留封锁有时可被攻击者“武器化”用于实施可用性攻击 [8, 9]。在此攻击中，攻击者向目标 B 发送触发审查的请求，并伪造源 IP 为受害者 A的IP地址。如果该请求触发了 A 与 B 之间的防火墙的残留封锁，则两者将无法通信，因为防火墙误以为 A 发送了被禁止的请求。残留封锁通常持续 1至3 分钟 [9, 10, 11, 37, 64, 66]，攻击者可以不断伪造触发审查的数据包以维持阻断。

我们的研究揭示了GFW首次对基于 UDP 的协议实施残留封锁。尽管 GFW 历来通过注入伪造的DNS响应包来封锁 UDP 上的 DNS 流量，但此前未以丢包的方式阻断 UDP 协议流量。这次新出的GFW QUIC 封锁机制因为使用丢包手段而引入了新的可用性攻击向量，影响整个中国。攻击者可利用此攻击阻断中国境内主机与境外服务器间的 UDP 流量，例如阻止所有境外公共或根 DNS 解析器，导致全国范围的 DNS 故障。

本节中，我们使用自己的主机与服务器作为攻击对象，探讨该攻击的可行性。

攻击部署。此攻击需具备 IP 伪造能力，因此需使用不受出口过滤限制的服务器。我们从公共 VPS 提供商处获取一台可伪造 IP 包并在中国境内被接收的主机。在中国境内，我们使用一台位于广州的 VPS 来模拟“受害者”主机，因为该主机入站与出站均可以触发 QUIC 封锁。我们另在中国境外的 32 个区域各部署一台 AWS EC2 实例，用于模拟不同“受害者”。

对每台 EC2 实例，我们先向广州 VPS 发送一个 DNS 查询包，确认请求被接收，表明两主机之间的连接初始时是可用的。

随后，我们从可伪造源IP的攻击服务器，向我们位于广州的 VPS 发送QUIC Initial包。我们将每个包的源 IP 伪造为不同的 EC2 实例的 IP。这些包可以触发 GFW 的残留封锁机制，导致广州 VPS 的特定端口无法与 EC2 实例通信。对于每个 EC2 实例的IP，我们伪造10个包，间隔1秒发送到广州 VPS。我们伪造数据包所经过的路径可能与发自EC2的真实数据包的路径不同，因此这两种包穿过的 GFW 节点也可能不同，这可能导致攻击失效。

与此同时，为了测量攻击效果，我们每 5 秒从各 EC2 实例向广州的 VPS 发送一个 DNS 查询包。若残留封锁在EC2实例与广州的VPS 之间生效，那么DNS请求将被丢弃，这也就表明可用性攻击成功了。

图 9：受可用性攻击影响的 EC2 实例地理分布图。受影响最严重的主机以红色显示，受影响较轻的以绿色显示。黑点分别表示位于广州的“受害者”服务器，以及位于美国的攻击服务器。

表 6 与图 9 显示 EC2 实例位置及攻击效果。在 32 台实例中，超过半数（17 台）被严重影响。部分实例仍能接收少量包，主要因 3 分钟残留封锁到期后到下一次伪造包到达之间有 1 秒窗口；加大发包频率或选准时机可提升阻断率。另有 7 台实例的约半数请求被丢弃，表明存在多条网络路径，而只有部分路径受到残留封锁的影响。

表 6：各 AWS 区域的数据包接收情况。可用性攻击持续了 30 分钟，真实客户端每 5 秒发 1 个监测数据包。攻击服务器在美国，受害服务器在广州。对于每台 EC2 实例，攻击服务器伪造其IP地址，每秒发送10个 QUIC Initial 包。


洲/区域	城市/地区	接收到的数据包数量	占共计360个数据包的百分比

非洲	开普敦	110	30.56%

亚太地区	香港	360	100.00%

亚太地区	海得拉巴	13	3.61%

亚太地区	雅加达	360	100.00%

亚太地区	马来西亚	360	100.00%

亚太地区	墨尔本	360	100.00%

亚太地区	孟买	360	100.00%

亚太地区	大阪	145	40.28%

亚太地区	首尔	246	68.33%

亚太地区	新加坡	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%

欧洲	巴黎	10	2.78%

欧洲	西班牙	15	4.17%

欧洲	斯德哥尔摩	14	3.89%

欧洲	苏黎世	17	4.72%

以色列	特拉维夫	18	5.00%

墨西哥	中部	13	3.61%

中东	巴林	201	55.83%

中东	阿联酋	22	6.11%

南美洲	圣保罗	12	3.33%

美国东部	北弗吉尼亚	195	54.17%

美国东部	俄亥俄	21	5.83%

美国西部	北加州	21	5.83%

美国西部	俄勒冈	19	5.28%

剩余 8 台实例未受任何影响，它们主要分布于太平洋地区，表明攻击服务器与这些实例未共享相同网络路径。我们确认，当真实客户端直接发送触发审查的数据包到不同实例时，所有 32 台实例均能触发 GFW 的封锁。

防御。由于 UDP 无状态且易伪造，防御此攻击并保持审查功能极具挑战。一种潜在缓解方案是仅在检测到对应的 QUIC Server Hello 及后续客户端包后再触发封锁，以确保连接真实存在。但此方案需对连接进行有状态跟踪，对审查设备造成巨大开销。此外，路径不对称会导致审查设备可能看不到 Server Hello 而无法审查。即便如此，攻击者仍可同时伪造双向流量以触发封锁，使该防御失效。

另一种方案是采用注入式封锁机制，避免丢包式残留封锁。但此方案也有风险和限制。例如，鉴于解密延迟（见图 2），QUIC Server Initial 可能先到达客户端并建立密钥，随后注入包才到达，导致注入无效。

在 QUIC 中防御这类可用性攻击尤为困难：QUIC协议在设计是就考虑到要抵御攻击者通过注入伪造包来阻断连接，因此GFW才需要使用基于丢包的残留封锁；而与此同时， UDP 的无连接特性使伪造 Initial 包极为简单，这使得GFW在使用残留封锁时，增加了可用性攻击的风险。要在 QUIC 中实现有针对性的封锁并防止可用性攻击，需要谨慎的工程设计。

7. 绕过封锁

如第 3.2 节所述，GFW 为了在线路速率下高效解析和封锁 QUIC 流量，采取了若干简化假设。这些设计选择再次体现出 GFW 设计者和开发者所遵循的“worse-is-better”理念 [31]。然而，这些假设以牺牲审查系统的准确性和鲁棒性为代价，从而为绕过封锁带来了机会。我们已将所发现的绕过策略负责任地披露给反审查社区和开源社区。

源端口 <= 目标端口。如第 3.4 节所详细说明的，GFW 忽略源端口 <= 目标端口的 UDP 数据包，从而做到仅关注客户端到服务器方向的流量。因此，一种临时绕过办法是使用目标端口大于等于源端口的方式。例如，服务器可将翻墙代理运行在高于或等于客户端临时端口范围的端口；Web 服务亦可监听在非常规高端口上，并通过 HTTP 头的Alt-Svc值或 DNS HTTPS 记录向客户端公布端口。对于无法变更监听端口或无法监听多个端口的软件，可通过 iptables 规则将所有发往高端口（如 65535）的流量重定向到当前监听端口（如 443），例如 iptables -t nat -A PREROUTING -p udp --dport 65535 -j REDIRECT --to-port 443。此方法对无法修改监听端口的软件尤其有用。

在 QUIC Client Initial 前发送任意 UDP 数据包。GFW 的 QUIC 封锁机制假定 QUIC client Initial 是新流的首个数据包。一个简单的绕过方式是在发送 client Initial 之前先发送一个带有随机负载的 UDP 数据包。对于真实的 QUIC 服务器而言，首个 UDP 数据包会被忽略，但对 GFW 而言，因为无法从首包解析出 SNI，所以会让该流被豁免。后续真正的client Initial 将不再被检查，连接可顺利建立。我们通过在发送 QUIC client Initial 之前发送带随机负载的 UDP 数据包，实证了该防御策略可绕过 GFW 的封锁。同时，我们也对 Chromium Quiche [35]QUIC 服务器实现进行了测试，确认其会忽略冗余 UDP 数据包。

连接迁移。QUIC 的连接迁移能力利用连接 ID 跨网络变化保持会话。GFW 采用选择性过滤策略：允许首个 QUIC 包，随后封锁客户端到服务器方向的数据包，但不监控连接 ID。由于服务器到客户端方向的数据包未被封锁，客户端只要在封锁激活前完成 1-RTT 握手，并迁移到不同网络四元组（源 IP、源端口、目的 IP、目的端口），即可绕过 GFW。

QUICstep [44]提出了一种相关方法，通过连接迁移技术实现 QUIC 封锁绕过。该方法先在低带宽高延迟的安全通道上完成 QUIC 握手，随后将连接迁移到常规通信通道，从而保证所有数据均为加密传输。

QUIC Client Initial 分片。QUIC client Initial 可通过多份 UDP 数据包发送，或以单个 UDP 数据包承载多个 QUIC 帧。截至 2025 年 1 月，GFW 不会重组被分片成多个 UDP 数据包，也不会重组在单个 UDP 数据包中被拆分为多帧的 TLS Client Hello。因此，可利用该弱点，将 SNI 拆分进 client Initial 内的多个 QUIC CRYPTO 帧以绕过 GFW 的 QUIC 封锁。

值得注意的是，Chrome 自 2021 年引入的 Chaos Protection 机制 [19]，会将 QUIC client Initial 拆分进多个 QUIC 帧，并分散在不同 UDP 数据包中。同时，自 Chrome 124 版 [12]起，支持在 TLS 1.3 下进行后量子密钥协商（ML-KEM 与 Kyber 密钥），启用该功能后，由于密钥长度超出 QUIC 单包最大长度，client Initial 会被分片到多个 UDP 数据包。这些特性实际上恰好利用了 GFW 无法重组分片 QUIC client Initial 的弱点，使 Chrome 的流量能够绕过 GFW 的 QUIC 封锁。

加密 Client Hello（ECH）。ECH [51]允许客户端使用通过 DNS HTTPS 记录获取的密钥，将部分 TLS Client Hello 消息加密发送给服务器，从而加密 SNI 扩展，令审查者无法获知 SNI。与 QUIC 的 client Initial 加密不同，ECH 加密为非对称加密，网络观察者无法解密。

审查者可选择封锁所有包含 ECH 的负载。然而，现代浏览器即便服务器不支持 ECH 也会发送“伪装” ECH 负载。截至 2025 年 1 月，GFW 不会封锁带有 ECH 的 QUIC 负载，除非外层（可解密）SNI 属于被封锁域名。

版本协商。QUIC 的版本协商机制 [43 §6]为绕过封锁提供了新的思路。通常，服务器收到不支持的版本号的 Initial 包后，会返回 Version Negotiation 包，等待客户端使用受支持版本重新发送 Initial。客户端可利用该机制，故意先发送带未知版本号的 Initial 包，使首包负载无法被解密，从而让后续连接流量绕过 GFW 的过滤。随后，客户端可继续以受支持版本完成握手，实现对审查机制的规避。

“权宜之计”值得部署吗？虽然上述方法多为利用 GFW 实现细节的机会型绕过策略，但中国审查者方面因为受限于资源和优先级 [5]，要全面修复这些漏洞也并非易事。过往研究也发现，类似的权宜之计在与审查者的博弈中可持续多年 [66 §8.3]。另一方面，这些绕过方案对 QUIC 代理和翻墙软件开发者而言，部署门槛较低，且不像GFW一样受到官僚体系约束 [5]。

负责任披露。我们已将关于中国 QUIC 封锁及绕过策略的发现分享给反审查社区及开源社区。具体包括：Mozilla Firefox [48]、Mozilla Neqo 库 [49]、quic-go 库 [53]、Lantern [18]、Hysteria [39]、TUIC [59]、sing-box [54]、V2Ray [61] 和 Xray [68]的开发者。

在我们向 Mozilla 进行负责任披露之前， 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 参数进行配置）。而这一功能的集成与启用，也恰好在无意间绕过了 GFW 针对 QUIC SNI 的封锁。

表 7：quic-go v0.52.0 [53]集成时间线。自 2025 年 5 月 23 日发布以来，主流绕过工具已更新依赖，默认启用 SNI 切片以绕过 GFW 针对 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]

Hysteria	2.6.2	2025 年 6 月 7 日 [40]

quic-go 库于 2025 年 5 月 23 日在 v0.52.0 版本 [53]引入了 SNI 切片功能。如表 7所示，这一更新允许依赖 quic-go 的绕过工具默认启用 SNI 切片，从而绕过 GFW 针对 QUIC SNI 的封锁。

截至 2025 年 6 月，我们正与某款主流浏览器合作，将“握手前伪装负载”方案集成于其中，以进一步提升对 GFW 的抗封锁能力。

8. 讨论

我们的研究结果引出了关于 GFW 封锁 QUIC 连接的两个关键问题：（1）其对常规网页流量的影响；（2）其对基于 QUIC 的代理的影响。当用户访问网站时，浏览器首先会通过 HTTP(S)-over-TCP 连接服务器，仅当服务器通过 Alternate Service 头声明支持 QUIC 时，才会尝试使用 QUIC。因此，基于 HTTP Host 和 TLS SNI 的封锁仍是拦截网页流量的主要机制，只有当网站未被这两种机制封锁时，GFW 的 QUIC 封锁才会介入。GFW 的 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 客户端启动握手失败。这一现象表明 GFW 正在有针对性地封锁 MASQUE 代理。同样，Hysteria 也面临类似情况，不仅其主项目域名 v2.hysteria.network 被封锁，用户自定义的 Hysteria 代理域名亦被封锁。

9. 结论

针对自 2024 年 4 月 7 日以来 GFW 基于 QUIC SNI 的审查机制，我们开展了测量实验，系统性地刻画、监测、揭示并提出绕过策略。结果表明，这一新型封锁机制可被滥用于阻断中国内外主机间任意 UDP 流量。我们还提出了一种 off-path的审查绕过策略，使用中等的流量负载来降低 GFW 的有效性。我们与多个开源社区合作，将审查绕过策略集成进一款主流浏览器、quic-go 库及所有主流的基于 QUIC 的翻墙工具中。

鸣谢

我们感谢匿名的牧羊人和评审专家的宝贵反馈。本研究得以启动，离不开勇敢的中国用户最早报告了QUIC审查问题，我们为他们的勇气深表敬意。我们特别感谢匿名的RQWDKM，其与我们共同进行了初步测量和调查，参与讨论，并对本文提出了详细的反馈。

我们衷心感谢 Mozilla Neqo 和 Firefox 团队的众多成员，感谢他们的讨论与支持。

我们感谢 Hysteria、Lantern、sing-box、TUIC、V2Ray、Xray 等项目的开发者与贡献者，为反审查讨论提供了宝贵的在线空间，并将审查绕过方案快速集成在他们的翻墙软件中。

我们同时也感谢下列个人及许多匿名贡献者的支持、反馈与富有洞见的讨论：Bill Marczak、David Fifield、Jeffrey Knockel、Juraj Somorovsky、klzgrad、nekohasekai、Nick Sullivan、Niklas Niere 及 Prateek Mittal。

本研究部分由美国国家科学基金会（NSF）CNS-2145783 项目资助，因该机构优先级调整，导致该项目提前终止，对相关研究造成重大影响 [30]。

本研究亦部分获得 NSF CNS-2319080、CNS-2333965 项目、斯隆研究奖和美国国防高级研究计划局（DARPA）青年教师奖 DARPA-RA-21-03-09-YFA9-FP-003 的资助。文中所表达的观点、意见和/或发现仅代表作者本人，不应被解读为代表美国国防部或美国政府的官方观点或政策。

伦理考量

本研究的伦理考量主要包括两方面：实验可能对网络基础设施造成的潜在影响，以及对所发现漏洞的披露处理。

可用性攻击。在第 6 节中，我们展示了 GFW 可以被攻击者利用以封锁互联网上的任意主机。为降低实验过程中对外部造成影响的风险，我们仅以我们自己的服务器为攻击目标。虽然攻击涉及伪造 IP 包，但我们仅伪装为属于自己的 IP 地址。该攻击的结果是，在短时间内，我们自己的 EC2 实例无法与中国服务器通信。

我们还基于计算机安全与伦理领域的两大伦理框架 [45]，对相关工作进行了分析。从结果主义伦理视角看，该攻击带来的外部风险可忽略不计；从义务伦理视角看，仅攻击自有主机最大限度地避免了牵涉他人，履行了对他人的基本责任。

GFW 性能降级攻击。在第 5 节，我们介绍了一种通过发送大量 QUIC Initial 包削弱 GFW 封锁能力的方法。该实验涉及若干风险，直接影响了我们的实验设计。首先，我们考虑了主动破坏 GFW的道德正当性（即便连其设计者亦承认[71 §1]，GFW本身就是伤害源 [28 §9.c], [28 §9.B, 3, 42]）。一方面，GFW 并非我们拥有和控制的系统，其被破坏可能带来负面或不可预知的后果；另一方面，促使 GFW 无法审查将为中国用户带来福祉，因为其网络本已违背人权 [60]。权衡后，我们认为，只要将风险控制在 GFW 审查体系内，对其实施性能降级具备道德正当性。

但我们同时必须评估攻击对其他系统的影响和风险。例如，若干扰 GFW 导致所有跨境流量被丢弃，则将影响中外正常通信。尽管第 3.1 节分析表明 GFW 的 QUIC 审查并非纯串联，但我们仍担心其与串联相关的部分可能影响所有流量。然而，全日封锁（diurnal pattern）测量结果显示，白天 QUIC 连接量较高时，GFW 仅能封锁一小部分连接（图 4），且未影响不再封锁域名名单上的 QUIC 及其他流量。

最后，我们还评估了实验可能对网络本身造成干扰的风险。由于需发送大量 QUIC 包，存在压垮链路或终端服务器的可能。我们采取多重措施降低这一风险：一，发送速率控制在 150 万包/秒，带宽占用低于 4 Gbps；二，确认与上游互联网提供商链路带宽至少为 40 Gbps，国际链路通常为 100 Gbps 或多 Tbps，实验流量仅占极小比例；三，限定包 TTL，仅穿越 GFW 而不抵达目的地，仅影响骨干链路，该类链路有足够余量承载我们的流量；四，持续监测网络的健康，包括 ZMap 扫描和双向连接性测试。实验期间未观测到网络性能下降，说明未对网络造成过载。

从义务伦理视角[60 §4.1]，我们需兼顾他人（如中国网民）的权利和本研究的初衷。本研究方法直面两种道德义务的冲突：一方面应尽量避免对他人网络资源的干扰，另一方面实验又肩负着阻止 GFW 持续伤害的责任。我们认为后者更具道德优先性，因此选择继续实验。从结果主义视角[60 §4.1]，需权衡利弊——本实验揭示了恢复用户信息获取权利的途径，同时将对其他网络和主机的风险降到最低。

漏洞披露。漏洞披露是安全研究领域的标准伦理实践，有助于提升系统安全水平并保护受影响用户。但我们的研究对象是 GFW，对其改进本身会带来负面后果，故披露过程需慎重。另一方面，我们又有必要保护可能因 GFW 漏洞受攻击的互联网用户。因此，我们仔细权衡披露内容，力求在不提升 GFW 审查能力的前提下，最大化地保护用户的利益。我们的目标是保护用户，同时避免“协助”中国强化审查的风险。

综合考量后，我们决定将可用性攻击（第 6 节）披露给审查方，因为该漏洞可能对用户造成危害。2025 年 1 月 22 日，我们向 CNCERT 及被誉为“GFW 之父”的方滨兴 [34]披露了漏洞，并建议移除存在漏洞的 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 节）直接披露给审查方，而是优先私下告知反审查社区，并让其随着论文的发表而公开。我们选择此策略是因为性能降级攻击仅影响 GFW 自己的基础设施，不威胁用户。如若直接披露，反而会使审查方有机会在反审查社区知晓漏洞前强化其审查机制。

虽然公开漏洞可能促使审查方修补漏洞（审查者可能本身就知道该漏洞，但因为论文的公开，审查者现在则知道了他人也发现了该漏洞），但我们认为公开披露的价值高于相关风险。只有让更广泛的技术社区了解审查系统的弱点，才能推动协议设计和反审查策略的进步。例如，QUIC Initial 包被设计为是加密的（尽管中间盒可解密），部分目的就是为了提升中间盒的解析难度。GFW 的 QUIC 审查系统难以跟上解密开销，说明即便协议设计仅略微增加处理成本，也能有效降低审查系统的效率[5]。

未收集个人身份信息（PII）。本研究不涉及人类被试者，也未收集任何个人身份信息（PII）。

开放科学

为促进后续研究与结果可复现性，我们已公开发布本研究的全部代码与数据。为提高可访问性，我们亦以 HTML格式提供论文的中英文版本。项目主页位于：https://gfw.report/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, and A. Houmansadr. How China detects and blocks Shadowsocks. In Internet Measurement Conference. ACM, 2020. URL: https://censorbib.nymity.ch/pdf/Alice2020a.pdf.
D. Anderson. Splinternet behind the Great Firewall of China: Once China opened its door to the world, it could not close it again. Queue, 10(11):40–49, November 2012. URL: https://queue.acm.org/detail.cfm?id=2405036, doi:10.1145/2390756.2405036.
Anonymous. Towards a comprehensive picture of the Great Firewall’s DNS censorship. In Free and Open Communications on the Internet. USENIX, 2014. URL: https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.pdf.
Anonymous and Anonymous. Sharing a modified Shadowsocks as well as our thoughts on the cat-and-mouse game, October 2022. URL: https://github.com/net4people/bbs/issues/136.
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. URL: https://www.usenix.org/system/files/foci20-paper-anonymous_0.pdf.
M. Bishop. HTTP/3. RFC 9114, June 2022. URL: https://www.rfc-editor.org/info/rfc9114, doi:10.17487/RFC9114.
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. URL: https://www.usenix.org/system/files/sec21-bock.pdf.
K. 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. URL: https://www.cs.umd.edu/~dml/papers/weaponizing_woot21.pdf.
K. Bock, iyouport, Anonymous, L.-H. Merino, D. Fifield, A. Houmansadr, and D. Levin. Exposing and circumventing China’s censorship of ESNI, August 2020. URL: https://github.com/net4people/bbs/issues/43#issuecomment-673322409.
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. URL: https://www.usenix.org/system/files/foci19-paper_chai_update.pdf.
Chrome Developers. Chrome 124 — release notes, April 2024. URL: https://developer.chrome.com/release-notes/124.
R. Clayton, S. J. Murdoch, and R. N. M. Watson. Ignoring the Great Firewall of China. In Privacy Enhancing Technologies, pages 20–35. Springer, 2006. URL: https://www.cl.cam.ac.uk/~rnc1/ignoring.pdf.
Cloudflare. Cloudflare Radar – Adoption and Usage Worldwide, 2025. URL: https://radar.cloudflare.com/adoption-and-usage?dateStart=2024-01-01&dateEnd=2024-12-31.
J. R. Crandall, D. Zinn, M. Byrd, E. Barr, and R. East. ConceptDoppler: A weather tracker for Internet censorship. In Computer and Communications Security, pages 352–365. ACM, 2007. URL: http://www.csd.uoc.gr/~hy558/papers/conceptdoppler.pdf.
critical_error. QUIC streams with encrypted_client_hello extensions in QUIC initials are being blocked in Uzbekistan. NTC Party Forum, 12 2024. URL: https://ntc.party/t/13953.
Dan Hall. Zero Trust WARP: tunneling with a MASQUE. URL: https://blog.cloudflare.com/zero-trust-warp-with-a-masque/.
L. developers. Lantern. URL: https://github.com/getlantern.
dschinazi. Chaos Protection in QUIC, 2025. URL: https://quiche.googlesource.com/quiche/+/cb6b51054274cb2c939264faf34a1776e0a5bab7.
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. URL: https://www.icir.org/vern/papers/hold-on.satin12.pdf.
M. Duke. QUIC Version 2. RFC 9369, May 2023. URL: https://www.rfc-editor.org/info/rfc9369.
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. URL: https://www.usenix.org/system/files/conference/foci18/foci18-paper-dunna.pdf.
Z. Durumeric, E. Wustrow, and J. A. Halderman. ZMap: Fast internet-wide scanning and its security applications. In USENIX Security Symposium. USENIX, August 2013. URL: https://www.usenix.org/conference/usenixsecurity13/technical-sessions/paper/durumeric.
L. Eggert. Pull request #2228: feat: Shuffle the client Initial crypto data. https://github.com/mozilla/neqo/pull/2228.
K. Elmenhorst, B. Schütz, N. Aschenbruck, and S. Basso. Web censorship measurements of HTTP/3 over QUIC. In Internet Measurement Conference. ACM, 2021. URL: https://dl.acm.org/doi/pdf/10.1145/3487552.3487836.
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. URL: https://conferences2.sigcomm.org/imc/2015/papers/p445.pdf.
A. L. et al. The quic transport protocol: Design and internet-scale deployment. SIGCOMM ’17. ACM, 2017. doi:10.1145/3098822.3098842.
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. URL: https://gfw.report/publications/ndss25/data/paper/wallbleed.pdf.
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. URL: https://dl.acm.org/authorize?N25517.
N. S. Foundation. Updates on nsf priorities. https://www.nsf.gov/updates-on-priorities, 2025.
R. P. Gabriel. Worse is better. URL: https://dreamsongs.com/WorseIsBetter.html.
gfw-report. Rapid blocking of connections following ESNI triggers, August 2020. URL: https://github.com/net4people/bbs/issues/43#issuecomment-673490763.
P. God. QUIC connection with SNI of *.eu.org has been blocked. Telegram post, 2024. URL: https://t.me/c/1166154022/909198.
J. Goldkorn. Fang Binxing and the Great Firewall. In G. R. Barmé and J. Goldkorn, editors, China Story Yearbook 2013: Civilising China. Australian Centre on China in the World. URL: 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 and related protocol toolkit. URL: https://github.com/google/quiche.
L. Hanson. The chinese internet gets a stronger backbone. 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, and N. Feamster. GFWeb: Measuring the Great Firewall’s Web censorship at scale. In USENIX Security Symposium. USENIX, 2024. URL: 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, and M. Polychronakis. How great is the Great Firewall? Measuring China’s DNS censorship. In USENIX Security Symposium. USENIX, 2021. URL: https://www.usenix.org/system/files/sec21-hoang.pdf.
Hysteria developers. Hysteria. URL: https://github.com/apernet/hysteria.
Hysteria Developers. Hysteria software release. URL: https://github.com/apernet/hysteria/releases/tag/app%2Fv2.6.2.
IETF. Multiplexed Application Substrate over QUIC Encryption (masque), 2025. URL: https://datatracker.ietf.org/wg/masque/about/.
Internet Society. When is the Internet not the Internet?, December 2023. URL: https://www.internetsociety.org/resources/internet-fragmentation/the-chinese-firewall/.
J. Iyengar and M. Thomson. QUIC: A UDP-Based Multiplexed and Secure Transport. RFC 9000, May 2021. URL: https://www.rfc-editor.org/info/rfc9000, doi:10.17487/RFC9000.
W. Jia, M. Wang, L. Wang, and P. Mittal. QUICstep: Circumventing QUIC-based censorship, 2023. URL: https://arxiv.org/abs/2304.01073.
T. Kohno, Y. Acar, and W. Loh. Ethical frameworks and computer security trolley problems: Foundations for conversations. In 32nd USENIX Security Symposium (USENIX Security 23), 2023. URL: https://securityethics.cs.washington.edu/.
madeye. Savoury implementation of the QUIC transport protocol and HTTP/3, 2024. URL: https://github.com/cloudflare/quiche.
Mozilla Developers. Bug 1942325 - update Neqo to v0.12.2 in mozilla-central. https://bugzilla.mozilla.org/show_bug.cgi?id=1942325.
Mozilla Foundation. Firefox Web Browser Source Code. https://github.com/mozilla-firefox/firefox.
Mozilla Foundation. Neqo: Next Generation QUIC Client and Server Library. https://github.com/mozilla/neqo.
Mozilla Neqo Team. Neqo version 0.12.0 release. https://github.com/mozilla/neqo/releases/tag/v0.12.0.
E. Rescorla, K. Oku, N. Sullivan, and C. A. Wood. TLS Encrypted Client Hello. Internet-draft, March 2025. Work in Progress. URL: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/24/.
Sakamoto and E. Wedwards. Bleeding wall: A hematologic examination on the Great Firewall. In Free and Open Communications on the Internet, 2024. URL: https://www.petsymposium.org/foci/2024/foci-2024-0002.pdf.
M. Seemann. quic-go: A QUIC implementation in pure Go (version 0.52.0). https://github.com/quic-go/quic-go/releases/tag/v0.52.0.
Sing-box developers. Sing-box. URL: https://github.com/SagerNet/sing-box.
sing-box Developers. sing-box software release. URL: https://github.com/SagerNet/sing-box/releases/tag/v1.12.0-beta.17.
N. Software. The ephemeral port range. URL: https://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html.
M. Streisand, E. Wustrow, and A. Houmansadr. Where have all the paragraphs gone? detecting and exposing censorship in Chinese translation. In Free and Open Communications on the Internet, 2023. URL: https://www.petsymposium.org/foci/2023/foci-2023-0001.pdf.
M. Thomson and S. Turner. Using TLS to Secure QUIC. RFC 9001. URL: https://www.rfc-editor.org/info/rfc9001.
TUIC Protocol. tuic: Delicately-tuiced 0-rtt proxy protocol. https://github.com/tuic-protocol/tuic.
United Nations Human Rights Council. The promotion, protection and enjoyment of human rights on the Internet. https://www.article19.org/data/files/Internet_Statement_Adopted.pdf, June 2016. Resolution A/HRC/32/L.20.
V2Ray developers. V2Ray. URL: https://github.com/v2fly/v2ray-core.
V2Ray Developers. V2Ray Core software release. URL: https://github.com/v2fly/v2ray-core/releases/tag/v5.33.0.
ValdikSS. Restriction HTTP/3 (QUIC) - post 10. ntc.party, Mar 2022. Accessed: 2024-05-27. URL: https://ntc.party/t/1823/10.
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. URL: https://www.cs.ucr.edu/~krish/imc17.pdf.
P. Winter and S. Lindskog. How the Great Firewall of China is blocking Tor. In Free and Open Communications on the Internet. USENIX, 2012. URL: 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, and E. Wustrow. How the Great Firewall of China detects and blocks fully encrypted traffic. In USENIX Security Symposium. USENIX, 2023. URL: https://www.usenix.org/system/files/sec23fall-prepub-234-wu-mingshi.pdf.
M. Wu, A. Zohaib, Z. Durumeric, A. Houmansadr, and E. Wustrow. A wall behind a wall: Emerging regional censorship in China. In Symposium on Security & Privacy. IEEE, 2025. URL: https://gfw.report/publications/sp25/data/paper/paper.pdf.
XRay developers. XRay. URL: https://github.com/XTLS/Xray-core.
Xray Developers. Xray software release. URL: https://github.com/XTLS/Xray-core/releases/tag/v25.6.8.
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. URL: https://dl.acm.org/doi/pdf/10.1145/3517745.3561461.
B. Yan, B. Fang, B. Li, and Y. Wang. Detection and defence of DNS spoofing attack, November 2006. URL: https://github.com/user-attachments/files/18172972/Yan2006a.pdf.

A. 全日封锁延迟分布

图 10 展示了 GFW 封锁延迟在一天中的变化。封锁延迟指 GFW 在检测到含有被封锁 SNI 的 QUIC Initial 包后，阻断该连接所需的时间。其测量方式为：客户端发送 QUIC Initial 包的时间与客户端首次发送被 GFW 丢弃的 UDP 数据包之间的时间差。

图 10：箱线图展示了 GFW 阻断连接所需时间的分布。横坐标为对数刻度。绿色三角形表示均值，须状线显示最小值和最大值。

最小封锁延迟在白天始终低于 100 毫秒，这很可能受限于 GFW 内部处理和响应速度。

最大封锁延迟则随一天内时段波动，可能与 GFW 处理的 QUIC 连接数量有关（第 5 节亦有提示）。在通常人类活动较少的凌晨时段（凌晨 12 点至 6 点），GFW 封锁连接所需时间相对较短，平均封锁延迟约为 150 毫秒。相比之下，在人类活动高峰时段（上午 7 点至晚上 11 点），平均封锁延迟可达 800 毫秒，且最大延迟在下午 3 点左右达到 7000 毫秒。

B. 基于端口的流量过滤

为进一步验证第 3.3 节中关于 GFW 基于源端口和目标端口过滤启发式规则的结论，我们扩展了分析范围，覆盖更多端口。采用相同方法，我们测试了从 1 到 65535 的端口，间距为 1000，并特别包含了65535号端口。

图 11 展示了在扩展端口范围下 GFW 的封锁行为。结果进一步证实了我们的最初发现：如果 QUIC Initial 包的源端口小于或等于目标端口，GFW 不会追踪或封锁对应的 UDP 流。

图 11：如果 QUIC Initial 包的源端口小于或等于目标端口，审查方不会追踪或封锁相应 UDP 流。该规则适用于所有端口号（1 至 65535）。

C. 向审查方披露漏洞的邮件

如第 9 节所述，因该漏洞允许攻击者利用 GFW 对用户造成进一步伤害，我们决定将可用性攻击（第 6 节）披露给审查者。2025年1月22日，我们向 CNCERT/CC 及被誉为“GFW 之父”的方滨兴 [34] 发送如下邮件，建议移除存在漏洞的 QUIC 审查设备并部署出站过滤以防止 IP 欺骗攻击。该邮件以中英文撰写，并提供了两个介绍攻击详情的中英文私有网页链接。尽管我们未收到任何回复或正式回应，但从2025年1月24日（周五）下午 2:04（UTC+8）至2025年2月24日（周一）上午 9:35（UTC+8）期间，英文网页共被访问 37 次（中文版无访问），说明信息已被接收。

主题:       Disclose a Vulnerability in the GFW’s QUIC Filtering Mechanism
发件人:     gfw.report <gfw.report@protonmail.com>
收件人:     CNCERT/CC <cncert@cert.org.cn>
抄送:       Fang Binxing <fangbx@iie.ac.cn>
日期:       Thu, 23 Jan 2025 12:01:46 +0000

尊敬的CNCERT团队：

我们撰写此信是为了披露一种由中国骨干网络上部署的QUIC过滤机制引发的漏洞。该机制至少自2024年4月7日以来一直在运行。该漏洞允许具有伪造IP数据包能力的网络攻击者利用中国的防火长城（GFW）长期中断或阻断中国境内外主机之间的通信。

以下是关于此漏洞的详细信息、影响和缓解措施。此外，我们在以下链接提供了此披露的最新版本：[此处隐去中文版负责任披露页面的网址。]

## 漏洞详情

攻击者可以向特定的IP:端口发送带有防火长城屏蔽名单中的SNI（例如google.com）的QUIC初始数据包（参见以下示例），从而触发GFW的残留审查机制，持续约180秒。如果攻击者将源IP地址伪造成中国境内的受害者IP地址，则此机制可被利用来阻止受害者的IP地址与指定的服务器IP:端口通信三分钟。同样，攻击者可以将源IP地址伪造成中国境外的受害者服务器IP地址，并向中国境内受害者的IP地址的多个端口发送数据包。通过不断发送伪造的QUIC初始数据包，攻击者可以无限期维持封锁。

当防火长城的审查机制被触发时，它会基于三元组（源IP、目标IP、目标UDP端口）阻断通信，时间为3分钟（180秒）。审查可以通过包含屏蔽名单中SNI的单个UDP数据包（如以下示例中的QUIC初始数据包）触发。通常情况下，这种阻断只会影响尝试连接的客户端和服务器之间的通信。然而，由于阻断可以由单个UDP数据包触发，能够伪造IP数据包的网络攻击者可以轻松地让防火墙阻断其他主机的通信。

例如，假设中国境内的某主机地址为19.89.5.35，一个位于中国境外的DNS服务器地址为4.2.2.1，使用UDP端口53。如果攻击者从19.89.5.35:x（任意源端口x）发送一个UDP数据包到4.2.2.1:53，这将触发防火长城阻止19.89.5.35向4.2.2.1:53发送任何数据包，持续3分钟。攻击者可以通过使用不同的源端口伪造数据包，来无限期延长封锁时间。

## 影响

GFW的开发和部署，以及此次发现的问题，对中国用户构成了严重风险，并可能在大范围内中断通信。例如，它可以被利用来阻止基于UDP的DNS流量，从而在中国的DNS解析器与外部网络之间造成广泛的连接问题。

为了展示此攻击的潜在影响，我们使用了32个全球分布的Amazon EC2实例进行了实验。在实验中，我们通过让每个EC2实例向我们在广州控制的VPS发送DNS请求，同时从美国的一个不进行出口过滤的服务器，向每个EC2 IP地址伪造包含屏蔽名单中SNI的QUIC初始数据包并发送到广州VPS。以下地图展示了仅使用一个伪造点时，哪些实例受到了影响。绿色点代表没有连接问题，红色点代表成功向广州主机发送请求有困难。黑色点分别代表我们的受害服务器（广州）和伪造服务器（美国）的位置。


## 缓解措施

由于此攻击可能造成的严重危害，我们敦促立即采取行动解决这一问题。UDP是一种无连接协议，很难完全防止伪造攻击。因此，最彻底的缓解措施是禁用负责阻断UDP连接的审查设备。除了导致这些有害攻击，防火长城还通过阻止信息访问，侵犯了基本人权。

一种较不彻底的缓解措施是部署出口过滤以防止IP数据包伪造，但只要攻击者能够找到一个能够伪造数据包的位置，即使在中国境外，此攻击仍然可能实现。鉴于此，我们建议：1）立即且永久性地禁用QUIC审查过滤设备；2）在边缘网络部署出口过滤以限制IP伪造。

感谢您对这一关键问题的关注。我们随时愿意提供更多技术细节或解答后续问题，以确保此问题得到及时解决。

此致
敬礼
Team

---

Example command:
nc -s $SRC_IP -p $SRC_PORT -vnu $DST_IP $DST_PORT <<<$(xxd -r -p \
<<< "c600000001104ebdf7c473c1c15db3ffa4534f5b3158102154b19e765d7a3caa33a20b92c56da30040e182
dcfd47c61c7fff552b8c61053c0c91ab148d199277a3b459519768aa6c79533eecd2d2e678dbac45dadef121d1d
3f5f56454c6b9305c45d919053fea8c1c1bd950d1fd14ee770d8312d10c03a18aea463538d721af70b4e732037e
ac620f361d0435114eea55204caa685dd33f8b2cb1dac6568b320e2d348f77e72a4c150ed5ac27a9ce9edf696ea
929baf34f28598320b0baa993fbdeddf7c45b724eee8f6fa9c7860a973f0138777422347161743bc6d36e519951
47d7f6d2cf4a398b7ea1066f77bcdee89e760d2568bc3c9bb8f7d5c43482a11a7d696c7dc62fe6ecade80000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000")

A Wall Behind A Wall: Emerging Regional Censorship in China

Sun, 11 May 2025 00:00:00 +0000

A Wall Behind A Wall: Emerging Regional Censorship in China

Mingshi Wu^∗

GFW Report

gfw.report@protonmail.com

Ali Zohaib^∗

University of Massachusetts Amherst

azohaib@umass.edu

Zakir Durumeric

Stanford University

zakir@cs.stanford.edu

Amir Houmansadr

University of Massachusetts Amherst

amir@cs.umass.edu

Eric Wustrow

University of Colorado Boulder

ewust@colorado.edu

^* Mingshi Wu and Ali Zohaib contributed equally to this work.

Abstract

China has long orchestrated its Internet censorship through relatively centralized policies and a unified implementation, known as the Great Firewall of China (GFW). However, since August 2023, anecdotes suggest that the Henan Province has deployed its own regional censorship. In this work, we characterize provincial-level censorship in Henan, and compare it with the national-level GFW. We find that Henan has established TLS SNI-based and HTTP Host-based censorship that inspects and blocks traffic leaving the province. While the Henan Firewall is less sophisticated and less robust against typical network variability, its volatile and aggressive blocking of second-level domains made it block ten times more websites than the GFW at some points in time. Based on the observed parsing flaws and injection behaviors, we introduce simple client-side methods to bypass censorship in the Henan province. Our work documents an alarming sign of regional censorship emerging in China.

1. Introduction

The People’s Republic of China develops and maintains one of the most sophisticated Internet censorship apparatuses, colloquially referred to as the Great Firewall (GFW). Through DNS poisoning [1, 2, 3, 4, 5], HTTP Host header filtering [6, 7, 8, 9], TLS SNI/ESNI filtering [2, 9, 10, 11 §3], IP address blocking [2 §4], active probing [12, 13, 14, 15 §5], and proxy traffic detection [15 §4], China blocks its citizens from accessing large swaths of Internet content and services.

China’s censorship apparatus has long been believed to be operated relatively centrally, in terms of both its policy and implementation. Empirical measurements have revealed China’s uniform and coordinated management of censorship policies [3, 4, 9, 15], software updates [16 §4.5] [5 §VII], and infrastructures [14 §3.4] [4 §5]. Censorship devices are positioned at the national border [4, 17, 18], where they inspect and filter traffic entering or exiting the country. As a result, traffic exchanged domestically within China is not inspected or blocked by the GFW.

However, recent anecdotes suggest that this centralized and uniform censorship model may no longer tell the whole story. In August 2023, users in the Henan Province of China—the third-largest province by population and a pivotal labor hub—began reporting an uptick in inaccessible websites that were accessible elsewhere in China [19].

In this work,¹ we first explore a natural question raised by the discovery of regional censorship in Henan (Section 3): have other provinces in China deployed the same or similar regional censorship? We conducted a measurement study in seven provinces and municipalities in China, including Beijing, Shanghai, Guangdong, Zhejiang, Jiangsu, Sichuan, and Henan, to identify potential regional censorship. Likely limited by the vantage points we could access in China, we found no evidence of regional censorship in the six provinces other than Henan.

¹ Project homepage: https://gfw.report/publications/sp25/en.

We then analyze the emerging regional censorship in the Henan Province, comparing its policies and implementations with the national GFW. As illustrated in Figure 1, our investigation reveals that the provincial-level middleboxes in Henan block access to certain HTTP and HTTPS websites through both HTTP Host-based and TLS Server Name Indication (SNI)-based filtering (Section 4.1). Contrasting the GFW that monitors and blocks traffic leaving and entering the country, this regional firewall only censors traffic exiting the province (Section 4.2). It also differs from the GFW in terms of connection tracking and parsing logic (Section 4.3), injection behaviors and fingerprints (Section 4.4), and network location. (Section 4.5).

Figure 1: Henan Province has deployed TLS SNI-based and HTTP Host-based censorship middleboxes that inspect and block traffic exiting the province.

We conduct a longitudinal study to understand the content blocked by the Henan Firewall and how it differs from the content blocked by the GFW (Section 5). Between November 2023 and March 2025 (with a measurement gap between March and October 2024), we tested Tranco top one million domains on a daily basis, and tested CZDS 227 million domains on a weekly basis. We find that the Henan Firewall employs more aggressive and volatile blocking policies than the GFW. The Henan Firewall blocked a cumulative 4.2 million domains, more than five times the size of the GFW’s cumulative blocklist. A key reason for this was its blocking of generic second-level domains (e.g., *.com.au). Our testing also revealed periods where it blocked ten times more domains than the GFW.

Based on the observed parsing flaws and injection behaviors, we introduce circumvention techniques to bypass this regional censorship (Section 6), which have been implemented by various popular anti-censorship tools. The regional censorship in Henan marks one of the first formally documented cases of a provincial firewall operating autonomously in China. We hope our study sounds the alarm to the broader censorship research community to identify, investigate, and combat the emergence of regional censorship in China and elsewhere.

2. Background and Related Work

2.1. The Great Firewall of China (GFW)

The Great Firewall of China (GFW) is a set of different censorship mechanisms and devices deployed in China. The GFW utilizes a network of middleboxes distributed across China’s border autonomous systems (ASes) to inspect and block Internet traffic [17]. The GFW not only blocks access to specific websites and services, but also tries to identify and block attempts to bypass its censorship.

Website censorship. To block access to specific websites and services, the GFW often employs a combination of techniques, including DNS injection [1, 3], HTTP Host-based filtering [8], TLS SNI/ESNI-based filtering [2, 9, 10, 20], and IP address blocking [2 §4].

To censor DNS traffic, the GFW operates on-path to inject forged DNS responses with wrong IP addresses to block access to specific domains [3, 4, 5, 21, 22]. Early reports from 2002 documented that the GFW used a single wrong IP address in its forged responses [23, 24]. Over time, this evolved into a more sophisticated system employing an increasing number of fake addresses and expanding the list of blocked domains [3, 4, 22, 25]. Researchers have uncovered memory disclosure vulnerabilities in the GFW’s injection system [5, 16, 26].

To censor HTTP and TLS traffic, the GFW statefully inspects unencrypted text in the connection. Upon detecting a censored domain in a HTTP request’s Host field or in a TLS ClientHello’s Server Name Indication (SNI) extension, the GFW injects TCP RST packets to both sides of the connection to tear it down [6, 7, 9, 27, 28]. Figure 2 shows the GFW’s operation on a connection containing a forbidden domain name in the SNI of the TLS Client Hello.

Figure 2: Overview of the Henan Firewall and the three different types of GFW. One can trigger and study each censorship mechanism individually by putting exclusively censored domains in the SNI or HTTP Host field of a probe. For example, as of April 2024, 011.com was exclusively blocked by the Henan Firewall, and youtube.com was exclusively blocked by the GFW.

The GFW often operates bidirectionally, meaning both traffic coming into the country and leaving the country can trigger its censorship [4, 9, 29]. The bidirectional operation of censorship middleboxes has enabled researchers to measure censorship from outside the country [3, 30, 31].

Projects such as OONI [32], Censored Planet [33], and ICLab [34] have been measuring censorship globally for years. To monitor website censorship in China, several large-scale projects have been developed, including the GreatFire Analyzer [35], Blocky [36], GFWatch [3], and GFWeb [9]. While longitudinal and large scale studies are excellent at tracking and understanding the blocklist changes in the GFW, sometimes a revisit of the existing censorship mechanisms could still reveal new updates by the censor. For example, Bock et al. [11] discovered secondary TLS censorship middleboxes in China that had operated undetected until an in-depth analysis revealed them.

Proxy censorship. Blocking access to websites is not enough to prevent users from accessing censored content, as users can use circumvention tools to bypass censorship. There has thus been a seemingly endless cat-and-mouse game between the GFW and the Internet users in China [37]. For example, the GFW employs active probing techniques to identify and block circumvention tools, such at Tor [12, 13, 38, 39, 40] and Shadowsocks [14, 15 §5], which have been successfully defended against [41, 42, 43, 44]. The GFW also conducts traffic analysis to identify and block fully encrypted proxies [15].

Other censorship mechanisms. There have also been unique components of China’s censorship that appear separate from the GFW’s censorship against websites and proxies. Notably, in 2015, researchers discovered the “Great Cannon” of China, which injected Javascript into HTTP traffic in order to co-opt victim browsers into participating in a denial-of-service attack against specific hosts [30].

2.2. Regional Variation in Censorship

Localized or decentralized censorship mechanisms are common in countries with strict censorship policies. In Russia, thousands of privately owned ISPs each implement their own filtering mechanisms, resulting in a varied censorship landscape [45, 46, 47]. Similarly, in India, researchers have shown that ISPs differ significantly in their implementation of government censorship orders, leading to fragmented censorship across the country [48].

However, prior work has suggested that China’s censorship systems and policies are largely uniform and centralized across the country. In 2011, Xu et al. [17] measured the location of censorship devices in China. They found that China’s keyword-censoring middleboxes were largely at the edges of the network and employed rules in line with nationwide blocking policies of that time. In 2012, Wright [18] performed a small-scale study on DNS censorship in China, finding that DNS responses to queries varied across the country. However, this work did not account for other possible causes of the variation in DNS responses (e.g. geolocation-based load balancing, or changes in DNS configuration). In 2018, Bao et al. [49] measured DNS injection variances in China from residential and cellular IP addresses. Internet-wide and longitudinal measurements have revealed China’s uniform and coordinated management of censorship policies [4, 3, 15, 9], software updates [16 §4.5] [5 §VII], and infrastructures [14 §3.4] [4 §5].

3. Detecting Regional Censorship

Anti-censorship researchers outside of China often rely on local user reports to learn about the new censorship shifts and upgrades in China. This is partially because of the difficulty for researchers to obtain a diverse range of vantage points inside China and then constantly monitor various Internet services and protocols. Encouragingly, online discussion forums—such as Net4People BBS [50], NTC Party forum [51], and the GitHub issue pages of popular anti-censorship tools such as Xray [52], V2Ray [53], sing-box [54], and Hysteria [55]—enable users to report new censorship behaviors as soon as they encounter them and allow researchers to investigate those reports promptly [37].

This crowdsourced, collaborative approach has also been effective in identifying and combating the provincial censorship in Henan. In particular, our study started with reports from a group of users in Henan who were unable to access certain websites [19, 56, 57, 58, 59]. We then obtained a server in the Henan Province and confirmed the presence of a regional firewall. In particular, as illustrated in Figure 2, we found that the regional Henan Firewall blocked TLS and HTTP connections for some Server Name Indication (SNI) and HTTP Host values, but it operated differently than the GFW. Most distinctively, the regional firewall in Henan blocks a TCP connection by injecting one TCP RST+ACK packet containing a fixed 10-byte payload to the client. The unique payload of TCP RST packet differentiates the Henan Firewall from all three types of packets injected by the GFW.

The discovery of regional censorship in Henan province led to a natural question: have other provinces in China deployed the same or similar regional censorship? Below, we explore this question with measurement across the country.

3.1. Experiment

Our goal is to quantify the regional variation of TLS censorship across China by comparing the number of domains blocked between each pair of hosts inside or outside of China. As summarized by the second row of Table 1, we obtained two vantage points in each of the seven cities in China, including Shanghai, Beijing, Chongqing, Guangzhou (Guangdong Province), Nanjing (Jiangsu Province), Chengdu (Sichuan Province), and Zhengzhou (in Henan Province). We also set up two VPSes in each of the three locations outside of China: Seattle (U.S.), San Francisco (U.S.), and Singapore. Our selection of vantage points was guided by a set of ethical considerations detailed in Section 7.

TABLE 1: Experiment timeline and vantage points. In total, we used 14 VPSes in China VPS Cloud (CVC, AS4837) in Zhengzhou, Henan Province (HN), six VPSes in Akamai Linode (LD, AS63949) in San Francisco (SF), Singapore (SG) and Seattle (SE), 12 VPSes in Tencent Cloud (TC, AS45090) in Beijing (BJ), Shanghai (SH), Chongqing (CQ), Guangzhou, Guangdong Province (GZ), Chengdu, Sichuan Province (CD), Nanjing, Jiangsu Province (NJ), and one bare metal network tap server (TAP) in a U.S. university.

Experiments	Time Span	Duration		China Vantage Points	External Vantage Points	Sections
Identification	7/10/24	1	day	12 (TC), 2 (CVC: HN)	4 (LD: SG,SE)	§3
Characterization	10/2/23 – 11/12/24	13	months	2 (CVC: HN)	1 (LD: SF), 3 (TC: GZ,BJ,SH)	§4
Traffic Analysis	10/31/24	1	hour	–	1 (TAP: US)	§4.3
Locating	10/2/23 – 12/8/23	2	months	1 (CVC: HN), 1 (TC: GZ)	1 (LD: SF)	§4.5
Blocklist	11/5/23 – 3/5/24 & 10/07/24 – 3/31/25	9	months	14 (CVC: HN), 2 (TC: GZ)	2 (LD: SF)	§5

For the two VPSes in each location inside or outside of China, we used one as a client and the other as a sink server. The sink servers were configured to accept TCP handshakes on all ports between 1 and 65535. They would acknowledge the TCP data sent to them, but would never send any TCP payload back to the client. We configured iptables rules on both the client and sink servers to drop any outgoing RST packets. This way, any RST packets received on either end must be injected by some middleboxes on the network path. We could thus confirm the presence of censorship by checking whether the TCP connection was being reset.

We then sent TLS traffic with various SNI values between each pair of the clients and sink servers on July 10, 2024. In particular, we used the top 10,000 domains from the Tranco list [60] 5YZ7N for testing.² To reduce the chances of false negatives due to packet loss, we repeated our test three times on the same day and let the OS control retransmissions of the packets.

² Tranco list ID 5YZ7N, obtained on August 15, 2023: https://tranco-list.eu/list/5YZ7N/1000000.

Limitations. Ideally, we would have liked to use a diverse set of vantage points to identify potential regional censorship in China. However, due to the difficulty of obtaining VPSes in China, we have only been able to obtain vantage points in a limited number of locations and ASes. While using residential vantage points would have allowed us to observe potential middleboxes from more network locations in China, this could put potential risks on uninformed users and providers of residential proxies [61]. For this reason, we focus on using two large VPS providers in China, China VPS Cloud and Tencent Cloud, to avoid risks or persecution to individuals. We utilized all available locations these two VPS providers offered to maximize our coverage. We acknowledge that our results are limited to measuring TLS censorship, which could potentially miss regional censorship of other protocols. Additionally, due to a configuration error, we did not test using our client in Singapore, potentially missing bidirectional censorship from that perspective.

3.2. Results

Figure 3 shows the number of blocked domains between different locations. We first observe that, connections originating from China to our sink servers in Singapore and the U.S. were almost equally impacted by the national-level Great Firewall of China (GFW), with around 479 out of the 10,000 domains blocked. The most significant blocking was observed in Zhengzhou, the capital of Henan province, where both provincial (Henan) and national (GFW) censorship mechanisms contributed to the high figure.

Figure 3: The matrix shows the number of domains blocked between each pair of hosts in various locations. For each host pair, we sent TLS ClientHello messages with SNI values of the top 10,000 domains from the Tranco list [60] 5YZ7N, generated on August 15, 2023. The result suggests that 1) regional censorship in Henan province exists evidenced by the non-zero number of blocked domains when testing from Zhengzhou, Henan to sink servers in other regions of China; 2) the censorship in Henan is not bidirectional, as initiating TLS connections from the outside to Henan did not trigger any blocking; 3) the GFW maintains a blocklist that is only censored when accessed from within China, as evidenced by the differences in the numbers of blocked domains when testing inside-out and outside-in.

Traffic leaving Henan is affected by the regional firewall, regardless of the sink server location, even to other regions within China. On average, 122 domains were blocked by the Henan Firewall. We did not observe any blocking of TLS connections within Henan itself; however, since both of our client and sink servers were in the same data center, we can only cautiously conclude that the Henan Firewall does not affect internal traffic within this data center.

When connections were made from Zhengzhou, Henan Province, to locations outside China (Singapore and Seattle), a total of 594 domains were blocked. This indicates the simultaneous operation of two firewalls with independent blocklists, with the Henan Firewall intercepting traffic before it reaches the GFW and thus, increasing the total number of domains that are blocked. We, however, did not observe any blocking of connections from other client locations in China to Henan or other sink server regions within China. This finding suggests that the Henan Firewall is the first known deployment of a regional firewall in China.

Moreover, as presented in the last row of Figure 3, tests from the U.S. to various locations in China consistently identified the same 411 domains blocked by the GFW, with only one exception: tests from the U.S. to Jiangsu Province detected 440 blocked domains. Further analysis indicates that the additional 29 domains blocked in the outside-in direction for Jiangsu is a subset of the 479 domains blocked by the GFW in the inside-out direction. This finding suggests that the additional censorship of these 29 domains likely does not reflect regional censorship specific to Jiangsu. Instead, it indicates that the GFW is configured to block these domains bidirectionally within Jiangsu.

Overall, these results are particularly noteworthy as they show the infeasibility of remote measurements to trigger the regional firewalls and more importantly, the asymmetric behavior of the GFW. In particular, while 479 domains were blocked on average when connections were initiated from within China, only 411 domains were blocked when connections were initiated from outside China. This discrepancy suggests that the GFW enforces a different blocklist for traffic originating from within China. Until recently, it was widely believed that the GFW operated symmetrically, triggering and applying the same blocklist to traffic regardless of direction. However, recent work has suggested this assumption is incorrect [9], and our findings here are consistent with this recent result.

We note that both the GFW and the Henan Firewall exhibit asymmetric interference to varying degrees. As shown in Figure 4(a) , while traffic going out of Henan is subject to the regional firewall (inside-out), inbound traffic (outside-in) to Henan does not trigger the regional firewall at all. This stands in contrast to the GFW, which, although bidirectional, behaves asymmetrically based on the domains queried.

Figure 4(b) provides a clear example of this behavior. When a TLS ClientHello with SNI value docker.com, in our case, is sent from within China (inside-out), the GFW triggers blocking via three TCP RST packets. However, when the same TLS ClientHello is sent from outside of China (outside-in), the GFW does not trigger any blocking. On the other hand, when a TLS ClientHello packet with the SNI value youtube.com, in this example, is sent, the GFW triggers blocking in both scenarios: whether the packet is sent from inside or outside China. This behavior demonstrates an apparent blocklist of domains that are exclusively censored by the GFW when accessed from within China.

(a) Henan Firewall

(b) GFW

Figure 4: (a) The Henan Firewall does not censor inbound TLS or HTTP traffic to Henan, contrasting the bidirectional censorship employed by the GFW. (b) The GFW’s TLS and HTTP censorship machines inspect bidirectional traffic coming in and out of China; however, certain domains are only censored when accessed from within China. In this example, while a TLS ClientHello with SNI value docker.com can trigger the three TCP RST packets by the GFW when sent from within China, it does not trigger any blocking when sent from outside of China.

In our experiment designed to detect any regional censorship, we inadvertently uncovered a significant aspect of the GFW’s operational mechanics that has only recently been documented [9]. The newly observed asymmetric nature of the GFW and regional firewalls highlights the critical need for inside-out measurements to fully capture the extent and nuances of censorship. Relying solely on remote measurements, as is common in many other studies, fails to provide a comprehensive picture of such censorship events.

To further substantiate the asymmetric behavior of the GFW, we provide a list of domains that are exclusively blocked when sending TLS ClientHello messages from within China, as shown in Table 2. In our experiment, 68 out of the 10,000 domains did not trigger any censorship when tested from outside China but only were blocked when probed from inside China. These domains include popular websites such as google.com, nyt.com, and docker.com. The list serves as concrete evidence of the selective enforcement of the GFW’s blocklist based on the origin of the traffic and the domain in question.

TABLE 2: A sample of domains that are exclusively blocked by the GFW when sending TLS ClientHello messages from within China. These domains did not trigger censorship when sent from outside China to within, as of July 10, 2024. Among the 10,000 Tranco top domains we tested, 68 domains were exclusively blocked inside-out and no domains were exclusively blocked outside-in.

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

4. Characterizing the Censorship Devices

Since October 2023, we conducted a series of experiments to characterize censorship devices and understand the differences between the Great Firewall (GFW) and Henan regional censorship devices. In this section, we answer several research questions: where are the regional censorship devices located? What packets can trigger the Henan SNI Firewall? Which ports are monitored by the Henan Firewall? Do the TCP RST injections have any specific fingerprints? And does the Henan Firewall induce residual censorship?

4.1. Methodology

We developed a methodology tailored to the specific characteristics of two firewalls, i.e., regional and national, as discussed earlier. To precisely assess the impact of each firewall, our approach involves isolating and analyzing these two systems individually. This method, which was devised based on our preliminary observations, serves as the foundation for our comprehensive measurement experiments. Key aspects of our methodology are outlined below.

Obtaining Vantage Points. In total we use 10 vantage points in Zhengzhou, China (in Henan) acquired via China VPS Cloud (AS 4837), two VPSes in Guangzhou, one in Beijing, and one in Shanghai via Tencent Cloud (AS 45090), and two VPSes in San Francisco, U.S. through Akamai’s Linode (AS 63949). The VPSes in Guangzhou, Beijing, Shanghai and San Francisco served as sink servers that were programmed to listen on ports 1 to 65535 and accept TCP connections but did not send any other data back to the sender. All our machines ran Ubuntu 22.04, and we verified their advertised locations using the IP2Location [62] database. We have summarized the timeline of our experiments and the vantage points used in each in Table 1.

Dropping Outgoing RSTs on the VPSes. We configured iptables rules on both the client and sink servers to drop all outgoing RST packets. This configuration ensures that any RST packet received by the client side can be reliably attributed to middlebox injections.

Triggering TLS SNI-based Censorship. We trigger censorship by sending a TLS ClientHello with potentially censored domain names in the SNI field. Since the sink servers are configured to not respond with any data packets and not tear down connections before observing a FINor a RST packet, we expect any RST packets received are indeed injected packets from a firewall. We mark a domain name as censored if a RST packet is received for a TLS ClientHello containing the domain name.

Triggering HTTP Host-based Censorship. To trigger HTTP censorship, we sent HTTP GET requests with the forbidden domain name in the Host header of the request:


            GET / HTTP/1.1\r\nHost: example.com\r\n

While later we found that the Henan Firewall does not require a full TCP handshake to trigger blocking, we still complete a TCP handshake before sending the HTTP request, making our testing methods consistent against the Henan Firewall and the GFW. We mark a domain name as censored if a RST packet is received for an HTTP GET request containing the domain name.

Isolating the Henan Firewall. To distinguish Henan Firewall responses from the GFW’s, we identify several fingerprints unique to each firewall. Prior work has documented the GFW disrupts connections by injecting up to three RST+ACK to both sides of the connection whenever a TLS ClientHello message with a forbidden Server Name Indication field is observed [2, 63]. In contrast, the Henan Firewall injects a single RST+ACK packet to only the client side of a connection. In addition, the Henan Firewall’s RST+ACK packet contains a payload, making it easy to distinguish from GFW responses. We expand on this in Section 4.4.

Finally, we send probes from vantage points in Henan to servers in Guangzhou, Beijing, and Shanghai to make sure that our traffic is not routed outside China (where it may encounter the GFW) but is still subject to the regional firewall in Henan.

Limitations. Our measurements in Henan Province are limited to a single Autonomous System (AS), China Unicom (AS 4837), due to the difficulty of obtaining diverse vantage points in China that could be ethically used for censorship measurement. Consequently, our empirical findings are confined to this single Internet Service Provider (ISP), limiting our ability to confirm or characterize censorship practices across other ISPs or ASes in Henan.

While user reports suggest that ISPs in Henan employ region-specific censorship, the censorship implementations are reportedly distinct [64]. For instance, Github user 5e2t reported that China Mobile Henan censored traffic on its cellular network and was capable of reassembling closely spaced TCP packets [64], which differs from the behavior we observed on China Unicom in Section 4.3. Therefore, our results should be interpreted as reflective only of China Unicom Henan’s censorship implementation, not necessarily indicative of province-wide practices across all ISPs.

4.2. What Traffic Is Targeted

Does the Henan Firewall sample traffic to monitor and censor? The censor has been observed to only monitor and censor a fraction of traffic, potentially as a way to reduce the computation load on its censorship devices [15 §6.3]. We, however, did not observe any traffic sampling or probabilistic blocking behaviors from the Henan Firewall. We observed that the Henan Firewall consistently blocked domains listed on its blocklist. We sent 1,000 consecutive ClientHello messages containing a forbidden domain name, each request made over a unique port pair with small delays. We received the TCP RST packets for every connection we made, indicating a 100% triggering rate of censorship for censored domains of the Henan Firewall.

What ports does the Henan Firewall monitor? Previous works have shown that the GFW TLS ESNI censorship middleboxes monitor all ports i.e. 1-65535 [10]. To measure the Henan Firewall, we sent TLS ClientHello messages, with a known blocked SNI to all ports of our sink server in Guangzhou, China. We found that the Henan Firewall, similar to the GFW, monitors TLS traffic going to any TCP port number, ranging between 1 and 65535.

Is the Henan Firewall bidirectional? Owing to the inherent limitations of obtaining vantage points in a censored region, researchers typically opt for performing measurements from the outside in rather than inside out. Particularly in China, works that study the GFW [3, 4, 9] used vantage points outside China because of its bidirectional nature. However, as mentioned in Section 3, sending probes from outside China does not trigger the Henan Firewall as it only censors traffic going out of Henan. As shown in Figure 3, we tested this by sending TLS ClientHello messages with different SNI values in the Tranco list [60] 5YZ7N, between nodes in Henan and nodes in other regions of China. We found that only traffic going out of Henan was blocked by the regional firewall. Similar asymmetric blocking behaviors were also observed in the GFW by prior work [9, 10].

4.3. How the Henan Firewall Parses Connections

In this section, we look at the parsing logic of the Henan Firewall and the GFW. We perform experiments to check the TCP handshake requirements for triggering the Henan Firewall and the GFW. We also use DPYProxy [65] to test for TCP and TLS reassembly capabilities, as well as the presence of residual censorship in the two firewalls. We summarize our findings in Table 3.

TABLE 3: Parsing logic of the GFW and the Henan Firewall. The Henan Firewall appears to be stateless and less robust against typical network variability than the GFW.

	GFW	Henan Firewall
Require SYN	✓	✗
Require SYN+ACK	✗	✗
TCP Reassembly	✓	✗
TLS Reassembly	✗	✗
TCP Header Length	Arbitrary	20 bytes Only

TCP handshake completeness requirements. The middleboxes designers often need to make a trade-off between the complexity of the parsing logic and the efficiency of the traffic analysis operations. For example, due to asymmetric routing nature of the Internet, and the fact that Henan Firewall and the GFW are not always immediate neighbors of the client or the server (as shown in Table 5), the middleboxes may only be able to observe flows in one direction. This nature often makes the middleboxes’ designers forgo requiring a complete TCP three-way handshake to track TCP connections and conduct censorship. On October 10, 2024, we tested the requirements of the TCP handshake completeness for the Henan Firewall and the GFW from our vantage point in Henan. We sent a single TCP packet whose payload is a TLS ClientHello message contained a forbidden domain name 011.com as the SNI, preceded by 1) a SYN packet from client, or 2) a SYN packet from the client and a SYN+ACK packet from the server, or 3) no packet at all.

As summarized in Table 3, while the GFW requires to observe a SYN packet from the client (but not a SYN+ACK packet from the server) to trigger the censorship [9], the Henan Firewall does not require to observe any TCP handshake packet to be triggered.

TCP segmentation. TCP segmentation enables the splitting of larger TCP payloads into smaller ones. In the context of circumvention, splitting a TLS ClientHello message into multiple TCP segments has been used to confuse stateless censors that do not reassemble packets. However, we confirm that the GFW performs TCP reassembly and thus, is stateful. On the other hand, we found that the Henan Firewall does not perform TCP reassembly and thus, it is possible to bypass it by splitting the TCP payload of the ClientHello into multiple TCP segments, with the SNI distributed between the segments. We tested this by initiating a TLS connection from our vantage point in Henan to our VPS in Guangzhou with a forbidden SNI and splitting the ClientHello into two segments, with the second segment containing the forbidden domain name. We observed that while a complete ClientHello message was blocked by the Henan Firewall, not putting a complete SNI extension in the first segment would bypass the Henan Firewall.

TLS fragmentation. While TCP segmentation has been long known to be used to bypass stateless censors, the use of TLS fragmentation was only recently analyzed by Niere et al. [65] and implemented in their DPYProxy tool. Before a TLS message is encapsulated within a TCP segment, it is first enclosed in what is known as a TLS record. Given that the maximum size of a TLS message exceeds the maximum allowable size for a TLS record, the TLS standard permits the division of TLS messages across several TLS records. Niere et al. [65] found that the GFW did not perform TLS reassembly, and it is thus possible to bypass it by fragmenting TLS ClientHello messages over multiple TLS records, wherein the SNI is split into multiple TLS segments within the same TCP payload. We confirm that, as of April 4, 2024, both the Henan Firewall and the GFW do not perform TLS reassembly and thus, it is possible to bypass them via TLS ClientHello fragmentation.

TCP header length has to be 20 bytes. The four most significant bits of the 13th byte of the TCP header represent the TCP Data Offset, which specifies the length of the TCP header in 32-bit words. The minimum value of the TCP Data Offset field is 5 words (20 bytes) when no TCP options are present, and the maximum value is 15 words (60 bytes).

We found that the Henan Firewall required the TCP header length to be exactly 20 bytes to correctly parse and block the TLS ClientHello or HTTP request messages. We tested this by sending forbidden messages (e.g. TLS ClientHello messages with a forbidden SNI 011.com) from our vantage point in Henan to our sink server in Guangzhou on October 17, 2024, with different TCP options set in their TCP headers. While varying the TCP header length, we made sure that the TCP options are always a multiple of four bytes to comply with the 32-bit word alignment requirement of TCP header. The TCP options we tested include common TCP ones like Maximum Segment Size (MSS), Window Scale, Timestamps, Selective Acknowledgment Permitted (SAckOk), No Option (NOP), End of Option List (EOL), as well as self-defined TCP options that are not commonly used. We found that as long as any TCP option was set, the Henan Firewall did not block the connection.

An intuitive hypothesis to explain this strange behavior is that the Henan Firewall does not parse the TCP header length field in the TCP header, and falsely assumes that the TCP header length is always 20 bytes. This way, when a TCP header has more than 20 bytes due to TCP options, it will treat the TCP options as part of the TCP payload and will thus fail to recognize a complete TLS ClientHello or an HTTP request message. However, we falsified this hypothesis and confirmed the Henan Firewall did parse the TCP header length field. In particular, we sent TLS ClientHello messages with a forbidden SNI 011.com with no TCP option set in its TCP header, confirming that this message was blocked by the Henan Firewall. If the Henan Firewall does not parse the TCP header length field in the TCP header, then regardless of the TCP header length value we put in the TCP header, this message should be blocked. We changed the 4-bit TCP header length field in the TCP header to be all 2⁴ possible values from 0 to 15, and recomputed the correct TCP checksum for each TCP packet, and found that the Henan Firewall only blocked a connection when its TCP header length value was 5 words (20 bytes). This experiment indicates that the Henan Firewall did parse the TCP header length field in the TCP header, but had a condition to only block a connection when its TCP header length is 20 bytes.

Although we were unable to determine the rationale behind this condition—possibly an oversight by the censor—it raises an important question about how much real-world traffic evaded detection due to this condition. We conducted a test on a university network in the United States. Specifically, we used Retina [66] to capture the TCP header length fields for all traffic on the campus network over a one-hour period from 3:56:14 PM to 4:56:14 PM (UTC–7) on October 31, 2024. In total, we collected 23.1 billion TCP packets and 5.0 billion TLS packets. As shown in Figure 5, only 22% of the TCP packets had a header length of 20 bytes, and only 19% of the TLS packets had a header length of 20 bytes. This result suggests that the Henan Firewall may only be able to censor around 20% of the targeted connections.

Figure 5: The distribution of the TCP header length fields of all TCP and TLS packets during a one-hour captured on a university network on October 31, 2024. In total, we captured approximately 23.1 billion TCP packets and 5.0 billion TLS packets. Only 22% of any TCP packets have a header length of 20 bytes, while only 19% of any TLS packets have a header length of 20 bytes. This evaluation result suggests that the Henan Firewall has only been able to censor around 20% of the targeted connections.

4.4. How the Henan Firewall Blocks Traffic

Does the Henan Firewall employ residual censorship? Residual censorship is a mechanism used by censors in which after a censorship event is detected between two hosts, the censor continues to block all subsequent connections between the two hosts (SrcIP, DstIP, DstPort - three tuple) for a certain duration typically 90 s or 180 s. The phenomenon has been documented by multiple previous works, studying the GFW [6, 8, 67]. We found that the Henan Firewall does not perform any residual censorship. We were able to make connections with the same three-tuple after any reset injections from the Henan Firewall.

Fingerprinting the injection behaviors. Continuing the efforts of fingerprinting the GFW’s evolving injection behaviors [7 §2.1, 65 §3.1, 68, 69, 70 §7.1.6], we fingerprint the TCP RST packets injected by the GFW and the Henan Firewall. Using the RST packets collected in Section 4.5, we analyze their packet features such as IP ID, IP TTL, TCP Flags, TCP Payload, and Payload Length.

TABLE 4: A comparison of the injection behaviors and packet fingerprints of the Henan Firewall and the three types of GFW TCP RST injectors. All injections were triggered by TLS SNI-based censorship. The IP TTLs shown are the observed values; their initial values should be higher. The 'C' and 'S' refer to the client and server.

	GFW (I)	GFW (II)	GFW (III)	Henan Firewall
Observed IP TTL	55–118	39–238	248	58
IP ID	0000	00A3 – FE5F	9916 – 9933	0001
IP Flag (DF)	0	1	0	0
TCP Payload Len	0 byte	0 byte	0 byte	10 bytes
TCP Payload	-	-	-	0102 03 04 05 06 07 08 09 00
TCP Flags	RST	RST+ACK	RST+ACK	RST+ACK
Packet Counts	x1	x3	x1	x1
Targeted Hosts	C&S	C&S	C&S	C
Residual Duration	180 s	180 s	180 s	-

Table 4 compares the reset packet-injection behaviors of the Henan Firewall against three types from the GFW (I, II, III). While the GFW injection mechanisms target both client (C) and server (S), the Henan Firewall exclusively injects reset packets to the client side.

Examining IP and TCP flags of the RST packets from firewalls, we observed that the Henan Firewall sent a single RST+ACK packet with the IP DF (Do Not Fragment) flag unset. Among the GFW injectors, type I sends a single RST packet without ACK with the IP DF flag unset, type II sends three duplicate and identical RST+ACK with IP DF set, and type III sends a single RST+ACK packet with IP DF unset.

The observed IP TTL values of the TCP RST packets by the three GFW injectors exhibited a range of values: 55–118 for type I, 39–238 for type II, and a fixed value of 248 for type III. We observed a fixed IP TTL value of 58 for the RST+ACK packets from the Henan Firewall. We note that these values are the IP TTL values observed by the client; the initial TTL values set by the censorship devices would have been higher, subsequently reduced by the number of network hops from the censorship devices to the client.

Regarding IP ID values, we observed that the Type I GFW inject one RST packet with a fixed IP ID of 0x0000, the Type II GFW injects three RST+ACK packets with a range of IP ID values from 0x00A3 to 0xFE5F (163–65119), and the Type III GFW injects RST+ACK packets with a range of IP ID values from 0x9916 to 0x9933 (39190–39219). The Henan Firewall, on the other hand, had a fixed IP ID value of 0x0001 for its TCP RST packets.

The most distinctive fingerprint of the Henan Firewall’s RST packets is their 10-byte TCP payload pattern 0102 03 04 05 06 07 08 09 00 , a characteristic not found in any of the GFW injectors. While RFC 9293 states that “TCP implementations SHOULD allow a received RST segment to include data (SHLD-2)” [71 §3.5.3], it is still very rare to see a RST packet with a payload in real world. In Section 6, we introduce a circumvention technique that leverages this distinct fingerprint to bypass the Henan Firewall.

4.5. Where Are the Censorship Devices Deployed

To find where in the network the Henan regional firewall devices are located, we used a variant on our methodology to measure the network time and TTL-hop distance of the censorship devices from our Henan client.

First, we sent ClientHello packets from our vantage point in Zhengzhou, Henan Province to our sink servers in Guangzhou and San Francisco independently, and measured the time difference between when we sent a ClientHello and when we received a RST for any of the connections. We utilized the top one million domains from the Tranco list performed the experiment four times in a day and recorded any RST packets that we received.

Figure 6 shows the cumulative distribution of the time difference between sending a ClientHello message and receiving the first TCP RST packet by the Henan censorship devices and the GFW. The analysis is based on 36,480 RST packets received from Henan and 16,649 RST packets collected from the GFW between October 2 and December 8, 2023. Although the GFW can inject more than three RST packets for a blocked connection, we account only for the first RST packet received since it is the one that initiates the connection tear down. The graph clearly shows the difference in latencies: the delta timing differences indicate that Henan censorship devices were located closer to the client, whereas the GFW was situated at the national gateway. Specifically, the delta times for the GFW ranged from 11.52 ms to 445.38 ms (with a mean of 17.98 ms), while those for the Henan devices ranged from 2.30 ms to 30.49 ms (with a mean of 2.82 ms). This evidence strongly suggests that the regional censorship in Henan is independently deployed and in closer proximity to our vantage points, implying that these censorship devices are located within the Henan province.

Figure 6: Cumulative distribution of the time difference between sending a TLS ClientHello packet containing a forbidden domain name and receiving the first forged TCP RST packet from the censorship devices.

Second, to identify the exact network hop where censorship occurs, we used a TTL-limited probing method based on traceroute. Specifically, we sent TLS ClientHello packets containing a known censored domain, gradually increasing the IP TTL value of the probes until an injected RST packet was observed. The TTL of the probe that triggered the RST reflects the hop count to the censoring device. This approach is similar to that used in prior work such as CenTrace [72].

TABLE 5: Results from our TTL-limited probing experiment, showing that the Henan middleboxes are two hops closer to our client compared to the GFW. We sent TLS ClientHello probes from Zhengzhou, Henan to a sink server in San Francisco, US, triggering two distinct middleboxes at different hops.

	Hops Away	ASN	ISP
Henan	5	4837	China Unicom Henan Province Network
GFW	7	4837	Backbone - China Unicom

Table 5 shows results from our measurements conducted in Zhengzhou, targeting a sink server in the US. We used 011.com to trigger regional censorship (Henan) and youtube.com for national-level censorship (GFW). Our findings indicate that the Henan middlebox is located at hop 5 within China Unicom’s provincial network, while the GFW appears at hop 7, deeper in the national backbone network. These results confirm that both censoring entities operate as on-path middleboxes, with the Henan device positioned closer to the client.

5. Understanding the Blocklists

We monitored and analyzed the websites blocked by the Henan Firewall and the GFW across time. We also inferred the underlying blocking rules employed.

5.1. Analyzing the Blocked Domains

Experiment setup. Due to the challenge of obtaining high-bandwidth machines in Henan, we divide our measurements into two parts. First, we perform daily tests on the top one million websites from the Tranco list 5YZ7N. Second, carried out weekly, we test 227 million domains sourced from the zone files of more than 1,000 Top-Level Domains (TLDs), obtained from the Centralized Zone Data Service (CZDS) of the Internet Corporation for Assigned Names and Numbers (ICANN) [73].

For our daily test of the Tranco top one million domains, we tested both TLS SNI and HTTP Host-based blocking by sending respective requests to servers we controlled in China. For each domain, for TLS SNI-based censorship, we sent four requests per day; for HTTP Host-based censorship, we sent two per day. For a given day, we mark a domain as blocked for that protocol if it receives a TCP RST in response to any of our requests.

Due to the bandwidth constraints, for the 227 million tested weekly, we send a single TLS request per domain each week to our server, and mark the domain as blocked if our request receives a TCP RST.

Experiment timeline. Table 1 summarizes the specific experiment timeline and vantage point usage. In particular, we failed to run the longitudinal experiments between March 5 and October 7, 2024. There were also minor data gaps, also reflected in Figure 7, due to unexpected disruptions of our VPSes in Guangzhou. Since we used the same machines to measure both the Henan Firewall and the GFW, the disruptions experienced by our sink servers in Guangzhou impacted our measurements of both firewalls. We thus removed these minor measurement gaps, counting towards an additional 25 days, from our analysis.

Figure 7: The numbers of domains blocked by the Henan Firewall and the GFW over time. We tested with a Tranco top one million domain list ID 5YZ7N, between November 5, 2023 and March 31, 2025, with a measurement gap between March 5 and October 7, 2024.

The Henan Firewall uses the same blocklist for HTTP Host-based and TLS SNI-based censorship. Prior work has shown that the GFW maintains different domain-based blocklists to censor different protocols [2 §4.1] [9 §5.2]. In contrast, we find the Henan Firewall uses the same blocklist for both HTTP Host-based and TLS SNI-based censorship. In particular, we compare the lists of domains that were blocked by Henan’s HTTP Host-based and TLS SNI-based censorship on the same day (November 14, 2024). A similar number of domains is blocked in each protocol: 24,795 domains blocked by HTTP Host-based censorship, and 24,974 domains blocked by TLS SNI-based censorship. The small 1% difference between these two lists is explained by measurement noise: we repeated the same detection for the divergent domains twice to reduce false negatives, and found the difference between lists disappeared.

Comparing the sizes of the blocklists over time. We monitored the changes to the blocklists of the Henan Firewall and the GFW over time. Figure 7 shows the total number of domains blocked by the Henan Firewall and the GFW. The Henan Firewall has a blocklist that remains much larger than the GFW blocklist until March 4, 2025.

The Henan Firewall frequently added and removed generic second-level domain blocking rules (e.g. *.com.au, *.net.br, *.gov.co), causing dramatic changes in the number of blocked domains. For example, Figure 7 shows a large consistent drop in the number of domains being blocked by the Henan Firewall, between November 10 and December 8, 2023. This drop was mostly due to the removal of at least 112 generic second-level domain blocking rules. In particular, the removal of the blocking rule *.com.au itself contributed to the unblocking of more than five thousands domains on November 22, 2023.

We observe that the blocklist used by the Henan Firewall also targets websites that are related to state or city governance from other countries. For instance, a majority of state government websites from the United States such as texas.gov, seattle.gov, alabama.gov, nc.gov are all blocked in Henan but not by the GFW. Compared to the 83 *.gov* domains that are seen in the GFW blocklist, we found 1002 *.gov* domains blocked by the Henan Firewall, showing an inclination to block anything that exhibits governance data or news from around the world. In fact, we noticed a trend in the Henan Firewall to target country code top-level domains (ccTLDs) more than the GFW as can be seen in Table 6. Some of these blocks were widespread: In 2024, Henan blocked all 5,334 *.com.au domains we tested on Jan 19 and Feb 1–2, all 2,075 *.co.za domains Feb 15–Mar 4, and all 1,547 *.org.uk domains Feb 8–Mar 4. These may be instances of overblocking, where the firewall contains an overly broad rule. It is unclear to us why the Henan Firewall would repetitively block and unblock these country code second level domains.

TABLE 6: Top ten TLDs censored by the GFW and the Henan Firewall over a period of three months. The Henan Firewall blocked more country code top-level domain (ccTLDs) than the GFW.

GFW	Henan
TLD	Blocklist %	TLD	Blocklist %
.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%

Henan Firewall’s blocklist is more volatile than the GFW’s. As shown in Figure 8, the Henan Firewall has more volatile blocking policy than the GFW’s blocklist. While 75% of blocked domains were censored for fewer than 51 days by the Henan Firewall, more than 50% of the domains ever censored by the GFW were blocked during the entire measurement period (256 days). Domains blocked by the GFW had longer censorship durations (mean: 173.8 days; median: 256 days) compared to those blocked by the Henan Firewall (mean: 35.7 days; median: 21 days).

Figure 8: The censorship duration of all domains (ever) blocked by the GFW and the Henan Firewall between November 5, 2023 and March 31, 2025, with a measurement gap between March 5 and October 7, 2024. Compared to the GFW, the Henan Firewall has a more volatile blocking policy, with a larger proportion of domains being blocked for a shorter duration.

As mentioned above, this volatile blocking policy of the Henan Firewall is also mostly due to the frequent addition and removal of generic second-level domain blocking rules. For example, Figure 7 shows two spikes in the number of domains blocked by the Henan Firewall between January 11 and January 12, 2024, as well as between February 1 and February 3, 2024. They are mostly due to the addition and removal of the blocking rule *.com.au. It is worth noting that even when the rule *.com.au was removed, for example on January 12 and February 3, 2024, the Henan Firewall still blocked 44 and 26 domains ended with .com.au, respectively. This observation suggests that the blocking rule can be finer grained than the second-level domain.

Do the two firewalls target similar websites? Figure 9 shows the cumulative distribution of the domains blocked by the GFW and by the Henan regional censorship devices among the top one million Tranco domains over our measurement period of nine months.

Figure 9: Cumulative distribution of the domains blocked by the GFW and the Henan Firewall in the Tranco top one million list 5YZ7N. The data is collected between November 5, 2023 to March 31, 2025, with a measurement gap between March 5 and October 7, 2024.

For the GFW, we classify a domain as blocked if it was blocked at least once during our measurement period. Due to the volatility of the Henan Firewall’s blocklist, we categorize domains into three classes: those that were ever blocked, those blocked for less than 21 days, and those blocked for less than 51 days. We selected these thresholds based on our observation of average blocking durations for both firewalls, as shown in Figure 8.

During our measurement period, we cumulatively observed 25,441 domains censored by the GFW, while 175,925 domains were blocked at least once by the Henan Firewall. Of the domains censored by the Henan Firewall, our analysis identified 104,100 domains with blocking periods under 21 days, while 163,083 domains experienced blocking durations shorter than 51 days.

Looking at the cumulative distribution and the ranking of the domains, we found that the most popular domains were more likely to be blocked by both the GFW and the Henan Firewall. The Henan Firewall is more homogeneous in blocking domains in terms of their popularity whereas the GFW’s blocklist exhibits a more heterogeneous distribution. While the GFW firewall targets the more popular websites, as can be seen from the graph, the Henan Firewall targets the websites more uniformly. However, the sizes of the two blocklists provide a stark contrast between the two firewalls.

Overlap between the two blocklists. To understand the sizes and overlap of the two blocklists, we perform a long-running experiment to test 227 million domains on a weekly basis, between December 26, 2023 and March 31, 2025. Figure 10 shows the accumulated blocklists of the GFW and the Henan Firewall. During the experiment, the Henan Firewall blocked 4,196,532 domains—more than five times the 741,542 domains ever blocked by the GFW. There are 479,247 domains blocked by both firewalls. The Jaccard index between the two blocklists is approximately 0.0885, indicating they share under 9% similarity and are therefore largely independent yet complementary in their coverage.

Figure 10: Venn diagram of the cumulative domains ever blocked by the GFW and the Henan Firewall. We conducted weekly testing of 227 million domains between December 26, 2023 and March 31, 2025 (with a measurement gap between March 5 and October 7, 2024). The Henan blocklist is more than five times the size of the GFW blocklist.

Categorizing the blocked domains. we used the whoisxmlapi.com [74] website categorization service to classify the blocklists obtained for each firewall between November 21, 2023, and January 15, 2024. We acknowledge that not all domains could be categorized, as some were inactive or did not host content. Table 7 shows the top ten categories of censored domains for each firewall.

TABLE 7: The top categories of domains blocked by the Henan Firewall and the GFW among the top one million Tranco domains. Categories not in the top ten of each firewall are marked as “-”.

Category	Henan	GFW

	Count	Portion (%)	Count	Portion (%)
Business	4861	26.9	1183	15.3
Computer	2517	13.9	642	8.3
Pornography	2394	13.2	2207	28.6
Gambling	1276	7.1	–	–
Society	1265	7.0	459	5.9
Shopping	1261	7.0	288	3.7
Travel	1230	6.8	–	–
Entertainment	1134	6.3	548	7.1
Education	1104	6.1	–	–
Uncategorized	1057	5.8	395	5.1
News	–	–	1378	17.9
Personal Sites	–	–	313	4.1
Streaming Media	–	–	305	4.0

An interesting point that we note here is that the Henan Firewall targets Business, Economy, Computer and Internet Information domains more than the GFW. More than 35% of the total domains appearing on the blocklist of the Henan Firewall were from these two categories. To find the reason behind the focus on these categories, we hypothesize that the province of Henan has been a center of a lot of financial controversies, with the most prominent being the mass protests in 2022 that were a result of a financial scandal involving local lenders [75]. Given the financial scandals targeting state-controlled financial institutions, it is very probable that the state wants to limit access to information that is relevant to the economy of the area. On the other side, it could be a part of the national policy to censor critics of the country’s business and economic policies.

The GFW on the other hand, targets more of the news and media, as well as adult content domains. This is in line with the long-standing understanding of the GFW that it aims to limit more of the news, morally sensitive and politically sensitive content.

5.2. Identifying the Blocking Rules

Another way to view how each of the firewalls configures filter rules is to infer likely regular expressions used for blocklist matching. As noted by Anonymous et al. [22 §6] and Hoang et al. [3 §4.1] in their study of the GFW’s DNS censorship, the GFW blocks domains using rules that may target second-level domains, top-level domains, and/or subdomains. They developed a methodology to encompass the blocking rules applied by the GFW. We used a similar methodology based on the permutations listed in Table 8 to infer blocking rules for both the Henan Firewall and GFW. We note that our inferred regular expressions may not fully reflect the rules employed by the censor, as our permutations can miss regular expressions based on second-level domains or more complex regular expressions such as *.gov* that we observe the Henan Firewall blocking. Nonetheless, our inferred rules allow us to identify structural differences in the blocklists of the Henan Firewall compared to the GFW.

TABLE 8: Permutations used to test the blocking rules of the Henan Firewall and the GFW. The placeholder {str} represents strings that, alone or combined with others, should not trigger censorship. In this work, we used the string ZZZZ.

Test	Pattern	Test	Pattern
Test 0	{str}domain{str}	Test 5	{str}domain
Test 1	domain	Test 6	{str}.domain.{str}
Test 2	domain.{str}	Test 7	{str}.domain{str}
Test 3	domain{str}	Test 8	{str}domain.{str}
Test 4	{str}.domain

As shown in Table 8, we generated nine permutations for each censored domain identified in our daily measurement experiment (Section 5), by prepending and/or appending a fixed string to the domain name. This methodology was used by Anonymous et al. [22 §6] in 2014 and Hoang et al. [3 §4.1] in 2021. We chose the pattern string ZZZZ to construct each permutation in this work. We then sent ClientHellos with SNI containing each permutation independently to our sink servers and recorded the results for each testing. This experiment was conducted four times daily during our measurement period.

As shown in Table 9, the most popular blocking regex pattern used by both the Henan Firewall and the GFW was ^(.*\.)?keyword$. This pattern meant to be used to block a domain and its subdomains. The second most popular blocking regex pattern used by the GFW was ^keyword$, which was used to only block the domain name itself, not its subdomains. The third most popular blocking regex pattern used by the GFW was ^(.*\.)?keyword, which was likely to be a mistake of not including the end anchor in the regex pattern. Interestingly, unlike the GFW, which sometimes employs regex patterns without end anchors, the Henan Firewall always includes end anchors in its regex patterns. This result could be because of a more carefully and consistently maintained blocklist, or perhaps the censorship implementation itself enforces the use of end-anchored regex patterns to prevent potential mistakes made by human.

TABLE 9: We infer the regex equivalents of blocking rules employed by the GFW and the Henan Firewall. In total, the GFW and the Henan Firewall employ 24 and 5 unique regex patterns, respectively. The table only shows the regex patterns that have more than ten occurrences for the GFW.

Inferred Regex	Tests Hit	Rule Count (Portion)

		GFW	Henan
`^(.*\.)?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%	–	–

6. Circumvention Strategies

Based on the parsing logic flaws we identified in Section 4.3, as well as the injection behaviors and fingerprints we observed in Section 4.4, we introduce simple but effective strategies to bypass the Henan Firewall. All strategies require only changes from the client-side, without cooperation from the server side, making them easy to employ and adopt. These strategies have already been implemented in various popular circumvention tools, including but not limited to Xray [76], GoodbyeDPI [77], and Shadowrocket [78].

Enable any TCP option field. As detailed in Section 4.3, the Henan Firewall can only parse and block TCP packets with a 20-byte header. Enabling any TCP option on an operating system will result in a TCP header longer than 20 bytes. While this circumvention solution relies on the unusual implementations of the Henan Firewall, it is nonetheless a feature that users or circumvention tools could easily employ to evade censorship. For instance, enabling TCP Timestamps (disabled by default on some versions of Windows) would prevent the Henan Firewall from blocking connections [56, 59].

Discard TCP RST packets with specific payload. As shown in Section 4.4, the Henan Firewall injects a TCP RST packet with an unusual 10-byte payload 0102 03 04 05 06 07 08 09 00 . Its uniqueness allows the client drop only the RST packets injected by the Henan Firewall, while keeping the RST packets sent by the server. Typically, dropping TCP RST packets sent to the client is not enough to evade TCP RST censorship by the GFW, as the GFW also injects RST packets to the server. However, as explained in Section 4.4, the Henan Firewall only injects RST packets to the client, and thus dropping the RST packets sent to the client is sufficient to evade censorship. This circumvention strategy can be easily applied via iptables rules, similar to the ones introduced by Clayton et al. [6 §5].

Segment or fragment TLS ClientHello into multiple packets. As explained in Section 4.3, the Henan Firewall does not perform TCP reassembly, and neither the Henan Firewall nor the GFW performs TLS reassembly [65]. Thus, clients can segment TCP packets or fragment TLS ClientHello messages over multiple TLS records to evade the Henan firewall [65]. As long as the TCP packets carrying the beginning part of ClientHello messages does not contain a complete SNI extension, one can bypass the Henan Firewall. Performing this fragmentation may require TLS libraries such as uTLS [79] that provide fine-grained control over the messages sent, or purposely built circumvention tools like DPYProxy [77] that can fragment records made by a browser. Popular circumvention tools such as Xray [76] and Shadowrocket [78] have also implemented this TCP segmentation strategy [80].

7. Ethics

Censorship measurement studies, especially in authoritarian regimes, require careful ethical considerations and continuous evaluation of the potential risks involved throughout the entire research process. In this work, we conducted all of our censorship measurements from machines we controlled, with network traffic generated automatically by our programs. This approach is a common practice in censorship measurement studies to mitigate the risk of overwhelming other hosts on the Internet and imposing any risks on users [3, 4, 9, 14, 15]. When analyzing the real-world traffic on the university network tap, we only collected the TCP header length fields of the packets without capturing any human identifiable or sensitive information. Since IRB approval is thus not applicable for this study (as it does not involve human subjects), we followed the ethical guidelines outlined in the Menlo Report [81]. Our research team also consulted experts with a deep understanding of Chinese censorship and its legal concerns. Below, we discuss the potential risks we identified and the steps we took to mitigate them [81 §C.3.2].

Traffic analysis. To evaluate the effectiveness of the Henan Firewall, we measured the TCP header length fields of all TCP packets on the university network tap. The use of this network tap was approved by the university’s privacy and security office. We also worked closely with the campus networking and security teams who have experience managing similar projects. This approval and collaboration ensured that we followed standard security procedures, complied with network use policy, respected user privacy, and minimized the network’s attack surface. Additionally, we designed the tap to only receive a copy of traffic, ensuring no impact on network users in case of system failure.

We designed our experiment to avoid collecting any potentially sensitive information, such as IP addresses, which could be linked to individuals. Specifically, we only collected the 4-bit Data Offset fields from all TCP headers in an aggregated manner. We never inspected or logged any raw traffic data. We practiced the principle of least privilege by restricting access to the network tap to a limited, authorized subset of our team.

Vantage points. Obtaining vantage points within censored areas has become increasingly challenging. However, two key research questions we aim to answer require diverse vantage point coverage in China: 1) Is the Henan Firewall also deployed in other provinces in China? 2) Do other provinces deploy their regional censorship apparatus as well? We took extra care to find the right balance between finding as diverse vantage points as possible and the potential risks it carries [81 §C.3.2]. For example, while using residential vantage points would have allowed us to observe censorship in China from more network locations, we decided not to use them due to the potential risks to the uninformed users [61].

We also explored the possibility of measuring the Henan Firewall remotely from outside the province or China, which will further reduce the risks of initiating connections from within the region; however, as introduce in Section 4.2, the Henan Firewall could not be triggered that way.

We thus, following the rationale and common practices outlined in prior work [14, 15], strategically selected vantage points provided by large commercial cloud providers to mitigate potential legal risks for individuals. We registered our VPS accounts with the accurate identity and contact information of one of our researchers who is neither a citizen nor a resident of China. Throughout our research, we received no complaints from the providers. To avoid the possibility of getting other cloud users’ resources blocked by the censor, we assigned dedicated IP addresses to each of our machines.

Probing rate and design. To avoid overwhelming our vantage points and the network paths our probes traversed, we restricted the transmission speed directed to our sink servers. For experiments in Section 3 and Section 4, we limited the probing rate to no more than one connection per second; for experiments in Section 5, we set a hard limit on each client to send no more than 1 Mbps of traffic. While the risks and potential harms of our probes being logged by the censor is minimal, we also designed our experiments with plausible deniability in mind. That is, since our sink servers never replied with any ServerHello messages or HTTP responses, and no full TLS or HTTP connections were ever established, our measurement behaviors do not resemble users accessing censored websites.

8. Conclusion

In this paper, we expose and document an alarming sign in China’s Internet censorship strategy: our measurements from seven different cities and provinces in China reveal a new regional firewall in Henan province. This Henan Firewall conducts HTTP Host-based and TLS SNI-based censorship for traffic going out of the province. It exhibits distinct characteristics compared to the GFW, including unique packet injection behaviors and fingerprints, different logic in tracking, parsing, and blocking connections, a once ten-times larger and more dynamic blocklist, and closer network location to the client. This localized censorship suggests a departure from China’s centralized censorship apparatus, enabling local authorities to exert a greater degree of control within their respective regions. We propose simple but effective circumvention techniques to get around this emerging system in Henan, which have been implemented in various popular circumvention tools. We hope our study sounds the alarm to the broader censorship research community to be aware of and further study emerging regional censorship in China, and elsewhere.

Availability

To encourage future research and promote transparency and reproducibility, we have made the code, anonymized data, and constantly updated blocklists available. For improved accessibility, this paper is also available in HTML format in both English and Chinese. The project homepage is at: https://gfw.report/publications/sp25/en.

Acknowledgments

We thank our shepherd and other anonymous reviewers for their valuable comments and feedback. We also thank the brave users in China for immediately reporting and actively studying the blocking incidents, including, but not limited to, 5e2t, Hsukqi, ThEWiZaRd0fBsoD, louiesun, and lemon99ee. We are grateful to ValdikSS, radioactiveAHM, RPRX, Fangliding, GFW-knocker, sambali9, rrouzbeh, nekohasekai, znlihk, the V2Ray developers, the Hysteria developers, the Shadowrocket developers, and many other developers for their helpful discussions and/or for integrating TCP segmentation and/or TLS fragmentation features into their respective circumvention tools. We also thank Jackson Sippe, Jade Sheffey, Paul Flammarion, the Stanford Empirical Security Research Group, the Stanford University security and networking teams, and many others who prefer to remain anonymous for their helpful discussions and support. We thank Net4People BBS, NTC Party forum, Xray community, V2Ray community, and sing-box community for providing online space for censorship discussions. We are grateful to David Fifield for providing feedback, support, and guidance throughout the entire project.

The work was supported in part by the National Science Foundation (NSF) under grant numbers CNS-2145783, CNS-2319080, and CNS-2333965, by a Sloan Research Fellowship, and by the Young Faculty Award program of the Defense Advanced Research Projects Agency (DARPA) under the grant DARPA-RA-21-03-09-YFA9-FP-003. The views, opinions, and/or findings expressed are those of the authors and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.

References

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
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
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
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
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
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
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
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
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
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: https://github.com/net4people/bbs/issues/43#issuecomment-673322409
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
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
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
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
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
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
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
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
Anonymous, “Issue 2426 | XTLS/Xray-core,” https://github.com/XTLS/Xray-core/issues/2426, 2023, (Accessed on 02/06/2024).
G. Report. (2022, Oct.) Large scale blocking of TLS-based censorship circumvention tools in China. [Online]. Available: https://github.com/net4people/bbs/issues/129
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
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
B. Dong, “A report about national DNS spoofing in China on Sept. 28th,” Dynamic Internet Technology, Inc., Tech. Rep., Oct. 2002. [Online]. Available: https://web.archive.org/web/20021015121616/http://www.dit-inc.us/hj-09-02.html
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
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
Anonymous. (2020, Mar.) GFW archaeology: gfw-looking-glass.sh. [Online]. Available: https://github.com/net4people/bbs/issues/25
C. Tang, “In-depth analysis of the Great Firewall of China,” http://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf, 2016.
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
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
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
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/usenixsecurity17/sec17-pearce.pdf
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
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
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
GreatFire, “GreatFire Analyzer,” https://en.greatfire.org/analyzer, n.d., accessed: 2025-04-18.
GreatFire, “Blocky,” https://blocky.greatfire.org/, accessed: 2025-04-18.
Anonymous and Amonymous. (2022, Oct.) Sharing a modified Shadowsocks as well as our thoughts on the cat-and-mouse game. [Online]. Available: https://github.com/net4people/bbs/issues/136
P. Winter. (2013, Mar.) GFW actively probes obfs2bridges. [Online]. Available: https://bugs.torproject.org/8591
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
T. Wilde. (2012) Knock knock knockin’ on bridges’ doors. [Online]. Available: https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors
Anonymous, Anonymous, Anonymous, D. Fifield, and A. Houmansadr. (2021, Jan.) A practical guide to defend against the GFW’s latest active probing. [Online]. Available: https://github.com/net4people/bbs/issues/58
Anonymous. (2021, Jan.) How to Deploy a Censorship Resistant Shadowsocks-libev Server. [Online]. Available: https://gfw.report/blog/ss_tutorial/en/
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
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
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
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
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
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
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/usenixsecurity18/sec18-liu_0.pdf
Net4People, “Net4People BBS Issues.” [Online]. Available: https://github.com/net4people/bbs/issues
NTC Community, “NTC Party: “No Thought is a Crime” — Internet Censorship Circumvention Forum.” [Online]. Available: https://ntc.party/
XTLS, “Xray-core Project Issue Tracker.” [Online]. Available: https://github.com/XTLS/Xray-core/issues
V2Fly, “V2Ray Core Project Issue Tracker.” [Online]. Available: https://github.com/v2fly/v2ray-core/issues
SagerNet, “sing-box Project Issue Tracker.” [Online]. Available: https://github.com/SagerNet/sing-box/issues
Hysteria, “Hysteria Proxy Project Issue Tracker.” [Online]. Available: https://github.com/apernet/hysteria/issues
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).
——, “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).
ghost, ““河南新上的 SNI/HOST 黑名单墙” (GitHub Discussion #3601),” https://github.com/XTLS/Xray-core/discussions/3601#discussioncomment-10293992, Aug 2024, (Accessed on April 18, 2025).
H. Lee, “启用 TCP Timestamps 解决 SNI 阻断,” https://blog.tsinbei.com/archives/1361/, Sep 2023, (Accessed on April 18, 2025).
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.
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
“IP2Location LITE IP address geolocation database.” [Online]. Available: https://www.ip2location.com/database/ip2location
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
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).
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
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
K. 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
klzgrad, “GFW技术报告：入侵防御系统的评测和问题,” https://www.chinagfw.org/2009/09/gfw_21.html, Aug 2009, accessed: 2025-04-11.
gfwrev, “HTTP URL/深度关键词检测,” https://gfwrev.blogspot.com/2010/03/http-url.html, Mar 2010, accessed: 2025-04-07.
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
W. Eddy, “Transmission Control Protocol (TCP),” RFC 9293, Aug. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9293
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
“Centralized Zone Data Service,” https://czds.icann.org/home, (Accessed on 01/31/2024).
“Website categorization api | domain category check | whoisxml api,” https://website-categorization.whoisxmlapi.com/api, (Accessed on 04/25/2024).
“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).
XRay developers. XRay. [Online]. Available: https://github.com/XTLS/Xray-core
GoodbyeDPI developers. GoodbyeDPI. [Online]. Available: https://github.com/ValdikSS/GoodbyeDPI
ShadowRocket developers. ShadowRocket. [Online]. Available: https://apps.apple.com/us/app/shadowrocket/id932747118
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
XRay developers. XRay pull request. [Online]. Available: https://github.com/XTLS/Xray-core/pull/3660
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

Appendix A. Meta-Review

The following meta-review was prepared by the program committee for the 2025 IEEE Symposium on Security and Privacy (S&P) as part of the review process as detailed in the call for papers.

A.1. Summary

This paper empirically confirms anecdotal evidence that the Henan province in China had started to deploy regional censorship mechanisms, purposely more stringent than those employed by the great firewall itself. The paper delivers a comprehensive analysis of censorship carried out by the Henan Firewall, both on in/out and out/in directions, shedding light on its functioning, blocking policies, and residual censorship mechanisms. In addition, the paper inspects whether similar regional censorship is occurring in other Chinese provinces, finding no evidence of additional interference beyond that of the great firewall.

A.2. Scientific Contributions

Independent Confirmation of Important Results with Limited Prior Research
Provides a Valuable Step Forward in an Established Field

A.3. Reasons for Acceptance

1): This paper provides an independent confirmation of important results with limited prior research. The paper builds a measurement apparatus to confirm (and expand on the information provided by) anecdotal reports of regional censorship within the Henan province in China. Besides providing a systematic understanding of the existence and blocking behavior of this new type of regional censorship, the paper also independently confirms the asymmetry in blocking behavior of the great firewall.
2): The paper provides a valuable step forward in an established field by applying different known methodologies to exhaustively study a new phenomenon of censorship in a part of China. The measurements carried out in the presented study are sound and rely on true-and-tested measurement methodologies, providing insights into a form of censorship that had not been further analyzed.

墙中之墙：中国地区性审查的兴起

Sun, 11 May 2025 00:00:00 +0000

墙中之墙：中国地区性审查的兴起

Mingshi Wu^∗

GFW Report

gfw.report@protonmail.com

Ali Zohaib^∗

University of Massachusetts Amherst

azohaib@umass.edu

Zakir Durumeric

Stanford University

zakir@cs.stanford.edu

Amir Houmansadr

University of Massachusetts Amherst

amir@cs.umass.edu

Eric Wustrow

University of Colorado Boulder

ewust@colorado.edu

^* Mingshi Wu 和 Ali Zohaib 对这项工作贡献相当。

摘要

长期以来，中国的互联网审查有着相对集中的政策和统一的实现，这套系统被称为中国防火长城（GFW）。然而，自2023年8月以来，有传闻称河南省部署了自己的地区性审查系统。在这项工作中，我们对河南省的省级审查进行描述和分析，并将其与国家级的GFW进行了比较。我们发现，河南建立了基于TLS SNI和HTTP Host的审查机制，用于检测和封锁离开该省的流量。虽然河南防火墙在复杂性和应对网络流量多样性方面有所欠缺，但其不稳定且激进的二级域名封锁策略，一度使其封锁的网站数量达到GFW的十倍之多。我们基于对河南防火墙的流量解析缺陷和注入行为的观察，提出了一些简单的仅需客户端实现的办法来绕过河南省的审查。我们的工作记录了一种值得警惕的现象，即中国的地区性审查正在抬头。

1. 引言

中华人民共和国开发并维护着世界上最复杂的互联网审查系统之一，通常被称作中国防火长城（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节）：中国的其他省份是否也部署了相同或类似的地区性审查？我们在中国的七个省市进行了测量研究，包括北京、上海、广东、浙江、江苏、四川和河南，以识别潜在的地区性审查。可能由于我们在中国所能使用的测量点有限，我们没有在除河南以外的六个省份发现地区性审查的证据。

¹ 项目主页： https://gfw.report/publications/sp25/en。

随后，我们分析了河南省新兴的地区性审查，将其封锁策略和实现与国家级GFW进行了比较。如图1所示，我们的调查显示，河南的省级中间设备通过基于HTTP Host和基于TLS服务器名称指示（SNI）的过滤来封锁对特定HTTP和HTTPS网站的访问（第4.1节）。与监控并封锁进出境流量的GFW不同，这个地区性防火墙仅审查离开该省的流量（第4.2节）。它在连接追踪和解析逻辑（第4.3节）、注入行为和指纹（第4.4节）以及网络位置（第4.5节）方面也不同于GFW。

图1：河南省部署了基于TLS SNI和HTTP Host的审查中间设备，用于检测和封锁离开该省的流量。

我们进行了一项长期研究，以了解河南防火墙所封锁的内容及其与 GFW 所封锁内容的差异（第5节）。在 2023 年 11 月至 2025 年 3 月期间（2024 年 3 月至 10 月之间没有测量），我们每天测试 Tranco 排名前一百万的域名，并每周测试 CZDS 的 2.27 亿个域名。我们发现河南防火墙采用了比 GFW 更激进且不稳定的封锁策略。河南防火墙累计封锁了 420 万个域名，是 GFW 累计封锁列表规模的五倍多。造成这种情况的一个关键原因是其封锁了许多通用二级域名（如 *.com.au）。我们的测试还揭示，在一些时期，其封锁的域名数量是 GFW 的十倍之多。

基于观察到的解析缺陷和注入行为，我们介绍规避技术来绕过这种地区性审查（第6节），这些技术已被许多流行的反审查工具使用。河南的地区性审查标志着中国首个被正式记录的省级自主运作防火墙案例。我们希望这项研究能向更广泛的审查研究社区发出警报，以识别、调查和应对中国及其他地区出现的地区性审查。

2. 背景与相关工作

2.1. 中国防火长城 (GFW)

中国防火长城 (GFW) 是部署在中国的一系列不同的审查设备和机制。GFW利用部署在中国边界自治系统 (AS) 的网络中间设备来检测和封锁互联网流量 [17]。GFW 不仅封锁特定网站和网络服务，而且试图识别和封锁翻墙行为。

网站审查。为了封锁对特定网站和服务的访问，GFW 通常同时使用多种技术手段，包括 DNS 污染 [1, 3]、基于 HTTP Host 的过滤 [8]、基于 TLS SNI/ESNI 的过滤 [2, 9, 10, 20] 以及 IP 地址封锁 [2 §4]。

为了审查 DNS 流量，GFW设备并联（旁路分光部署）于网络，注入带有错误 IP 地址的伪造 DNS 响应，以阻止对特定域名的访问 [3, 4, 5, 21, 22]。2002 年的早期报告记录了 GFW 在其伪造响应中使用单一错误 IP 地址 [23, 24]。随着时间的推移，其演变成了一个更复杂的系统，使用了越来越多的虚假地址，并扩大了其域名封锁列表 [3, 4, 22, 25]。研究人员还发现过 GFW DNS注入系统中的内存数据泄露漏洞 [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 的连接的审查。

图2：河南防火墙和三种不同类型 GFW 的概述。我们在数据包的 SNI 或 HTTP Host 字段中使用仅被某一种墙审查的域名，以单独触发和研究每种墙的审查机制。例如，在 2024 年 4 月，011.com 仅被河南防火墙封锁，而 youtube.com 仅被 GFW 封锁。

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)，它向 HTTP 流量中注入 Javascript，以利用受害者的浏览器发动对特定主机的拒绝服务攻击 [30]。

2.2. 审查的地区性差异

在审查政策严格的国家，本地化或分散化的审查机制很常见。在俄罗斯，数千家私营互联网服务提供商 (ISP) 各自实施自己的过滤机制，导致审查环境多样化 [45, 46, 47]。类似地，在印度，研究人员表明 ISP 在执行政府审查令方面存在显著差异，导致全国范围内的审查碎片化 [48]。

然而，先前的研究表明，中国的审查系统和政策在全国范围内基本是统一和集中化的。2011 年，Xu 等人 [17] 测量了中国审查设备的位置。他们发现，中国的关键词审查中间设备主要位于网络边缘，并采用符合当时全国性封锁策略的规则。2012 年，Wright [18] 对中国的 DNS 审查进行了一项小规模研究，发现DNS 响应在全国各地有所不同。然而，这项工作没有考虑 DNS 响应变化的其他可能原因（例如基于地理位置的负载均衡，或 DNS 配置的变化）。2018 年，Bao 等人 [49] 从住宅和移动 IP 地址测量了中国的 DNS 投毒差异。全网地持续性测量揭示了中国在审查策略 [4, 3, 15, 9]、审查软件更新 [16 §4.5] [5 §VII] 和审查基础设施 [14 §3.4] [4 §5] 方面，进行了统一的协调和管理。

3. 检测地区性审查

中国境外的反审查研究人员通常依赖境内用户的报告来了解中国审查策略的新变化和升级。部分原因是研究人员难以在中国境内获得多样化的测量服务器，并持续监测各种互联网服务和协议的可访问情况。令人鼓舞的是，在线论坛——例如 Net4People BBS [50]、NTC Party 论坛 [51]，以及 Xray [52]、V2Ray [53]、sing-box [54] 和 Hysteria [55] 等流行反审查工具的 GitHub 问题汇报页面——为用户在遇到新的审查事件时立即报告遭遇提供了平台。这也使得研究人员能够迅速调查这些报告 [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节中的一系列伦理考量。

表1：实验时间线和测量点。我们总共使用了位于河南省郑州市的China VPS（CVC, AS4837）的14台虚拟主机，位于旧金山（SF）、新加坡（SG）和西雅图（SE）的Akamai Linode（LD, AS63949）的6台虚拟主机，位于北京（BJ）、上海（SH）、重庆（CQ）、广东省广州市（GZ）、四川省成都市（CD）、江苏省南京市（NJ）的腾讯云（TC, AS45090）的12台虚拟主机，以及一台位于美国某大学的裸金属网络流量捕获服务器（TAP）。

实验名称	实验时间	实验时长		中国测量点	境外测量点	章节
识别	24年7月10日	1	天	12 (TC), 2 (CVC: HN)	4 (LD: SG,SE)	§3
特征分析	23年10月2日 – 24年11月12日	13	个月	2 (CVC: HN)	1 (LD: SF), 3 (TC: GZ,BJ,SH)	§4
流量分析	24年10月31日	1	小时	–	1 (TAP: US)	§4.3
定位	23年10月2日 – 23年12月8日	2	个月	1 (CVC: HN), 1 (TC: GZ)	1 (LD: SF)	§4.5
封锁列表	23年11月5日 – 24年3月5日 & 24年10月7日 – 25年3月31日	9	个月	14 (CVC: HN), 2 (TC: GZ)	2 (LD: SF)	§5

对于中国境内或境外的每个地点的两个虚拟主机（VPS），我们把其中一个作为客户端，把另一个作为水槽服务器。水槽服务器被配置为接受端口 1 到 65535 上的 TCP 握手。它们会发送ACK来确认发送给它们的 TCP 数据，但绝不会向客户端发回任何 TCP 载荷。我们在客户端和水槽服务器上都配置了 iptables 规则来丢弃任何传出的 RST 数据包。这样，任何一端收到的 RST 数据包都一定是由网络路径上的某些中间设备注入的伪造包。因此，我们可以通过检查 TCP 连接是否被重置来确认审查的存在。

我们在 2024 年 7 月 10 日，在每对客户端和水槽服务器之间发送了包含各种不同 SNI 值的 TLS 流量。具体来说，我们使用了 Tranco 列表 [60] 5YZ7N 中排名前 10,000 的域名进行测试。² 为了减少因丢包导致的假阴性概率，我们在同一天重复测试了三次，并在每次测试中，让操作系统控制数据包的重传。

² Tranco 列表 ID 5YZ7N，获取于 2023 年 8 月 15 日： https://tranco-list.eu/list/5YZ7N/1000000。

局限性。理想情况下，我们希望使用多样化的测量点来识别中国潜在的地区性审查。然而，由于获取中国的VPS很困难，我们只能在有限数量的地点和自治系统（AS）中获取测量点。虽然使用住宅测量点可以让我们从中国更多的网络位置观察到潜在的审查中间设备，但这可能会给不知情的用户和住宅代理提供商带来潜在风险[61]。出于这个原因，我们专注于使用中国的两家大型 VPS 提供商——China VPS和腾讯云，以避免给个人带来风险或迫害。我们利用了这两家 VPS 提供商提供的所有可用地点，以最大化我们的覆盖范围。我们承认我们的结果仅限于测量 TLS 审查，这可能会遗漏针对其他协议的地区性审查。此外，由于配置错误，我们没能使用新加坡的客户端进行测试，因此错过了从该视角进行的审查测量。

3.2. 结果

图3 显示了不同地区之间被封锁域名的数量。我们首先观察到，从中国发往我们位于新加坡和美国的水槽服务器的连接，受到国家级中国防火长城（GFW）的影响几乎相同，在大约 10,000 个域名中约有 479 个被封锁。最显著的封锁发生在河南省，省级（河南防火墙）和国家级（GFW）审查机制共同拦截，导致了较高的封锁数量。

图3：该矩阵显示了在不同区域的每对主机之间被封锁的域名数量。对于每对主机，我们发送了包含 Tranco 列表 [60] 5YZ7N（生成于 2023 年 8 月 15 日）中排名前 10,000 个域名的 SNI 值的 TLS ClientHello 消息。结果表明：1）河南省存在地区性审查，证据是从河南郑州向中国其他地区的水槽服务器发起连接时，被封锁域名的数量不为零；2）河南的审查不是双向的，因为从外部向河南发起 TLS 连接并未触发任何封锁；3）GFW 维护着一个仅在中国境内访问时才会被审查的封锁列表，证据是由内向外和由外向内测试时被封锁域名数量有差异。

离开河南的流量受到地区性防火墙的审查，无论水槽服务器的位置如何，即使是发往中国境内其他地区的连接也会受到审查。平均而言，有 122 个域名被河南防火墙封锁。我们没有观察到在河南省内交换的 TLS 连接被封锁；然而，由于我们的客户端和水槽服务器都位于同一个数据中心，我们只能谨慎地得出结论，即河南防火墙不影响该数据中心内部的流量。

当从河南省郑州连接到中国境外地点（新加坡和西雅图）时，总共有 594 个域名被封锁。这表明两个具有独立封锁列表的防火墙在同时运作，河南防火墙在流量到达 GFW 之前对其进行审查，从而增加了被封锁域名的总数。然而，我们没有观察到从中国其他区域连接到河南或中国境内其他水槽服务器区域时存在任何封锁。这一发现表明，河南防火墙是中国已知的第一个部署地区性防火墙的案例。

此外，如图3最后一行所示，从美国到中国不同地点的测试一致地识别出相同的 411 个被 GFW 封锁的域名，只有一个例外：从美国到江苏省的测试检测到 440 个被封锁的域名。进一步分析表明，在江苏省由外向内方向额外被封锁的 29 个域名是 GFW 在由内向外方向封锁的 479 个域名的一个子集。这一发现表明，这 29 个域名的额外审查很可能并不反映江苏省特有的地区性审查。相反，它表明江苏省内的 GFW 被配置为对这29个域名进行双向封锁。

这些结果尤其值得注意，因为它们显示了远程测量无法触发地区性防火墙，更重要的是，揭示了 GFW 的不对称行为。虽然从中国境内发起的连接平均有 479 个域名被封锁，但从中国境外发起的连接只有 411 个域名被封锁。这种差异表明 GFW 对源自中国境内的流量执行不同的封锁列表。直到最近，人们仍普遍认为 GFW 是对称运作的，无论流量方向如何，都会触发相同的封锁列表。然而，最近的研究表明这种假设是不正确的 [9]，我们在此的发现与其观测结果一致。

我们注意到 GFW 和河南防火墙都在不同程度上表现出不对称的封锁。如图4(a)所示，虽然离开河南的流量受到地区性防火墙（由内向外）的影响，但进入河南的入站流量（由外向内）完全不会触发地区性防火墙。这与 GFW 形成对比，GFW 是双向的（但其行为根据查询的域名而表现出不对称性）。

图4(b) 提供了一个清晰的例子来说明这种行为。在我们的案例中，当一个 SNI 值为 docker.com 的 TLS ClientHello 从中国境内发送时（由内向外），GFW 会通过三个 TCP RST 数据包触发封锁。然而，当相同的 TLS ClientHello 从中国境外发送时（由外向内），GFW 不会触发任何封锁。另一方面，当发送带有 SNI 值 youtube.com 的 TLS ClientHello 数据包时（在此示例中），无论数据包是从中国境内还是境外发送，GFW 都会在两种情况下触发封锁。这种行为表明存在一个明显的域名封锁列表，这些域名仅在从中国境内访问时才会被 GFW 审查。

(a) 河南防火墙

(b) GFW

图4: (a) 河南防火墙不审查进入河南的入站 TLS 或 HTTP 流量，这与 GFW 采用的双向审查形成对比。 (b) GFW 的 TLS 和 HTTP 审查机器检查进出中国的双向流量；然而，某些域名仅在从中国境内访问时才被审查。在此示例中，虽然从中国境内发送带有 SNI 值 docker.com 的 TLS ClientHello 可以触发 GFW 发送三个 TCP RST 数据包，但从中国境外发送时则不会触发任何封锁。

在我们检测地区性审查的实验中，我们无意中发现了 GFW 运作机制的一个重要方面，而这直到最近才被记录下来 [9]。新观察到的 GFW 和地区性防火墙共有的不对称性，表明审查测量需要由内向外的测量，以全面捕捉审查的范围和细微差别。仅仅依赖由外向内的远程测量，正如其他许多研究中常见的那样，则无法提供此类审查机制的全面情况。

为了进一步证实 GFW 的不对称行为，我们提供了一个域名列表，这些域名仅在从中国境内发送 TLS ClientHello 消息时被封锁，如表2所示。在我们的实验中，10,000 个域名中有 68 个在从中国境外测试时未触发任何审查，仅在从中国境内探测时才被封锁。这些域名包括流行的网站，如 google.com、nyt.com 和 docker.com。该列表提供了具体的证据，证明 GFW 根据流量来源和相关域名选择性地执行其封锁列表。

表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

4. 审查设备特征分析

自 2023 年 10 月以来，我们进行了一系列实验来分析审查设备的特征，并理解中国防火长城（GFW）与河南地区性审查设备之间的差异。在本节中，我们将回答几个研究问题：地区性审查设备位于何处？哪些数据包可以触发河南 SNI 防火墙？河南防火墙监控哪些端口？注入的TCP RST 包是否具有特定的指纹？河南防火墙是否会引发残余审查？

4.1. 方法

如前所述，我们针对地区性和国家级两种防火墙的具体特征制定了一套测量方法。为了精确评估每种防火墙的影响，我们的方法单独隔离并分析这两个系统。这种基于我们初步观察设计的测量方法，是我们进行全面测量实验的基础。我们的测量方法概述如下。

获取测量点。我们总共在中国郑州（河南）通过China VPS（AS 4837）获取了 10 个测量点，在广州、北京和上海通过腾讯云（AS 45090）获取了两台 VPS，以及在美国旧金山通过 Akamai 的 Linode（AS 63949）获取了两台 VPS。位于广州、北京、上海和旧金山的 VPS 作为水槽服务器，被设置为监听在从 1 到 65535 的所有端口以接受 TCP 连接，但不向发送方发回任何TCP载荷数据。我们所有的机器都运行 Ubuntu 22.04，并使用 IP2Location [62] 数据库验证了它们宣称的位置。我们在表1中总结了我们实验的时间线和每个实验使用的测量点。

在 VPS 上丢弃传出的 RST 数据包。我们在客户端和水槽服务器上都配置了 iptables 规则来丢弃所有传出的 RST 数据包。这种配置确保客户端收到的任何 RST 数据包都一定是由中间设备伪造的。

触发基于 TLS SNI 的审查。我们通过发送在 SNI 字段中包含可能被审查域名的 TLS ClientHello 来触发审查。由于水槽服务器被配置为不发送任何带有载荷的数据包，并且在观察到 FIN 或 RST 数据包之前不切断连接，我们预期收到的任何 RST 数据包都一定是防火墙注入的伪造包。如果包含该域名的 TLS 连接收到了 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 在观察到包含禁止的SNI的 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 的审查情况。

4.2. 河南防火墙针对哪些流量

河南防火墙是否对流量进行抽样监控和审查？据观察，一些审查者有时仅监控和审查一部分流量，这可能是为了减少其审查设备的计算负载 [15 §6.3]。然而，我们没有观察到河南防火墙有任何流量采样或概率性封锁行为。我们观察到河南防火墙持续封锁其封锁列表上的域名。我们连续发送了 1,000 个包含被禁止域名的 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中总结了我们的发现。

表3：GFW 和河南防火墙的流量解析逻辑。河南防火墙似乎是无状态的，并且在应对不同网络流量时不如 GFW 健壮。

	GFW	河南防火墙
需要看到 SYN	✓	✗
需要看到 SYN+ACK	✗	✗
支持TCP重组	✓	✗
支持TLS重组	✗	✗
TCP 头部长度要求	任意	仅 20 字节

TCP 握手完整性要求。网络中间设备的设计者通常需要在流量解析逻辑的健壮性和效率之间进行权衡。例如，由于互联网的非对称路由特性，以及河南防火墙和 GFW 并非总是客户端或服务器的直接邻居（如表5所示），网络中间设备可能只能观察到单向的流量。这种特性常常使得中间设备的设计者放弃使用完整的 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 载荷分割成较小的载荷。在规避审查的背景下，将 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 重组，因此可以通过将 TLS ClientHello 消息分片到多个 TLS 记录中（其中 SNI 被分割到同一 TCP 载荷内的多个 TLS 分片中）来绕过它。我们确认，截至 2024 年 4 月 4 日，河南防火墙和 GFW 都不执行 TLS 重组，因此可以通过 TLS ClientHello 分片来绕过它们。

TCP 头部长度必须为 20 字节。 TCP 头部的第 13 个字节的前四个有效位表示 TCP 数据偏移量，它指定了 TCP 头部的长度（以 32 位字为单位）。当没有 TCP 选项存在时，TCP 数据偏移字段的最小值为 5 个字（20 字节），最大值为 15 个字（60 字节）。

我们发现河南防火墙要求 TCP 头部长度必须正好是 20 字节才能正确解析和封锁 TLS ClientHello 或 HTTP 请求消息。我们在 2024 年 10 月 17 日，通过从河南的测量点向广州的水槽服务器发送包含被禁止消息（例如，带有被禁止 SNI 011.com 的 TLS ClientHello 消息）并设置不同的 TCP 选项来进行测试。在改变 TCP 头部长度的同时，我们确保 TCP 选项始终是四字节的倍数，以符合 TCP 头部的 32 位字对齐要求。我们测试的 TCP 选项包括常见的选项，如最大分段大小（MSS）、窗口缩放、时间戳、选择性确认许可（SAckOk）、无操作（NOP）、选项列表结束（EOL），以及不常用的自定义 TCP 选项。我们发现，只要设置了任何 TCP 选项，河南防火墙就不会封锁连接。

一个自然提出的假设是，河南防火墙不解析 TCP 头部中的 TCP 头部长度字段，并错误地假设 TCP 头部长度始终为 20 字节。这样，当 TCP 头部因 TCP 选项而超过 20 字节时，它会将 TCP 选项视为 TCP 载荷的一部分，从而无法识别完整的 TLS ClientHello 或 HTTP 请求消息。然而，我们证伪了这一假设，并确认河南防火墙确实解析了 TCP 头部长度字段。具体来说，我们首先发送了带有被禁止 SNI 011.com 且 TCP 头部未设置任何 TCP 选项的 TLS ClientHello 消息，并确认该消息被河南防火墙封锁。如果河南防火墙不解析 TCP 头部长度字段，那么无论我们在 TCP 头部中放入什么 TCP 头部长度值，该消息都应该被封锁。我们将 TCP 头部中的 4 位 TCP 头部长度字段更改为所有 2⁴ 种可能的值（从 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% 的目标连接。

图5：2024 年 10 月 31 日在一所大学网络上捕获的一小时内所有 TCP 和 TLS 数据包的 TCP 头部长度字段分布。总共捕获了约 231 亿个 TCP 数据包和 50 亿个 TLS 数据包。只有 22% 的 TCP 数据包头部长度为 20 字节，而只有 19% 的 TLS 数据包头部长度为 20 字节。这一评估结果表明，河南防火墙可能只能审查大约 20% 的目标连接。

4.4. 河南防火墙如何封锁流量

河南防火墙是否采用残余审查？残余审查是审查者经常使用的一种手段，即在检测并打断两台主机之间的通讯后，在一定时间内（通常是 90 秒或 180 秒）继续封锁这两个主机（源IP、目的IP、目的端口 - 三元组）之间的所有后续连接。这种现象已被多项研究 GFW 的先前工作记录在案 [6, 8, 67]。我们发现河南防火墙不执行任何残余审查。在河南防火墙进行任何重置注入后，我们仍然能够使用相同的三元组建立连接。

注入行为指纹分析。延续前人对 GFW 不断演变的注入行为进行指纹分析的工作 [7 §2.1, 65 §3.1, 68, 69, 70 §7.1.6]，我们对 GFW 和河南防火墙注入的 TCP RST 数据包进行了指纹分析。利用第4.5节中收集的 RST 数据包，我们分析了它们的数据包特征，例如 IP 标识符（IP ID）、IP 生存时间（IP TTL）、TCP 标志、TCP 载荷和载荷长度。

表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 载荷	-	-	-	0102 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 标志，我们观察到河南防火墙发送单个 RST+ACK 数据包，且 IP DF（不分片）标志未设置。在 GFW 注入器中，类型 I 发送单个不带 ACK 的 RST 数据包，且 IP DF 标志未设置；类型 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 注入三个 IP ID 值范围从 0x00A3 到 0xFE5F（163–65119）的 RST+ACK 数据包，类型 III GFW 注入 IP ID 值范围从 0x9916 到 0x9933（39190–39219）的 RST+ACK 数据包。另一方面，河南防火墙的 TCP RST 数据包具有固定的 IP ID 值 0x0001。

河南防火墙 RST 数据包最独特的指纹是其 10 字节的 TCP 载荷模式 0102 03 04 05 06 07 08 09 00 ，这在任何 GFW 注入器中都未发现。虽然 RFC 9293 规定 “TCP 实现应允许接收到的 RST 段包含数据（SHLD-2）”[71 §3.5.3]，但在现实世界中看到带有载荷的 RST 数据包仍然非常罕见。在第6节中，我们介绍了一种利用这种独特指纹来绕过河南防火墙的翻墙技术。

4.5. 审查设备部署在何处

为了找出河南防火墙设备在网络中的位置，我们测量审查设备距离我们河南客户端的网络延迟和 TTL 跳数距离。

首先，我们从位于河南省郑州的测量点独立地向位于广州和旧金山的水槽服务器发送 ClientHello 数据包，并测量了我们的客户端从发送 ClientHello 到接收到 RST包之间的时间差。我们利用了 Tranco 列表中的前一百万个域名，每天进行四次实验，并捕获收到的 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 毫秒）。这一证据有力表明，河南的地区性审查是独立于GFW部署的，并且更接近我们的测量点，这意味着这些审查设备位于河南省境内。

图6：发送包含被禁止域名的 TLS ClientHello 数据包与接收到审查设备发出的第一个伪造 TCP RST 数据包之间时间差的累积分布。

接着，为了确定审查发生的确切网络跳数，我们使用了基于 traceroute 的 TTL 操纵探测方法。具体来说，我们发送包含已知被审查域名的 TLS ClientHello 数据包，逐渐增加探测包的 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 跳（中国联通骨干网）。这些结果证实了两个审查实体都作为中间设备运行，其中河南设备距离客户端更近。

5. 理解封锁列表

我们持续监测并分析了被河南防火墙和 GFW 封锁的网站。我们还推断了其采用的封锁规则。

5.1. 分析被封锁的域名

实验设置。由于很难在河南获取高带宽机器，我们将测量分为两部分。首先，我们每天测试 Tranco 列表 5YZ7N 中排名前一百万的网站。其次，我们每周测试2.27 亿个域名，它们是从互联网名称与数字地址分配机构（ICANN）的集中区域数据服务（CZDS）提供的超过 1,000 个顶级域名（TLD）的域文件中提取的 [73]。

对于 Tranco 前一百万域名的每日测试，我们通过向我们控制的位于中国的服务器发送相应的连接，来测试基于 TLS SNI 和 HTTP Host 的封锁。对于每个域名，针对基于 TLS SNI 的审查，我们每天发送四个连接；针对基于 HTTP Host 的审查，我们每天发送两个连接。在一天之中，如果某一测试中被测域名收到了 TCP RST 响应，我们就将该域名标记为在该协议下被封锁。

由于带宽限制，对于每周测试的 2.27 亿个域名，我们为每个域名向我们的服务器发送一个 TLS 连接，如果请求收到 TCP RST，则将该域名标记为被封锁。

实验时间线。表1 总结了具体的实验时间线和测量点使用情况。需要特别指出的是，我们在 2024 年 3 月 5 日至 10 月 7 日期间未能运行监测实验。此外，我们在广州的 VPS 出现的意外中断，也导致了一些较小的数据缺口。这些缺口在图7中也有所体现。由于我们使用相同的机器来测量河南防火墙和 GFW，广州水槽服务器的中断同时影响了我们对两个防火墙的测量。因此，我们将这些小的测量缺口（总计额外 25 天）从分析中移除。

图7：河南防火墙和 GFW 封锁的域名数量随时间变化关系。我们在 2023 年 11 月 5 日至 2025 年 3 月 31 日期间，使用 Tranco 前一百万域名列表 ID 5YZ7N 进行了测试，其中 2024 年 3 月 5 日至 10 月 7 日没能测试。

河南防火墙对基于 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 显示，在 2023 年 11 月 10 日至 12 月 8 日期间，河南防火墙封锁的域名数量持续大幅下降。这一下降主要是由于至少 112 条通用二级域名封锁规则被移除。特别是，在2023 年 11 月 22 日移除 *.com.au 这一条封锁规则，就解封了超过五千个域名。

我们观察到河南防火墙使用的封锁列表也针对与其他国家相关的州或市政府网站。例如，美国的大多数州政府网站，如 texas.gov、seattle.gov、alabama.gov、nc.gov 都在河南被封锁，但未被 GFW 封锁。与 GFW 封锁列表中出现的 83 个 *.gov* 域名相比，我们发现河南防火墙封锁了 1,002 个 *.gov* 域名，这表明其倾向于封锁任何展示来自世界各地的治理数据或新闻内容。事实上，如表6所示，我们注意到河南防火墙比 GFW 更倾向于针对国家代码顶级域名（ccTLD）。其中一些封锁范围很广：2024 年，河南在 1月19日，和2月1日至2月2日封锁了我们测试的所有 5,334 个 *.com.au 域名，在 2 月 15 日至 3 月 4 日封锁了所有 2,075 个 *.co.za 域名，在 2 月 8 日至 3 月 4 日封锁了所有 1,547 个 *.org.uk 域名。这些可能是过度封锁的实际例子，即防火墙包含过于宽泛的规则。我们不清楚河南防火墙为何会重复封锁和解封这些国家代码二级域名。

表6：GFW 和河南防火墙在三个月内审查的前十大顶级域名（TLD）。河南防火墙封锁的国家代码顶级域名（ccTLD）多于 GFW。

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%

河南防火墙的封锁列表比 GFW 更不稳定。如图8所示，河南防火墙的封锁列表比 GFW 的封锁列表更不稳定。75% 被封锁的域名被河南防火墙审查的时间少于 51 天，而超过 50% 曾被 GFW 审查的域名在整个测量期间（256 天）都被封锁。与河南防火墙封锁的域名（平均：35.7 天；中位数：21 天）相比，被 GFW 封锁的域名审查持续时间更长（平均：173.8 天；中位数：256 天）。

图8：2023 年 11 月 5 日至 2025 年 3 月 31 日期间（其中 2024 年 3 月 5 日至 10 月 7 日没有测量），所有曾被 GFW 和河南防火墙审查的域名的被封锁时长累积分布。与 GFW 相比，河南防火墙的封锁策略更不稳定，更大比例的域名被封锁的时间较短。

如上所述，河南防火墙这种不稳定的封锁策略也主要是由于频繁添加和删除通用二级域名封锁规则所致。例如，图7 显示，在 2024 年 1 月 11 日至 1 月 12 日以及 2 月 1 日至 2 月 3 日期间，河南防火墙封锁的域名数量出现了两次峰值。这主要是由于添加和删除了 *.com.au 封锁规则。值得注意的是，即使在 *.com.au 规则被移除后，例如在 2024 年 1 月 12 日和 2 月 3 日，河南防火墙仍然分别封锁了 44 个和 26 个以 .com.au 结尾的域名。这一观察结果表明，封锁规则的粒度可以比二级域名更细。

两个防火墙是否针对相似的网站？图9 显示了在我们九个月的测量期间，GFW 和河南地区性审查设备在 Tranco 前一百万域名中封锁的域名的累积分布。

图9：GFW 和河南防火墙在 Tranco 前一百万列表 5YZ7N 中封锁的域名的累积分布。数据收集于 2023 年 11 月 5 日至 2025 年 3 月 31 日，其中 2024 年 3 月 5 日至 10 月 7 日没有测量。

对于 GFW，如果一个域名在我们的测量期间至少被封锁过一次，我们就将其归类为被封锁。由于河南防火墙封锁列表的不稳定性，我们将域名分为三类：曾被封锁的域名、被封锁时间少于 21 天的域名以及被封锁时间少于 51 天的域名。我们根据对两个防火墙平均封锁持续时间的观察（如图8 所示）选择了这些阈值。

在测量期间，我们累计观察到 25,441 个域名被 GFW 审查，而有 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%，因此在覆盖范围上很大程度上是独立的，但又互为补充。

图10：GFW 和河南防火墙曾封锁的累积域名的维恩图。我们在 2023 年 12 月 26 日至 2025 年 3 月 31 日期间（其中 2024 年 3 月 5 日至 10 月 7 日没有测量）每周测试 2.27 亿个域名。河南封锁列表的大小是 GFW 封锁列表的五倍多。

对被封锁域名进行分类。我们使用了 whoisxmlapi.com [74] 网站分类服务，对 2023 年 11 月 21 日至 2024 年 1 月 15 日期间获取的每个防火墙的封锁列表进行了分类。我们承认并非所有域名都能被分类，因为有些域名不活跃或不托管内容。表7 显示了每个防火墙审查域名的前十个类别。

表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 更倾向于针对商业、经济、计算机和互联网信息领域的域名。河南防火墙封锁列表上出现的总域名中，超过 35% 来自这两个类别。为了找出关注这些类别的原因，我们假设河南省一直是许多金融争议的中心，其中最突出的是 2022 年因涉及当地贷款机构的金融丑闻而引发的大规模抗议活动[75]。鉴于针对国家控制的金融机构的金融丑闻，该省很可能希望限制对其经济相关信息的访问。另一方面，这可能是审查批评该国商业和经济政策的国家政策的一部分。

另一方面，GFW 则更多地针对新闻和媒体以及成人内容域名。这与长期以来对 GFW 的理解一致，即其旨在更多地限制新闻、道德敏感和政治敏感内容。

5.2. 识别封锁规则

另一种观察各个防火墙如何配置过滤规则的方法是推断可能用于封锁列表匹配的正则表达式。正如 Anonymous 等人 [22 §6] 和 Hoang 等人 [3 §4.1] 在他们对 GFW 的 DNS 审查研究中指出的那样，GFW 使用可能针对二级域名、顶级域名和/或子域名的规则来封锁域名。他们开发了一种方法来涵盖 GFW 应用的封锁规则。我们使用了基于表8中列出的排列组合的类似方法，来推断河南防火墙和 GFW 的封锁规则。我们注意到，我们推断的正则表达式可能无法完全反映审查者使用的规则，因为我们的排列组合可能会遗漏基于二级域名的正则表达式或更复杂的正则表达式，例如我们观察到河南防火墙封锁的 *.gov*。尽管如此，我们推断的规则使我们能够识别河南防火墙封锁列表与 GFW 相比的结构性差异。

表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

如表8所示，我们为在每日测量实验（第5节）中识别出的每个被审查域名，通过在域名前面和/或后面添加一个固定字符串，生成了九种排列组合。这种方法曾被 Anonymous 等人 [22 §6] 于 2014 年和 Hoang 等人 [3 §4.1] 于 2021 年使用。在这项工作中，我们选择了模式字符串 ZZZZ 来构造每种排列组合。然后，我们独立地向我们的水槽服务器发送包含每种排列组合作为 SNI 的 ClientHello 消息，并记录了每次测试的结果。在我们的测量期间，该实验每天进行四次。

如表9所示，河南防火墙和 GFW 使用的最流行的封锁正则表达式模式是 ^(.*\.)?keyword$。此模式旨在用于封锁域名及其子域名。GFW 使用的第二种最流行的封锁正则表达式模式是 ^keyword$，仅用于封锁域名本身，而不封锁其子域名。GFW 使用的第三种最流行的封锁正则表达式模式是 ^(.*\.)?keyword，这很可能是在正则表达式模式中未包含结束锚点的错误。有趣的是，与 GFW 有时采用没有结束锚点的正则表达式模式不同，河南防火墙总是在其正则表达式模式中包含结束锚点。这一结果可能是由于封锁列表维护得更仔细、更一致，或者可能是审查软件本身强制使用以结束锚点结尾的正则表达式模式，以防止人为错误。

表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%	–	–

6. 规避策略

基于我们在第4.3节中发现的解析逻辑缺陷，以及在第4.4节中观察到的注入行为和指纹，我们介绍了一些简单但有效的策略来绕过河南防火墙。所有策略都只需要客户端进行更改，无需服务器端配合，因此易于采用和实施。这些策略已被各种流行的规避工具实现，包括但不限于 Xray [76]、GoodbyeDPI [77] 和 Shadowrocket [78]。

启用任意 TCP 选项字段。如第4.3节所述，河南防火墙只能解析和封锁 TCP 头部长度为 20 字节的数据包。在操作系统上启用任何 TCP 选项都会导致 TCP 头部长度超过 20 字节。虽然这种规避方案依赖于河南防火墙不寻常的实现方式，但用户或规避工具可以轻松利用这一特性来规避审查。例如，启用 TCP 时间戳（在某些 Windows 版本上默认禁用）将绕过河南防火墙的封锁 [56, 59]。

丢弃带有特定载荷的 TCP RST 数据包。如第4.4节所示，河南防火墙注入的 TCP RST 数据包带有一个不寻常的 10 字节载荷 0102 03 04 05 06 07 08 09 00 。其独特性使得客户端可以只丢弃由河南防火墙伪造的 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]。

7. 伦理

审查测量研究，特别是在威权政权下，需要在整个研究过程中进行仔细的伦理考量并对潜在的风险进行持续评估。在这项工作中，我们所有的审查测量都是在我们控制的机器上进行的，网络流量由我们的程序自动生成。这是审查测量研究中的一种常见做法，旨在减轻对互联网上其他主机的负担并避免给互联网用户带来风险 [3, 4, 9, 14, 15]。在分析大学网络上的真实世界流量时，我们仅收集了数据包的 TCP 头部长度字段，没有捕获任何可识别个人身份的信息或其他敏感信息。由于本研究不涉及人类受试者，因此 IRB 批准不适用，我们遵循了《门洛报告》(Menlo Report) [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 的流量上限。虽然我们的探测被审查方记录的风险和潜在危害很小，但我们在实验设计中也考虑了合理否认性（plausible deniability）。也就是说，由于我们的水槽服务器从未回复任何 ServerHello 消息或 HTTP 响应，且未曾建立完整的 TLS 或 HTTP 连接，因此我们的测量行为并不类似用户访问被审查网站时的情形。

8. 结论

在本文中，我们揭示并记录了中国互联网审查策略中一个令人警惕的迹象：我们对中国七个不同城市和省份的测量表明河南省存在一个全新的地区性防火墙。这个河南防火墙对离开该省的流量实施基于 HTTP Host 和 TLS SNI 的审查。与 GFW 相比，它展现出独特的特征，包括独特的数据包注入行为和指纹、不同的连接追踪、解析和封锁逻辑、一个一度比GFW大十倍且更动态的封锁列表，以及更靠近客户端的网络位置。这种本地化的审查表明中国可能正在偏离其集中化的审查体系，允许地方当局在各自区域内施加更大程度的控制。我们提出了一些简单但有效的规避技术来绕过河南的审查系统，这些技术已被各种流行的规避工具所整合。我们希望我们的研究能向更广泛的审查研究社区发出警报，使其意识到并进一步研究中国及其他地区新兴的地区性审查。

可用性

为了鼓励未来的研究并促进透明度和可复现性，我们公开了代码、匿名化的数据以及持续更新的封锁列表。为了提高可访问性，本文还提供了中英双语的 HTML 网页版本。项目主页位于： https://gfw.report/publications/sp25/en。

致谢

我们感谢我们的牧羊人和其他匿名审稿人提出的宝贵意见和反馈。我们也感谢勇敢的中国用户们立即报告并积极研究封锁事件，包括但不限于 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，部分得到了斯隆研究奖学金以及美国国防高级研究计划局（DARPA）的青年教师奖计划（项目编号 DARPA-RA-21-03-09-YFA9-FP-003）的支持。文中所表达的观点、意见和/或发现仅代表作者本人，不应被解读为代表美国国防部或美国政府的官方观点或政策。

引用

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
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
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
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
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
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
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
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
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
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: https://github.com/net4people/bbs/issues/43#issuecomment-673322409
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
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
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
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
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
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
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
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
Anonymous, “Issue 2426 | XTLS/Xray-core,” https://github.com/XTLS/Xray-core/issues/2426, 2023, (Accessed on 02/06/2024).
G. Report. (2022, Oct.) Large scale blocking of TLS-based censorship circumvention tools in China. [Online]. Available: https://github.com/net4people/bbs/issues/129
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
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
B. Dong, “A report about national DNS spoofing in China on Sept. 28th,” Dynamic Internet Technology, Inc., Tech. Rep., Oct. 2002. [Online]. Available: https://web.archive.org/web/20021015121616/http://www.dit-inc.us/hj-09-02.html
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
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
Anonymous. (2020, Mar.) GFW archaeology: gfw-looking-glass.sh. [Online]. Available: https://github.com/net4people/bbs/issues/25
C. Tang, “In-depth analysis of the Great Firewall of China,” http://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf, 2016.
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
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
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
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/usenixsecurity17/sec17-pearce.pdf
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
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
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
GreatFire, “GreatFire Analyzer,” https://en.greatfire.org/analyzer, n.d., accessed: 2025-04-18.
GreatFire, “Blocky,” https://blocky.greatfire.org/, accessed: 2025-04-18.
Anonymous and Amonymous. (2022, Oct.) Sharing a modified Shadowsocks as well as our thoughts on the cat-and-mouse game. [Online]. Available: https://github.com/net4people/bbs/issues/136
P. Winter. (2013, Mar.) GFW actively probes obfs2bridges. [Online]. Available: https://bugs.torproject.org/8591
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
T. Wilde. (2012) Knock knock knockin’ on bridges’ doors. [Online]. Available: https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors
Anonymous, Anonymous, Anonymous, D. Fifield, and A. Houmansadr. (2021, Jan.) A practical guide to defend against the GFW’s latest active probing. [Online]. Available: https://github.com/net4people/bbs/issues/58
Anonymous. (2021, Jan.) How to Deploy a Censorship Resistant Shadowsocks-libev Server. [Online]. Available: https://gfw.report/blog/ss_tutorial/en/
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
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
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
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
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
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
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/usenixsecurity18/sec18-liu_0.pdf
Net4People, “Net4People BBS Issues.” [Online]. Available: https://github.com/net4people/bbs/issues
NTC Community, “NTC Party: “No Thought is a Crime” — Internet Censorship Circumvention Forum.” [Online]. Available: https://ntc.party/
XTLS, “Xray-core Project Issue Tracker.” [Online]. Available: https://github.com/XTLS/Xray-core/issues
V2Fly, “V2Ray Core Project Issue Tracker.” [Online]. Available: https://github.com/v2fly/v2ray-core/issues
SagerNet, “sing-box Project Issue Tracker.” [Online]. Available: https://github.com/SagerNet/sing-box/issues
Hysteria, “Hysteria Proxy Project Issue Tracker.” [Online]. Available: https://github.com/apernet/hysteria/issues
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).
——, “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).
ghost, ““河南新上的 SNI/HOST 黑名单墙” (GitHub Discussion #3601),” https://github.com/XTLS/Xray-core/discussions/3601#discussioncomment-10293992, Aug 2024, (Accessed on April 18, 2025).
H. Lee, “启用 TCP Timestamps 解决 SNI 阻断,” https://blog.tsinbei.com/archives/1361/, Sep 2023, (Accessed on April 18, 2025).
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.
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
“IP2Location LITE IP address geolocation database.” [Online]. Available: https://www.ip2location.com/database/ip2location
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
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).
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
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
K. 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
klzgrad, “GFW技术报告：入侵防御系统的评测和问题,” https://www.chinagfw.org/2009/09/gfw_21.html, Aug 2009, accessed: 2025-04-11.
gfwrev, “HTTP URL/深度关键词检测,” https://gfwrev.blogspot.com/2010/03/http-url.html, Mar 2010, accessed: 2025-04-07.
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
W. Eddy, “Transmission Control Protocol (TCP),” RFC 9293, Aug. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9293
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
“Centralized Zone Data Service,” https://czds.icann.org/home, (Accessed on 01/31/2024).
“Website categorization api | domain category check | whoisxml api,” https://website-categorization.whoisxmlapi.com/api, (Accessed on 04/25/2024).
“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).
XRay developers. XRay. [Online]. Available: https://github.com/XTLS/Xray-core
GoodbyeDPI developers. GoodbyeDPI. [Online]. Available: https://github.com/ValdikSS/GoodbyeDPI
ShadowRocket developers. ShadowRocket. [Online]. Available: https://apps.apple.com/us/app/shadowrocket/id932747118
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
XRay developers. XRay pull request. [Online]. Available: https://github.com/XTLS/Xray-core/pull/3660
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

附录 A. 元评审

以下元评审由 2025 IEEE Symposium on Security and Privacy (S&P) 的程序委员会根据论文征集要求，在评审过程中编写。

A.1. 摘要

本文实证性地确认了中国河南省已开始部署地区性审查机制的传闻，且其审查比防火长城更为严格。论文对河南防火墙实施的审查进行了全面分析，涵盖入站和出站两个方向，揭示了其运作方式、封锁策略和残余审查机制。此外，论文还检查了中国其他省份是否存在类似的地区性审查，但未发现除防火长城之外的额外干扰证据。

A.2. 科学贡献

对先前研究有限的重要结果进行了独立确认
在一个成熟领域中取得了有价值的进步

A.3. 接收理由

1): 本文对先前研究有限的重要结果提供了独立确认。论文构建了一个测量体系，以确认（并扩展）关于中国河南省内地区性审查的传闻报告。除了对这种新型地区性审查的存在和封锁行为提供系统性理解外，本文还独立确认了防火长城封锁行为的不对称性。
2): 通过应用不同的已知研究方法，对中国部分地区一种新的审查现象进行了详尽研究，本文在一个成熟领域中取得了有价值的进步。研究所进行的测量是可靠的，并依赖于经过验证的测量方法，为一种此前未被进一步分析的审查形式提供了见解。

Wallbleed: A Memory Disclosure Vulnerability in the Great Firewall of China

Tue, 25 Feb 2025 00:00:00 +0000

Wallbleed: A Memory Disclosure Vulnerability in the Great Firewall of China

Shencha Fan

GFW Report

gfw.report@protonmail.com

Jackson Sippe

University of Colorado Boulder

Jackson.Sippe@colorado.edu

Sakamoto San

Shinonome Lab

54k4m070@proton.me

Jade Sheffey

University of Massachusetts Amherst

jsheffey@cs.umass.edu

David Fifield

david@bamsoftware.com

Amir Houmansadr

University of Massachusetts Amherst

amir@cs.umass.edu

Elson Wedwards

ElsonWedwards@proton.me

Eric Wustrow

University of Colorado Boulder

ewust@colorado.edu

Abstract

We present Wallbleed, a buffer over-read vulnerability that existed in the DNS injection subsystem of the Great Firewall of China. Wallbleed caused certain nation-wide censorship middleboxes to reveal up to 125 bytes of their memory when censoring a crafted DNS query. It afforded a rare insight into one of the Great Firewall’s well-known network attacks, namely DNS injection, in terms of its internal architecture and the censor’s operational behaviors.

To understand the causes and implications of Wallbleed, we conducted longitudinal and Internet-wide measurements for over two years from October 2021. We (1) reverse-engineered the injector’s parsing logic, (2) evaluated what information was leaked and how Internet users inside and outside of China were affected, and (3) monitored the censor’s patching behaviors over time. We identified possible internal traffic of the censorship system, analyzed its memory management and load-balancing mechanisms, and observed process-level changes in an injector node. We employed a new side channel to distinguish the injector’s multiple processes to assist our analysis. Our monitoring revealed that the censor coordinated an incorrect patch for Wallbleed in November 2023 and fully patched it in March 2024.

Wallbleed exemplifies that the harm censorship middleboxes impose on Internet users is even beyond their obvious infringement of freedom of expression. When implemented poorly, it also imposes severe privacy and confidentiality risks to Internet users.

I. Introduction

The national Internet censorship system in China, known as the Great Firewall (GFW), is composed of many parts and subsystems, each using different techniques to control access to online information. One prominent component is the DNS injection subsystem, which forges DNS responses to DNS queries for censored domain names. Until March 2024, certain DNS injection devices had a parsing bug that would, under certain conditions, cause them to include up to 125 bytes of their own memory in the forged DNS responses they sent. We call this bug Wallbleed, as a nod to similar buffer over-read vulnerabilities like Heartbleed [1], Ticketbleed [2], and Cloudbleed [3, 4].

In this work,¹ we analyze the causes and implications of Wallbleed. Our study confirms that Wallbleed existed for at least two years. (Reports of a similar vulnerability circulated as early as 2010 [5], [6].) We ran continuous measurements between October 2021 and April 2024. The vulnerability was partially patched in November 2023, but DNS injectors were still vulnerable to certain crafted queries until March 2024, when it was finally fully patched.

¹ Project homepage: https://gfw.report/publications/ndss25/en/.

Wallbleed provides an unprecedented look at the GFW, both its internal architecture as well as the censor’s operational behaviors. While prior work has studied what domains and resources are blocked in China, little is known about the inner workings of the GFW’s network middleboxes [7, 8, 9]. From the data leaked with Wallbleed, we are able to discern the underlying architecture of the GFW, and we reverse-engineer the parsing bug responsible for Wallbleed to create a behavior-identical implementation in C. During the course of our study, we discovered previously unknown characteristics of GFW DNS injection, such as that every injection process cycles through a list of false IP addresses independently and in a fixed order, a side channel that distinguishes multiple processes in an injector node. Finally, we conducted longitudinal and Internet-wide measurements to monitor the censor’s patching activity, taking advantage of a rare opportunity to learn more about how the GFW maintains its censorship infrastructure.

We examined the contents of Wallbleed-leaked memory and discovered apparent network protocol headers, payloads, x86_64 stack frames, and executable code (though we show evidence that it is not the code of the GFW itself). We sent traffic tagged with recognizable byte patterns past the GFW, and in some cases recovered those tags in subsequent Wallbleed responses, demonstrating that the vulnerability leaked at least some of the traffic seen by the GFW. We see, in Wallbleed-leaked memory, samples of plaintext network traffic and protocols not all of which are related to DNS censorship, including IP, TCP, UDP, and HTTP. We also performed IPv4-wide scans to estimate how many addresses inside and outside China might have had their traffic processed by Wallbleed-vulnerable middleboxes. Even some traffic whose source and destination are both outside China might have been affected, due to routing through China’s network border.

Significant ethical considerations accompany an investigation of this nature. We discuss them in depth in Section IX, including the question of whether or not to disclose a vulnerability in a system that is, itself, considered by many to be a source of harm [10, 11]. The injection of fraudulent DNS responses is one of many persistent attacks carried out daily by the GFW. The intention and effect of these attacks are well-known: to limit people’s access to information. Wallbleed is an example of how censorship devices pose risks to security and privacy even beyond their obvious infringement of freedom of expression. While this specific vulnerability was eventually fixed, the existence of such devices continues to be a hazard.

II. Backgroud

A. DNS injection attacks

The GFW’s DNS injection subsystem employs a fleet of middlebox devices at China’s network border that watch for DNS queries for blocked domain names. When they see one, they inject a DNS response back towards the client, spoofing the source address as if it came from the intended resolver. The injected response is a false answer to the query, containing an incorrect, useless IP address. When the client subsequently tries to connect, it will meet with an error rather than a connection to the expected destination. The injection middleboxes are on-path, not in-path devices: they do not block the query from reaching the legitimate resolver, nor the authentic response from reaching the client. The injectors’ false response “wins” because it arrives first, having been injected at a point in the network path nearer to the client [12]. Clients accept the first received DNS response, as only one response is expected per query in normal operation.

The DNS injection subsystem is bidirectional: it responds to queries in both directions, whether they are leaving China or entering it. This feature is convenient for analysis: it is easier to send packets into China from the outside, than to acquire and maintain a network vantage point inside the country. By sending DNS queries to a non-live IP address in China, we can be sure that any responses received are from a middlebox injector, not the end host.

Just as the GFW consists of disparate components, DNS injection is done by several distinct kinds of DNS injector—at least three. The foundational pieces of research on this topic are gfwrev’s work of 2009 [13], Anonymous’s work of 2014 [7], Anonymous et al.’s “Triplet censors” of 2020 [8], and Hoang et al.’s “How great is the Great Firewall?” of 2021 [9]. The several kinds of injector differ in their lists of blocked domain names, their network fingerprints at the IP and DNS layers, and quirks of their parsing logic. The Wallbleed vulnerability exists in just one kind of injector, the one which Anonymous et al. call “Injector 3” [8 §4.1].

DNS injection has long been a primary technique of the GFW. But circumventing it alone is not enough, because there are other systems in play. Even if a client is able to get a correct DNS response by some means, their communication may be disrupted by a different subsystem, such as the IP address filter [14 §4.1], TLS SNI filter [14, 15, 16] or TLS ESNI filter [14, 17]. In this paper we will be concerned only with DNS injection, and with only one kind of DNS injector.

The government of China is not alone in using DNS injection for censorship. See also, for example, the “DNS Tampering” column of Table 1 of the 2023 survey of Master and Garman [18], and Nourin et al.’s study of bidirectional injection of DNS and other protocols in Turkmenistan [19].

B. The format of DNS messages

As the Wallbleed vulnerability stems from low-level parsing errors, it will be important to understand how DNS messages are represented on the wire and in memory. The format of DNS messages is specified in RFC 1035 [20]. Queries and responses have the same basic format: a 12-byte header, followed by four variable-length sections: question, answer, authority, and additional. We will be concerned only with the question and answer sections. The question section contains the DNS name being queried (or, in a response, the name that the response is in answer to). The answer section, present only in responses, contains the information requested by a query (commonly an IP address) in a data structure called a resource record.

Figure 1 is a sample injected DNS response. It features everything that will be necessary to understand the DNS messages that arise in this research. We will use these field names and background colors consistently.

1234 ID
8180 flags
0001 QDCOUNT
0001 ANCOUNT
0000 NSCOUNT
0000 ARCOUNT
03 r s f 03 o r g 00 QNAME
0001 QTYPE (A, IPv4 address)
0001 QCLASS (IN)
c00c NAME (pointer to QNAME)
0001 TYPE (A, IPv4 address)
0001 CLASS (IN)
000000ec TTL (236 seconds)
0004 RDLENGTH
1f0d 5b 21 RDATA (31.13.91.33)

Fig. 1: The structure of an injected DNS response.

The message is a DNS response (rather than a query), as indicated by the most significant bit of the flags being set. It has one question and one answer; the authority and additional sections are empty. The QNAME in the question section is the name the DNS client asked to resolve, rsf.org. The answer section has been constructed by the GFW injector. It asserts that the client’s QNAME resolves to an incorrect IPv4 address (one of hundreds the injector may use).

The most important thing to understand is the encoding of DNS names. Names are pervasive in the DNS protocol: there is one in every question section (QNAME field), and at least one in every resource record (NAME field). A name is a sequence of labels. A label, in turn, is sequence of bytes, prefixed by a byte indicating its length. A name ends at an empty label, i.e., one that consists only of the length prefix 00. The name example.com has three labels of 7, 3, and 0 bytes. Its encoding is 13 bytes long: 07 e x a m p l e 03 c o m00.

There is an exception to the length-prefix encoding of names. If the two most significant bits of the the length prefix are set, then the other 6 bits of that byte, and the 8 bits of the next byte, form a 14-bit compression pointer that indicates that the remaining labels in the name are found starting at the given byte offset in the message. Message compression is useful because it is common for DNS messages to contain the same name more than once, or several names with a common suffix. The compression pointer pattern c00c is one to know by sight. It points to byte offset 12, which is the offset of the QNAME field in the question section. Rather than copy the QNAME into the answer section, the injectors vulnerable to Wallbleed begin the answer section with a c00c compression pointer. (The use of compression pointers is not unique to the GFW; legitimate resolvers use them as well. Of the various kinds of DNS injector that exist in the GFW, some use c00c and some make a copy of QNAME [8 §4.1].)

The format of DNS names, with its length prefixes and pointer indirection, lends itself to memory safety errors in parsers. When processing a label length prefix, one must check that the end of the label stays inside the bounds of the message. The lack of such a check is the fundamental cause of the Wallbleed overflow vulnerability.

III. Demonstrating overflow

This is a well-formed query whose QNAME, rsf.org, is on the GFW’s blocklist:

1234 0100 0001 0000 0000 0000 03 r s f 03 o r g 00 0001 0001

If we send these bytes, in a UDP datagram with destination port 53, from a host outside China to a host inside China, we get an injected DNS response. (Actually more than one response, because this QNAME is on the blocklist of more than one kind of injector.) Any destination IP address in China will do, even a non-responsive one—the query only needs to pass by an injector middlebox in transit.

An injected response looks like the following (this is Figure 1 in a more compact form):

1234 8180 0001 0001 0000 0000 03 r s f 03 o r g 00 0001 0001 c00c 0001 0001 000000ec 0004 1f 0d 5b 21

The ID and question section are copied from the query. The flags have been set as appropriate for a response. The answer section falsely asserts that the name rsf.org (represented by a compression pointer c00c) resolves to the IPv4 address 31.13.91.33 (1f0d 5b 21 ). As detailed in Appendix A, this fake address is one of many that the injector may use. If we send the query again, we will likely get a different one.

See what happens if we now artificially increase the length prefix of the org label from 03 (3) to 20 (32):

1234 0100 0001 0000 0000 0000 03 r s f 20 o r g 00 0001 0001

For one thing, we now get only one injected response: the malformed query is ignored by injectors other than the Wallbleed ones. The TTL and IP address in the answer section are different than before, which is expected: these typically change in every response. More significantly, the injected response contains 29 additional bytes before the answer section. These bytes come from the memory of the injection device that handled the query. In this example, the leaked bytes are a fragment of a UPnP HTTP header:

12348180 0001 0001 0000 0000 03 r s f 20 o r g 00 0001 0001 C u s t o m / 1 . 0 U P n P / 1 . 0 P r o c / V e r 0d c00c 0001 0001 000000820004 68 f4 2e a5

Whenever an injector responds to such a query, it reveals a small window of its memory, each time with different contents.

We posit that something like the following process must have occurred inside the injector device. Having observed a DNS query on its network tap, the injector copies the packet into memory for processing. Its goal is to parse the QNAME from the query, check it against a blocklist, and inject a response if needed. In parsing the QNAME, the injector first sees the 3-byte label rsf: so far, so good. But the length prefix 20 says that the next label is 32 bytes long, which extends over the org label and empty label, the QTYPE and QCLASS fields, and past the end of the query. Because it fails to enforce a bounds check, the injector regards the bytes that follow the packet in memory as being part of the query—as if the QNAME had been the 38 bytes 03 r s f 20 o r g 00 00 01 ⋅⋅⋅ P r o c / . Despite the extraneous bytes at the end of the name, it still matches the blocklist, for reasons we will explain in Section III-A. The injector copies the entire QNAME (as it sees it) into a DNS response. The next 4 bytes (in this example, V e r 0d ) are interpreted as the query’s QTYPE and QCLASS, and also copied into the response.

Why does the parser stop at the / byte, rather than treat it as a length prefix and reading another label? We present a precise, reverse-engineered description of the parsing algorithm in Appendix B, which answers this and other questions. In this case, it is because the QNAME parser stops after the first label length prefix that is past the end of the query.

A. Blocklist matching

When an injector checks a name against its blocklist, it does not use the name’s wire-format representation. Instead, it flattens the QNAME into a dot-delimited string terminated by a 00 byte. This string is what is passed to the blocklist lookup function. The evidence for this claim is that when a label in a query contains an ASCII dot character . or a null byte 00, the blocklist matcher interprets it as a label separator or name terminator, respectively. For example, if the name example.com were on the blocklist, either of the QNAMEs 07 e x a m p l e 03 c o m 00 or 0f e x a m p l e . c o m 00 a b c 00 would elicit an injection. Though the names are distinct at the DNS level (the first consists of three labels of 7, 3, and 0 bytes; the second of two labels of 15 and 0 bytes), they are both flattened into the same effective string “example.com”.

This explains why the QNAME 03 r s f 20 o r g 00 00 01 ⋅⋅⋅ P r o c / that was understood by the injector in the previous example matches the blocklist rule for rsf.org. Though the second label is not just org, but rather org plus many additional bytes, the first of those additional bytes is 00, which terminates the name when it is flattened into a string. The extra bytes are included in the injected DNS response, but they do not affect blocklist matching.

It also explains why we modified the length prefix of the org label, rather than the rsf label. If we had extended the rsf label, the 03 before o r g would have been interpreted as a literal character in the flattened name string—and because the string “rsf\x03org” does not match anything on the blocklist, it would not have gotten a response. Whereas by extending the org label, rsf and org remain separate labels, and the final empty label 00 becomes a string terminator. Altering the first length prefix can work, but then the second length prefix must also be changed to a dot, in order to separate the labels in the final string: 20 r s f . o r g 00.

Blocklist rules are not literal names, but patterns, like regular expressions [9 §4.1]. A single rule may, for example, block an entire domain with its subdomains. Patterns are not uniformly constructed (showing signs of fallible human curation). The rsf.org pattern we have been using is end-anchored and label-anchored: rsf.org and x.rsf.org match the pattern, but xrsf.org, rsf.org.x, and rsf.orgx do not. As a regular expression, it would be something like (.*\.)*rsf\.org$. In comparison, the pattern for shadowvpn.com is start-anchored and not label-anchored: shadowvpn.com, shadowvpn.comx, and shadowvpn.com.x match it, but xshadowvpn.com and x.shadowvpn.com do not. Its regular expression would be ^shadowvpn\.com.*.

B. Maximizing leaked bytes per response

The greatest number of bytes that may be leaked in a single response is 125. This is a consequence of the fact that the question section in injected responses has a maximum size of 131 bytes, and the shortest question section in a query that triggers a response has a length of 6 bytes. The question section in a response contains a copy of the question section from the query at the beginning; everything after that is leaked memory. To maximize the amount of leaked memory, minimize the size of the question section in the query (how big the query actually is), and maximize the size of the question section in the response (how big the injector thinks the query is).

The first step in minimizing the size of the query is to omit the QTYPE and QCLASS fields. When these fields are absent, the injector reads them from its own memory. QCLASS has no effect, and QTYPE only controls whether the injector crafts a type A (IPv4) or type AAAA (IPv6) response. The injectors default to type A for unknown QTYPEs; they send a type AAAA response only when the QTYPE is 001c. In either case, the size of the question section is the same.

The other part of minimizing query size is to use a short QNAME. To find short DNS names that trigger an injection response, we enumerated all names of the forms a.b, a.bc, and ab.c, with a, b, and c ranging over the characters ‘a’–‘z’, ‘0’–‘9’, ‘-’, and ‘_’, and sent them in DNS queries into China. We found eight short names that worked: 3.tt, 4.tt, 5.tt, 6.tt, 7.tt, 8.tt, 9.tt, and x.co. ² Each of these names takes 6 bytes to encode (e.g., 01 3 02t t00). ³

² We did this experiment on November 3, 2021. The name 3.tt has stopped triggering injection since August 7, 2023: see Section IV.
³ There is a minor subtlety here. With names as short as these, it is technically possible to omit the final 00 byte, which otherwise is needed to terminate the flattened name string parsed from the query. The injector seems to zero the 18th byte of the destination buffer before copying the query into memory, so queries that are only 17 bytes long effectively have an implicit null terminator. As the DNS header takes up 12 bytes, this trick only works for QNAMEs as short as 5 bytes. But because the first leaked byte is a constant 00 in this case, shortening the QNAME from 6 to 5 bytes does not increase the number of informative bytes leaked. See Appendix B for an algorithmic description of this and other low-level details.

At the start of Section III, we caused an injector to leak 29 bytes by increasing a QNAME label length prefix from 3 to 32. Intuitively, in order to leak more bytes, one should increase the label length further. This intuition holds true, but only up to a point. Figure 2 shows how the size of the question section in a response varies as the label length in a query is increased. (The injector we are concerned with does not enforce RFC 1035’s length limit of 63 bytes on labels [20 §4.1.4], naively interpreting every byte value as a simple length instead.) They increment one-for-one until the response question section reaches a maximum of 131 bytes. Beyond that point, the question section becomes slightly smaller than the maximum, 130 bytes.

Fig. 2: The size of the question section in injected DNS responses versus the label length prefix x in a query for the QNAME x r s f . o r g 00 . We are using the “embedded dot character” and “embedded null terminator” tricks from Section III-A, in order to place the variable label length prefix at the beginning of the question section.

This odd behavior is a product of the confused logic of the query parsing algorithm (Appendix B). Two conditions that cause the algorithm’s main loop to terminate are when the total length of the QNAME exceeds 127 bytes while processing the contents of a label, and when the parser has just read a length prefix past the end of the query. The sweet spot of 131 bytes occurs when the QNAME is 127 bytes exactly (including the final label length prefix). In this case, the first exit condition is avoided, allowing the next iteration of the loop to read 1 additional byte before exiting. The 127 bytes of the QNAME, plus 4 bytes for the missing QTYPE and QCLASS, produce a question section of 131 bytes total.

The QNAME length limit is a general characteristic of this kind of injector, independent of the Wallbleed parsing bug. We sent well-formed queries for names of increasing length (a.google.sm, aa.google.sm, aaa.google.sm, …) into China, using a base domain google.sm known to match the blocklist. The injectors stopped responding once the m byte at the end of the final label was pushed out of the first 127 bytes. The limit is the same for type A and type AAAA queries, and for any number of labels in the QNAME. The maximum name length prescribed in RFC 1035 is 255 bytes [20 §2.3.4].

Though it is satisfying to know the absolute limits and the reasons for them, there is little difference between 130 and 131 bytes in practice. In many of the experiments of this paper (some performed before we understood the nuances of the parsing algorithm), we used a label length prefix of ff, which gets 1 byte fewer per query than the maximum possible. A question section of 130 bytes in response to sufficiently large length prefixes agrees with findings of klzgrad in 2012 [6].

C. Incomplete patch (Wallbleed v2)

The GFW attempted to patch Wallbleed between September and November 2023, adding restrictions to the DNS message parsing algorithm. We have documented the progression of patching in Section VII. The QTYPE and QCLASS fields could no longer be omitted, and QCLASS had to have the value 0001. In addition, a label length prefix that overflowed the end of the query but did not reach the 127-byte QNAME length threshold caused a query to be ignored. A query like the following no longer worked to leak DNS injector memory:

00000120 0001 0000 0000 0000 03 w w w 06 g o o g l e ff c o m 00

But the first patch overlooked one of the exit conditions in the parsing loop. A query with QTYPE and QCLASS, and with a final label length prefix that exceeded the 127-byte threshold, still caused the parser to think the query was larger than it really was. A slightly modified probe format still worked to elicit the contents of memory:

00000120 0001 0000 0000 0000 03 w w w 06 g o o g l e 03 c o m ff0001 0001

We named the pre-patch and post-patch vulnerabilities Wallbleed v1 and Wallbleed v2 respectively. We have used Wallbleed v1 probes in most of the experiments described in this paper. After the patch, we were able to resume experiments using modified probes, until Wallbleed v2 was finally patched in March 2024. With Wallbleed v2, only maximum-length overflows were possible: ff for a label length worked, but 20 did not. We found that the shortest domains, like 3.tt, no longer worked as triggers, and therefore did later experiments with te.rs, the next shortest effective domain.

D. Other details of injection triggering

Here we comment on a few other details of the conditions to trigger injection. Note that there are other kinds of DNS injector in the GFW [8, 9], with its own blocklist and implementation quirks.

The injector defaults to type A responses. The DNS injectors respond only to queries whose QNAME matches a certain blocklist. The vulnerable injector injects type AAAA responses to type AAAA queries, and type A responses to queries of all other types.

The injector works on both IPv4 and IPv6. The UDP datagrams that carry DNS queries may be sent over IPv4 or IPv6; the injector responds to either, forging an IPv4 or IPv6 response as appropriate for the query. (Here we are referring to the IP version over which the query is sent, not the QTYPE of the query. A query sent over IPv4 may request an IPv6 address and vice versa.) On May 9, 2023, we sent Wallbleed probes for the QNAME ff g o o g l e . s m 00 Francisco, AS14061) to an IPv6 host in Alibaba Cloud (Beijing, AS37963) and to a non–DNS server 2400:dd01:103a:4041::101 in China. In both cases, we got an injected DNS response containing leaked memory. However, we could not trigger DNS injection in the other direction, sending queries from the VPS in China to the VPS or other IPv6 addresses in the US. This is likely because the injector was not deployed on the paths from our VPS in China to the foreign destinations we tested.

Only destination port 53 is looked at. On May 9, 2023, we sent queries for google.sm from the VPS in the US to our VPS in China, varying the UDP destination port over every value between 0 and 65535. Only queries sent to port 53 resulted in injections. This observation is consistent with prior findings of Lowe et al. in 2007 [21 §6.4] and Anonymous et al. in 2020 [8 §2.1].

IV. What information is leaked?

To better understand what information is leaked from the vulnerability, we conducted a longitudinal measurement and collected data for two years, from November 21, 2021 to November 29, 2023. Table I I summarizes this experiment, as well as those of later sections.

TABLE I: Experiment timeline and vantage points. In total, we used three VPSes in Tencent Cloud (TC, Beijing) (AS45090), one machine at the University Colorado Boulder (Scan, CO) (AS104) and one machine at the University of Massachusetts Amherst (Long, MA) (AS1249).

Experiments	Time Span		Duration		CN Hosts	US Hosts	Sections
Characterization	Oct. 2, 2021 – Feb. 10, 2022		4	months	1 (TC, Beijing)	1 (Long, MA)	§III-B
Re-characterization	May 9 – Sep. 10, 2023	& Feb, 2024	5	months	1 (TC, Beijing)	1 (Long, MA)	§III
Longitudinal	Nov. 21, 2021 – Apr. 16, 2024		2	years	3 (TC, Beijing)	1 (Long, MA)	§IV
Seeing Our Own	Aug. 12 – Sep. 8, 2023	& Mar. 13, 2024	4	weeks	1 (TC, Beijing)	1 (Scan, CO)	§V
Internet Scan	Jun. 25 & Aug. 23, 2023	& Mar. 6, 2024	3	days	-	1 (Scan, CO)	§VI
Patching Behavior	Sep. 6 – Nov. 7, 2023	& Mar. 6, 2024 – Apr. 16, 2024	3	months	2 (TC, Beijing)	2 (Scan & Long)	§VII, §III-C

Based on the observations in Section III-B, we designed the following Wallbleed probe to trigger the vulnerability:

00000120 0001 0000 0000 0000 01 3 ff t t

The probe is a query for 3.tt, but truncated before the terminating empty label of QNAME (omitting the QCLASS and QTYPE fields), and with the tt label length prefix increased from 02to ff. (Per footnote 3, no final 00 label is needed for a QNAME this short.) As explained in Section III-B, this probe causes a leak of 124 bytes of memory.

Experiment setup. We sent Wallbleed probes from a host in a US university to an IP address in China. The address in China was a VPS under our control in Tencent Cloud (AS45090). We varied the UDP source port of probes over a range of 1,000 port numbers (10001 to 11000), as prior work has suggested that the source port number may affect DNS injection [22]. We sent probes at a rate of 100 packets per second (pps) and collected 5.1 billion Wallbleed responses over two years.

Query names. The QNAME we started with, 3.tt, was evidently removed from the injectors’ blocklists and stopped eliciting injection responses on Monday, August 7, 2023 at 11:04:01 (China Standard Time, UTC+8). We changed the QNAME to 4.tt, another short name from Section III-B.

A. Wallbleed leaks network traffic

Looking at samples of the 124-byte leaked fragments of memory, it is immediately clear that they include snippets of network traffic. These snippets originate, at least in part, in packets that pass by the injection device: in Section V we demonstrate recovery of packet payloads that we ourselves sent through the GFW. But the mix of protocols is different from what one would expect of a uniform sample of all traffic entering or exiting China.

After preliminary manual analysis of a sample of responses, we used regular expressions to search for common or sensitive strings. To reduce the risk of analyzing human-identifiable information, our program outputs only the number of matches. As shown in Table II, we find instances of UPnP, SSDP, HTTP, SMTP, SSH, and TLS, as well as potentially sensitive information such as HTTP cookies and passwords.

TABLE II: Counts of matches of regular expressions against 5.1 billion Wallbleed responses observed over two years.

Regular Expression	Protocol	Count		Rate
ssdp:discover	SSDP	184	M	3.61%
UPnP/IGD\xml	UPnP	174	M	3.41%
(?s)[3-4]\xfftt.....-CONTROL	(§IV-B)	121	M	2.37%
\x45\x00	(§IV-A)	2.8	M	0.05%
uuid:WAN	SSDP	34	M	0.67%
Host:␣	HTTP	21	M	0.41%
(?i)Date:\s* …	(§IV-C)	16	M	0.31%
\x7f\x00\x00	(§IV-D)	2.8	M	0.05%
Cookie:␣	HTTP	2.0	M	0.04%
RCPT␣TO	SMTP	72.5	k	0.0014%
&key=	URL	58.1	k	0.0011%
MAIL␣FROM	SMTP	42.4	k	0.0008%
&password=	URL	26.9	k	0.0005%

It is remarkable that the memory contains application-layer protocols other than DNS. Since the injector responds to DNS queries only on UDP port 53 (Section III-D), we might expect to see only DNS, or only UDP port 53 traffic; but in fact we see a variety of protocols, including ones that typically run on different ports and transport protocols. A noticeably large fraction consists of UPnP (Universal Plug and Play) and SSDP (Simple Service Discovery Protocol). UPnP uses HTTP—but there is more than an order of magnitude more UPnP than other forms of HTTP. The sample response in Section III is one such instance of UPnP. We extracted the HTTP Location header from 166 million UPnP snippets: in every case, the host part of the URL was a literal IP address in one of the private ranges of RFC 1918 [23]. Private addresses are consistent with UPnP and SSDP, which are normally used for service discovery in local networks. Nonetheless, it is difficult to explain why they appear at such a high rate in the memory of the vulnerable injector.

In addition to application-layer protocols, there are network-layer and transport-layer headers and packets. For instance, there are IPv4 headers. To find these, we first looked for the two-byte pattern 4500 that commonly begins an IPv4 header, then (interpreting the bytes that follow as a header) filtered for a valid IP checksum. Table III shows the distribution of the protocol field in 181,834 IPv4 headers. TCP, UDP, and ICMP are the most common, with a long tail of 43 others.

TABLE III: The most common protocol fields in IPv4 headers. Only counts of more than 10 are shown.

Number	Protocol Name	Count
6	TCP	120,087
17	UDP	59,882
1	ICMP	1,735
50	ESP	38
0	IPv6 Hop-by-Hop Option	36
47	GRE	12

There were 7,743 cases where an IP header was followed by a TCP header and enough data to form a complete TCP segment, having consistent length fields and valid IP and TCP checksums. TCP headers have flags and port numbers, from which we may heuristically infer which of the two IP addresses in the IP header is the server, and which is the client. To avoid analyzing human-identifiable information, we anonymized IP addresses into two coarse categories: private (RFC 1918) and public. We then counted the proportions of client/server and private/public; the results are shown in Table IV.

TABLE IV: Client/server and private/public flows inferred from 7,743 complete TCP segments.

Client Address	Server Address	Count
Private	Private	384
Private	Public	6,276
Public	Private	193
Public	Public	890

Since the DNS injectors monitor public Internet traffic, we expected that TCP segments recovered from their memory would have mostly public IP addresses; however only 11% of TCP segments are public-to-public. Most of them actually involve a private client and a public server. Because private IP addresses are not globally routable, one might suspect that they represent part of the GFW’s internal traffic (which would be compatible with the observations about UPnP above). However, the limited size of the memory leak means we can count only fairly short TCP segments (up to 125 bytes). It is also a possibility that the TCP segments we see were encapsulated in a higher-level protocol like GRE, not directly routed past the middlebox.

B. The four “digest” bytes

At the beginning of the longitudinal experiment, the first 4 bytes of leaked data in Wallbleed responses were different from the others. They were generally more random-looking, which was especially apparent when a leak otherwise consisted of readable ASCII. Dissimilar byte sequences might be attributed to partially overwritten memory, but this was different: it was consistently the first 4 bytes,⁴ and they did not contain fragments of network protocols as the other bytes did. We took to calling these bytes “digest” bytes, on the supposition that they represented a hash of the query packet, possibly for load-balancing purposes. (This is only a guess—we tried, but did not find a hash algorithm that reproduced the digest bytes.) Digest bytes disappeared from Wallbleed responses in two stages across 2022 and 2023.

⁴ In the special case of a 17-byte query, including the probe used in this section, the digest bytes came after the initial 00 described in footnote 3.

Digest bytes were not actually random, but were determined by the contents of the DNS query, including its UDP 4-tuple. On February 15, 2022 (at a time when all Wallbleed responses had digest bytes), we sent Wallbleed probes with identical payloads and source and destination IP addresses and ports. In all 114,717 resulting injections, the first 4 bytes were exactly d8fd d0 41 . Keeping the 4-tuple fixed and changing a bit in the payload, however, caused the digest bytes to change.⁵ This may be compared to the injector process assignment of Section V-A, which depends on the 4-tuple but not the payload.

⁵ Changing a payload bit also changes the IP checksum, so digest bytes may have depended on IP and UDP headers only, or on headers and payload.

We measured the prevalence of digest bytes over time by looking for a particular string, ACHE-CONTROL (part of an HTTP Cache-Control header), that frequently appears at the beginning of Wallbleed responses (Table II). When digest bytes are present, the first 4 bytes of the string are overwritten. Figure 3 shows how digest bytes disappeared in two stages over nine months. When we began measurements, all responses had digest bytes. The first response that lacked digest bytes was on Saturday, September 3, 2022, at 01:31 (China Standard Time, UTC+8). After that, the presence or absence of digest bytes depended on the source port of the probe, with roughly half of ports eliciting digest bytes at a given point in time. The mapping of which ports caused digest bytes changed sporadically, but remained at a 50% fraction—we suspect this represents load balancing. After Thursday, June 8, 2023, at 15:33 (UTC+8), digest bytes almost completely disappeared.

Fig. 3: The lower plot shows the rate of Wallbleed responses with digest bytes, averaged over all probe source ports in a day. Before September 3, 2022, all responses had digest bytes; after June 8, 2023, none did; and in between, half did and half did not. During the transition period, whether a given source port elicited digest bytes was consistent over short time spans. The upper plot shows the rate of digest responses by probe source port and day, which is always close to 0% or 100%.

C. How long bytes remain in memory

We estimated how long bytes tend to remain in memory by looking for naturally occurring timestamps, namely HTTP Date headers. These strings, in the format Date: Wed, 21 Apr 2021 00:00:00 GMT, indicate the time at which an HTTP response was generated. Figure 4 shows the distribution of the age of 16.3 million Wallbleed responses containing complete Date headers: the difference between when a response was received and the timestamp encoded in its Date header. Most Date headers are from the recent past: 75% are between 0 and 5 seconds old, and 7% are older. About 10% are nominally almost exactly 8 hours in the future relative to the time of capture, which is likely a result of servers wrongly reporting local time as UTC.

In Section V-A we conduct a similar memory-age experiment, using our own deliberately placed timestamps.

Fig. 4: Cumulative distribution of HTTP Date timestamps relative to the time of capture. The upper plot has a scale of seconds; the lower a scale of hours. Most timestamps are less than 5 seconds old. Time zone errors make some appear to be 8 hours in the future.

D. Inferring the GFW’s internal architecture

Leaked memory occasionally contained what looked like x86_64 pointers. These are 64-bit values in little-endian byte order, whose most significant 16 bits are zero, and which lie in conventional address ranges. On Linux, the typical address range of stack pointers is 0x00007f0000000000–0x00007fffffffffff, and that of code and heap pointers is 0x0000550000000000–0x000056ffffffffff.

A typical stack from on Linux contains a stack address followed by a code address (corresponding to a saved frame pointer and return address respectively). We looked for these patterns in our leaked payloads. We found 70,497 examples, and noticed several common patterns. We created pattern templates based off the 14 64-bit words present in each payload. For example, a stack address (a 64-bit value in the typical Linux stack pointer range) is replaced with the single character ‘s’. In this way, code pointers (‘c’), and common numbers including zero (‘0’), −128 (‘1’), 22 (‘2’), and 4 (‘4’) are replaced, and remaining unlabeled words are converted to ‘_’. This yields 3,559 unique patterns, the most frequently occurring of which we plot in Figure 5.

Fig. 5: The counts of common stack frame patterns in leaked memory seen weekly over time. ‘s’ and ‘c’ correspond to stack and code addresses respectively, and digits to specific common 64-bit values we observed. Red vertical lines indicate when we observed changes in the digest-byte pattern (Figure 3).

The two red lines indicate the stages of digest byte transition from Figure 3. The first line, on September 3, 2023, coincides with a shift to the most seen stack frame patterns; the second, on June 8, 2023, does not show as clear a pattern change. We were not able to draw more concrete conclusions from these changing patterns though; they may be purely coincidental.

The stack frames we see are congruent with Linux stack frames with ASLR enabled, as indicated by a given pattern seeing randomization in a subset of bits: the least significant 12 bits are consistent across stack/code pointers, corresponding to the consistent offset in a 4 KB page. In some stack frames, we also observe what appear to be glibc stack canaries [24], indicated by a random value whose least significant 8 bits are set to 0 preceding a stack/code address pair.

We also observe sequences of x86_64 instructions, such as function prologues. We believe these to be code that the GFW sees on the network, not the code of the GFW itself, for two reasons. First, it is implausible that instructions would leak in a stack-based memory disclosure, as Linux clears pages before allocation and does not allow executable code in writable pages. Second, we also observe x86_64 code in traffic seen on a university network tap, which appears to be Microsoft code updates that send (signed) plaintext binaries [25].

V. Seeing our own traffic

In Section IV-A we saw evidence that Wallbleed leaked at least some network traffic, even non-DNS traffic, that passed through an injection device. Here we confirm that fact with a dedicated experiment. We sent our own tagged traffic across the border into China, and were later able to recover a fraction of it in Wallbleed responses.

Tagged traffic was recoverable only within a few seconds of its being sent. The recovery rate was low, and varied by time of day. Injection devices are internally divided into multiple independent processes, which we reveal using a previously undocumented side channel in the ordering of injected false IP addresses. Each process has its own memory: recovery of past traffic is possible only when a Wallbleed probehappens to be assigned to the same process. The assignment of packets to processes is deterministic, and depends on (at least) the source port of the probe. Probes sent over IPv6 may recover traffic originally sent over IPv4, and vice versa.

A. Timestamped magic sequence probes

We developed a new probe for this experiment. The magic sequence probe is a UDP packet, sent to port 53, whose 40-byte payload is two copies of the 20-byte sequence:

G F W B l e e d exp pkt rep timestamp

where exp is an experiment ID, pkt is an incrementing packet ID, rep is 0 for the first copy of the sequence in a probe or 1 for the second, and timestamp is an epoch timestamp. The fixed string “GFWBleed” and unique IDs make it easy to identify magic sequences in Wallbleed responses. The timestamp lets us estimate how long a recovered magic sequence was kept in memory. While magic sequence probes use UDP and destination port 53, they are not DNS in structure.

At the same time as sending magic sequence probes, we sent Wallbleed probes, as in Section IV, to recover the sequences we were trying to place in memory. We sent the probes from a US university to a destination in China between August 12 and September 8, 2023 (Table I). The destination host was different from the one used in Section IV to avoid potential interference between the two experiments. We sent magic sequence probes at an average rate of 30 pps, from a single source port 10000. We sent Wallbleed probes at 100 pps from 199 source ports in the range 20001–20199. The choice to use a single source port for magic sequence probes would turn out to be significant, as it helped reveal the existence of discrete injector processes. We collected 3,521 Wallbleed responses containing magic sequences.

Recovered traffic is usually less than 1 second old. Figure 6 shows the difference between the timestamp encoded in a magic sequence probe and when it was recovered in a Wallbleed response. As with the HTTP Date timestamps of Section IV-C, traffic was short-lived in the injector’s memory: 99% of recovered magic sequences were less than 1.5 s old. The uniform slope between −1 s and 0 s is an artifact of the one-second granularity of timestamp. Unlike the HTTP Date experiment, here there is no possibility of time zone confusion.

Fig. 6: Cumulative distribution of the difference between the timestamp stored in a magic sequence and when we recovered it in a Wallbleed response. The graph shows the distribution of 3,521 Wallbleed responses with magic sequences, collected between August 12 and September 8, 2023. The range of time differences is −10.19 s to −0.23 s.

The likelihood to recover traffic varies in a daily cycle. Figure 7 shows the number of Wallbleed responses containing magic sequences at each hour of the day, over 28 days. Though we sent Wallbleed probes and magic sequence probes at a constant rate, the number of probes recovered per hour varies in a 24-hour cycle, with a peak between 04:00 and 05:00 and a trough between 22:00 and 23:00 (China Standard Time, UTC+8). This is consistent with the inverse diurnal pattern of Internet traffic volume in China: the more traffic the injector handles, the less likely we are to observe our own packets.

Fig. 7: The likelihood of observing a magic sequence depends on the time of day. The faint background points represent the number of Wallbleed responses containing a magic sequence received during every hour of the day, over four weeks starting on August 14, 2023. The dark foreground points are averages of corresponding hours across all 28 days.

Packets have consistent alignment in memory. When we recover a magic sequence, we do not get all 40 bytes in full. Almost always, the beginning is overwritten by the bytes of the Wallbleed probe that triggered the response. With the Wallbleed probe from Section IV, the first 18 bytes are overwritten and the last 22 bytes are intact. It is likely that the injection device aligns the first byte of packets at consistent locations in memory. Other observations support this hypothesis: in Section IV-B, we took advantage of the alignment of a common ACHE-CONTROL string to test for the presence of digest bytes.

Only a subset of source ports ever saw a magic sequence. We sent magic sequence probes from a single source port (10000). Though we sent Wallbleed probes from 199 different source ports (20001–20199), only 64 source ports ever recovered a magic sequence. (Those that did recovered 55 magic sequences on average.) Further investigation led us to believe that each DNS injection device consists of multiple independent processes, each with its own memory buffer, and that packets are deterministically assigned to a process according to features that include the source port. (But not the payload, because magic sequence probes had variable payloads. This contrasts with the digest bytes of Section IV-B, which did depend on the payload.) Only when a Wallbleed probe is assigned to the same process as the original magic sequence probe does it have a chance of recovering it. (This could explain the horizontal bands in Figure 3: for a time, half of processes used digest bytes and half did not.) In the next subsection, we show more evidence for the multiple-process hypothesis, in the form of a previously unknown side channel in the fake IP addresses of injected DNS responses.

B. The ordering of phony IP addresses

Previous research has shown that the GFW’s DNS injection draws fake response IP addresses from a fixed pool—and that different subsets of the pool are used, depending on what name is queried [8 §3.2], [9 §5.3]. What has not been appreciated, before now, is that the pools are also ordered and cyclic. When probed at a high enough rate (around 100 queries per second or more—much greater than an injector’s natural injection rate), using a consistent query name and source/destination IP address and port tuple, injected responses repeatedly cycle through IP addresses in the same order (with occasional gaps where the injector responded to queries from other users). By repeated probing, it is possible to get multiple copies of the sequence, reconcile the gaps, and recover the complete ordered list of false IP addresses for a given query name. A sample ordered list of 592 IP addresses for the query name 4.tt appears in Appendix A.

Choosing any IP address to be “first” in the cycle, we may build a reverse mapping from an IP address to its index. Independent of the Wallbleed leak, every DNS response reveals the injector’s internal index variable at the time of injection. Figure 8 shows the index of the IP address contained in Wallbleed responses over a 45-second interval, when probed at a high rate from 199 source ports. We see not one, but three roughly linear sequences. They are cyclic: when one reaches the top, it wraps around to the bottom. The same source port consistently maps to the same sequence. To us, it looks like hash-based load balancing over multiple processes within the injector device. The input to the load balancing assignment includes a packet’s UDP 4-tuple, but not its data payload (because the magic sequence probes’ payloads are variable). Keeping the rest of the 4-tuple fixed, source ports fall into a handful of equivalence classes according to which injector process they are assigned to. This explains why only 64 of 199 source ports recovered magic sequences: those are the ones that happened to be assigned to the same process as the magic sequence probes with source port 10000.

Fig. 8: A 45-second sample of Wallbleed responses received on August 23, 2023, the result of probing at a high rate from 199 different source ports. The IP address in each response has been reverse-mapped to its index (from 1 to 592) in the ordered list of Appendix A. The indices are not random, but form three distinct cyclic sequences—each source port consistently mapping to one of the three. Each sequence represents a process within the DNS injector, with its own address list iterator and memory allocation. Only 64 of 199 source ports mapped to the right process to recover the magic sequence probes of Section V-A.

C. IPv4 and IPv6

Wallbleed provides a way to tell if IPv4 and IPv6 packets are processed on the same GFW nodes or different ones. If we send a unique payload over IPv4 past the GFW, and see parts of that payload in leaked memory from IPv6-based Wallbleed queries, then we know that there are nodes that process both IPv4 and IPv6 in the same memory.

We assembled a set of IPv6 prefixes that geolocate to China from MaxMind’s GeoLite2 country code database [26] (downloaded March 12, 2024), excluding prefixes that were not routed, based on RouteViews BGP data (downloaded March 13, 2024). We sent a Wallbleed v2 probe to 8 random addresses in each IPv6 prefix. If at least 6 responded with a Wallbleed leak, we kept the prefix. We sampled these 610 IPv6 prefixes to obtain 133 k random IPv6 addresses that have a high likelihood of passing a GFW node. For IPv4 addresses, we randomly sampled 126 k IPv4 addresses that responded to an IPv4-wide ZMap scan, conducted March 6, 2024.

To each IPv4 and IPv6 address, we sent a needle: a UDP port 53 packet with a 900-byte payload consisting of a repeated sequence of an 8-byte string, 2-byte experiment ID, and 4-byte index that identified which IP address we sent the needle to. In parallel, we sent Wallbleed v2 probes to each address at a speed of 50 packets per second, and collected the responses to see if any contained previously sent needles. We repeated this process five times over 80 minutes.

There were 70 instances of one address receiving a Wallbleed-leaked payload containing a needle originally sent to a different address. Of these, 12 leaked from an IPv4 needle to an IPv4-probed address, 47 leaked IPv6-to-IPv6, 8 IPv4-to-IPv6, and 3 IPv6-to-IPv4. The presence of IPv4-to-IPv6 and IPv6-to-IPv4 leaks demonstrates that Wallbleed-vulnerable DNS injectors process both IPv4 and IPv6 traffic in the same memory space.

VI. IP addresses affected by Wallbleed

Wallbleed-prone DNS injectors formed part of the Great Firewall of China. Did these injectors affect every part of China, or anywhere outside China? How many IP addresses might have had their traffic pass through a vulnerable injector, and thus potentially be leaked? We did IPv4-wide scans from the outside of China to answer these questions. Both Wallbleed v1 and v2 affected IP addresses everywhere in China, consistent with the hypothesis of deployment of DNS injection at the network border. In many cases, even probes sent from the US to a place outside China got Wallbleed injections, because of network paths that transit the border.

A. IPv4-wide scan

We used ZMap [27] to scan the public IPv4 address space from a US university. To discover IP addresses affected by Wallbleed v1, we sent this payload to UDP port 53:

00000120 0001 0000 0000 0000 01 4 10 t t

The payload is designed to elicit overflow from Wallbleed injectors, with only a small amount (14 bytes) of overflow to confirm the vulnerability. As is explained in footnote 3, this very short QNAME does not require a trailing 00 to be effective. We sent packets at a rate of 250 Mbps, and the scan took three hours.

We chose the name 4.tt because it is unlikely to be on the DNS blocklists of countries other than China. As late as November 2020, 4.tt was a Chinese-language gambling site.⁶ (Gambling is one of the topics blocked by the Great Firewall [28 Art. 15], [9 §4.2].) The name no longer resolves to an IP address, and has not since at least July 2023. Using a China-focused and defunct name in our scans reduces the chance of triggering DNS injectors in other countries.

⁶ https://web.archive.org/web/2020*/http://4.tt/

To discover IP addresses affected by Wallbleed v2, we sent the following payload to UDP port 53:

00000100 0001 0000 0000 0000 02 t e 02 r s ff 0001 0001

As introduced in Section III-C, te.rs was the shortest effective QNAME for Wallbleed v2, and the label length prefix had to extend past a constant threshold in the parser.⁷

Limitations. We ran the scans just three times: on June 25, 2023 and August 23, 2023 for Wallbleed v1, and on March 6, 2024 for Wallbleed v2. We scanned from one host in the US: other locations with different network paths to China might find different results. The results of this snapshot study reflect routing patterns at the time of the scan, and we cannot say how they may change over time. Similar injector middleboxes—with or without Wallbleed-like vulnerabilities—may exist in other countries, but our scans would not have found them, as we used a China-specific blocked domain.

⁷ We failed to limit the amount of overflow with Wallbleed v2 probes as we did with Wallbleed v1, which we might have done by adding a prefix to the QNAME to bring its length close to the injectors’ maximum length threshold.

B. Analysis of Wallbleed responses

Unless stated otherwise, the analysis in this section is based on the scan of August 23, 2023. The results of the June 25, 2023 scan for Wallbleed v1 and the March 6, 2024 scan for Wallbleed v2 were qualitatively similar.⁸ The scan elicited 248.3 million responses from 245.4 million distinct IP addresses. 2.17 million IP addresses had more than one response, as many as 20,270 in one case, which may have been the result of routing loops [29, 30].

⁸ We failed to limit the amount of overflow with Wallbleed v2 probes as we did with Wallbleed v1, which we might have done by adding a prefix to the QNAME to bring its length close to the injectors’ maximum length threshold.

We used a two-step filter to separate Wallbleed injections from other responses. First, we filtered for responses whose answer section contained a false IP address known to be used by Wallbleed injectors. To be precise, we kept responses that ended in a resource record of the form c00c 0001 0001 TTL 0004 a b c d (type A), or c00c 001c 0001 TTL 0010 a b c d e f g h (type AAAA), where a.b.c.d or a:b:c:d:e:f:g:h is one of the IP addresses in Appendix A. (Both type A and type AAAA responses are possible, though the probe did not specify a QTYPE.) Next, we filtered for responses beginning with the byte pattern 00008180 0001 0001 0000 0000 01 4 10 t t ; that is, a response for the QNAME and ID field of the probe, and flags equal to 8180, as is characteristic of the affected injectors.

After filtering, there remained 244,911,941 responses (98.6% of all responses) from 242,442,549 distinct IP addresses that were definite Wallbleed injections. Table V shows the distribution of UDP payload lengths and DNS answer resource record types.

TABLE V: UDP length and DNS resource record type of Wallbleed responses in the Wallbleed v1 scan.

UDP Payload Length (Bytes)	# Responses	TYPE
52	244,881,083	A
64	30,837	AAAA
33	8	A
48	7	A
45, 46, 50, 51, 158	1	A
68	1	AAAA

In virtually all cases (99.99%), the response to our probe was a type A (IPv4) response of 52 bytes. 52 bytes is the expected length, given the label length prefix in the probe and the fixed size of the injector’s answer section. In a small number of cases, the response was a type AAAA (IPv6) response of 64 bytes. There is an explanation for this effect: because our probe did not contain a QTYPE field, the injector took the QTYPE from bytes in memory located just after the probe. The injector defaults to type A responses, but in the special case that the bytes corresponding to QTYPE have the value 001c, the injector crafts a type AAAA response instead.

C. Analysis of responding IP addresses

We used IP geolocation and IP-to-ASN mapping to find the location of IP addresses for which a Wallbleed response was received in the horizontal scans (after filtering out non-Wallbleed responses as described in the previous subsection). Unsurprisingly, almost all are reported to be in China, and they represent every geographic region of the country. A minority of responding IP addresses are reported to be outside China (after cross-checking against multiple databases to reduce the chance of geolocation errors).

We looked up every IP address affected by Wallbleed responses in the country-level IP2Location LITE DB5 database [31] (June 30, 2023) and the CAIDA ASN database [32] (July 18, 2023). The 242 million IP addresses for which a Wallbleed response was received map to 32 countries or regions, and belong to 381 ASes with 554 different ASNs. Table VI shows the top ten ASes by number of responding IP addresses, all located in China.

TABLE VI: The ASes ASes with the greatest number of Wallbleed- affected IP addresses. All are located in China, according to a geolocation database. When an AS has multiple ASNs, we show the one with the most affected IP addresses.

AS Name	ASNs	# IPs
China Telecom	4134, …	104.2 M
China Unicom Backbone	4837, …	54.9 M
China Mobile	9808, …	23.9 M
China TieTong	9394, …	12.8 M
China Unicom	4837, …	12.7 M
Alibaba	37963, …	7.3 M
Tencent	45090, …	5.2 M
China Networks IX	4847	3.7 M
CERNET	4538	3.1 M
Oriental Cable Network	9812	1.7 M

For finer granularity, we sampled 10,000 IP addresses that country-level geolocation placed in China, and looked them up in the city- and province-level IP2Location LITE DB5 database [31] (August 24, 2023). The sampled IP addresses represented all 22 provinces, 5 autonomous regions, and 4 municipalities of China. We therefore surmise that Wallbleed-prone DNS injectors affected the entire country, not only certain regions.

TABLE VII: Networks outside China for which Wallbleed responses were received in horizontal scans from the US. Two scans are represented, one on June 25, 2023 and one on August 23, 2023. The table shows the ten ASes with the greatest number of affected IP addresses. In total, there were 104 non-Chinese ASes in 37 countries in the June scan, and 99 ASes in 31 countries in the August scan.

AS Name	ASN	CC	# Unique IPs
Jun.	Aug.
Dreamline	9457	KR	1,534	1,086
MASTER-7-AS	26380	AU	315	489
Anpple Tech	133847	MY	243	257
Chinanet Backbone	4134	HK	235	248
AZT	53587	US	186	168
Network Joint	133762	HK	63	61
HK Broadband	9269	HK	50	85
STACKS-INC-01	398704	HK	31	78
Viettel Group	7552	VN	31	30
Aofei Data	135391	HK	29	28

Just 110,676 (0.05%) IP addresses mapped to a country other than China in country-level geolocation. It is not implausible that addresses outside China should be affected, as DNS injection is known to affect network paths that merely pass through China in transit [33]. But because geolocation databases can be inaccurate [34 §6.2], we applied additional filtering to eliminate addresses that are less certain to be outside of China:

1): We used three different databases: MaxMind GeoLite2 city [26] (September 1, 2023), IP2Location LITE DB5 [31] (August 24, 2023), and IPGeolocation.io [35] (October 2, 2023). If an IP address mapped to China in any database, we discounted its entire /24 network.
2): We looked up each IP address in the ASN databases of Team Cymru [36] (October 2, 2023) and CAIDA [32] (June 27, 2023). When an ASN’s country of registration was China, we also discounted its entire /24 network.

The filter is designed to be conservative, in that it errs on the side of placing IP addresses in China. 6,822 IP addresses remained after filtering. Table VII summarizes them by AS, and Figure 9 shows their geolocation.

Fig. 9: City-level geolocation of IP addresses outside China for which a Wallbleed response was received, when scanning from our host in the US.

Though there likely remain a few incorrect geolocations, it is clear that some traffic outside of China may have been exposed to the privacy risk represented by Wallbleed. In 2010, Sparks et al. observed that 109 regions are DNS-polluted, primarily due to GFW DNS injections on the transit paths to TLD servers [33 §4.4]. In 2021, hosts in Mexico were not able to reach whatsapp.net as the GFW injected forged responses to queries to the root DNS servers in China [37, 38].

VII. Monitoring the censor’s patching behavior

We expected that the GFW would eventually patch the Wallbleed vulnerability. With a combination of continuous monitoring and China-wide scans, we captured the process of patching both Wallbleed v1 in September/October 2023, and Wallbleed v2 in March 2024.

Experiment setup. For continuous monitoring, we sent Wallbleed probes and ordinary DNS queries for the same QNAME, at 100 pps, from the US to an IP address under our control in China. We used 4.tt for v1 probes and and te.rs for v2 probes. The ordinary DNS queries acted as controls to distinguish patching of the vulnerability from the injector being offline or the QNAME being removed from the blocklist. If the injector stops responding to Wallbleed probes, but continues to respond to the normal probes without interruption, this is evidence that the censor can hot-patch the GFW with minimal downtime. On the other hand, if the injector stops responding to both for some time, and later resumes responding to normal probes only, then we can measure the downtime related to patching. Using a machine in UMass Amherst, we did continuous monitoring of Wallbleed v1 between September 6 and November 7, 2023, and of Wallbleed v2 between March 6 and April 16, 2024.

We also did scans of a sample of about one million addresses in China. These were designed to test whether patching would happen at different times in different regions, or simultaneously across the country. We selected one representative per /24 subnet from the 215 million responsive IPv4 addresses discovered in the IPv4 scan of Section VI, yielding 1,130,343 IP addresses. We used ZMap [27] to send a Wallbleed probe to each of these IP addresses every 15 minutes. We conducted these scans from CU Boulder, between September 6 and November 7, 2023 for Wallbleed v1, and between March 28 and April 16, 2024 for Wallbleed v2.

Experiment results. Figure 10 shows the number of /24 subnets that responded to Wallbleed v1 probes in ZMap scans, as well as the hourly churn rate: the number of IP addresses that were responsive in one hour but not the next, or vice versa. We aggregated responding IP addresses by hour to reduce false negatives caused by packet loss.

Fig. 10: We tracked the number of IPv4 /24 subnets that responded to Wallbleed v1 probes over time. We scanned 1,130,343 IP addresses (one per subnet) every 15 minutes between September 6 and November 7, 2023. We failed to collect data between September 17 and October 4, 2023. Wallbleed v1 was patched in two major stages: between September 6 and 14, 2023; and between October 22 and November 1, 2023.

There are some variations in the response rate leading up to October 23, when the Wallbleed vulnerability was patched over about a week. Starting on October 23, we observed discrete steps down in response rate as the vulnerability was progressively patched. The last three steps occurred on October 30 (Monday), October 31 (Tuesday), and November 1 (Wednesday) at the same time each day: between 10:00 and 12:00 (China Standard Time, UTC+8). After 12:00 on November 1, we no longer saw Wallbleed v1 responses for any IP addresses we scan. We examined the IP addresses that transitioned to unresponsive in the step on October 30. 86% of the 39 k addresses were part of a /20 subnet that no longer responded, indicating that the discrete steps corresponded to large blocks of IP addresses changing in tandem, rather than a more randomized, load-balancing style of update.

Wallbleed v2 was completely patched by March 28, 2024. Unfortunately, we only captured the last 60 minutes of the patching process, in four horizontal scans. Like Wallbleed v1, Wallbleed v2 was patched in discrete steps. We isolated the time of final patching of Wallbleed v2 to between 16:01:30 and 16:16:30 (China Standard Time, UTC+8) on March 28, 2024 (a different time of day than v1).

In the last one-hour capture, 42,084 IP addresses elicited Wallbleed v2 responses. Interestingly, 33,779 (80.3%) of these addresses belong to AS4538 (CERNET, the China Education and Research Network Center), along with a long tail of 49 ASes that belong to China Mobile and various universities in China. This observation supports the hypothesis that CERNET maintains a subset of the national GFW infrastructure. The DNS injector in CERNET had the Wallbleed v2 vulnerability in common with the rest of the GFW, suggesting unified management and coordinated patching. Meanwhile, its distinct patching schedule demonstrates a degree of independence in its operation and maintenance.

VIII. Related work

DNS injection by the Great Firewall is one of the oldest and most-studied forms of Internet censorship. The earliest documentation we know of is in two independent studies from 2002, one by Dong [39] and one by Zittrain and Edelman [40], both of which found that a single bogus IP address was used in all injected responses. In 2009, gfwrev discovered two types of DNS injector in China with distinct fingerprints, and documented another seven response IP addresses in addition to the one that had been used in 2002 [13]. In 2014, Anonymous et al. analyzed IP ID and TTL patterns in injected responses toinfer the existence of 367 separate injection processes, each injecting at a rate of between 0 and 60 fake DNS responses per second [7 §7]. The number of bogus IP addresses in use had grown to at least 174 by 2016 [41, 42]. Anonymous et al. distinguished the fingerprints of at least three DNS injectors in 2020 [8]. Large-scale measurements by Hoang et al. in 2021 showed that tracking changes in the GFW’s DNS domain blocklists can help in understanding censorship trends in China [9].

The past work that most resembles, and indeed inspires, our own is gfw-looking-glass.sh, a one-line shell script posted by klzgrad from gfwrev in 2010 [5, 6]. To the best of our knowledge, it was the first memory-dumping vulnerability in the GFW. DNS queries with a name truncated after the first byte of a 2-byte compression pointer caused the GFW’s DNS parser to treat nearby memory as part of the name, and leak it back in the injected response. This vulnerability was fixed prior to our discovery of Wallbleed. The script incidentally demonstrated that a query name containing an embedded dot character, 06 w u x . r u , was treated the same as one correctly split into separate labels, 03 w u x 02 r u , indicating that the GFW, at that time too, serialized the name to a dotted string before matching it against a blocklist, rather than matching on structured labels. In 2014, klzgrad found that the GFW’s DNS injector had ceased to interpret compression pointers, opening opportunities to evade DNS injection with queries that used pointers in unusual ways [43].

Wallbleed was independently discovered by Sakamoto and Wedwards in 2023 [44]. They analyzed the leaked data, inferred the characteristics of the GFW’s processes, and proposed several attacks leveraging this vulnerability. Apart from confirming their observations, we developed the study of Wallbleed further with longitudinal and Internet-wide measurements of more than two years since October 2021. We uncovered the root cause of Wallbleed, reconstructed the parsing logic in C code, used a novel side channel to identify individual processes in the vulnerable injector, examined affected IP addresses, and, after the first incomplete patch of November 2023, found the Wallbleed v2 vulnerability.

Wallbleed is named like other similar memory disclosure vulnerabilities. Heartbleed, a vulnerability in OpenSSL, allowed clients to leak up to 64 KB of a TLS server’s memory at a time [1]. Cloudbleed was a vulnerability in an HTML parser used on edge servers of the Cloudflare content delivery network in 2017 [3, 4]. Similarly, Ticketbleed documented a vulnerability in F5 middleboxes [2].

IX. Ethics

Three main ethical considerations arise in this research. The first is the handling of experimental data, such as what we collected over two years in our longitudinal experiment. If, as we contend, Wallbleed represented a privacy risk to the users whose traffic passed through vulnerable injectors, then the storage and analysis of leaked data require sensitivity and care. The second is whether, or under what circumstances, it is okay to exploit a security vulnerability in a system that may itself be regarded as a hostile network attacker [10, 11]—in this case the GFW. The third is how to approach disclosure.

A. Data handling

The experiment in Section V demonstrates that at least some of the data exposed by Wallbleed to third parties originated in traffic transiting the firewall. This presents a privacy concern: network traffic may contain sensitive information such as usernames, passwords, or web requests. We submitted our research plan to our institutional review board (IRB), which exempted the research as not involving human subjects. Below we detail our considerations and safeguards for this data.

Data collection. There is an unavoidable trade-off between reducing data collection and being able to do meaningful analysis. Once the Wallbleed vulnerability was understood, leaking a single byte would have been sufficient to confirm its presence, but such limited measurement would not have allowed us to study the firewall’s architecture or how Internet users were impacted. On-the-fly analysis of in-memory (rather than stored) data would have allowed us to report some results, but we would not have noticed and would not have been able to analyze unanticipated changes, such as the gradual disappearance of “digest” bytes in Section IV-B. We therefore focused on a strategy of protecting collected data, rather than artificially limiting what was collected. Ultimately, after discussion within our team and with reviewers, we decided to delete the collected data upon publication of this work.

B. Ethics of exploitation

Exploiting a bug of this nature is ethically complicated. From a deontological perspective [45 §4.1], security researchers might decide to avoid exploiting vulnerabilities in systems they do not control under any circumstances, as doing so may have unintended and negative impacts that are difficult to predict. Alternatively, from a consequentialist perspective [45 §4.1], one must weigh the benefits of research against its risk of harms.

We identify two high-level sources of potential harm and negative effects in our research: (1) the data we collected, which may contain sensitive information, could leak; and (2) the probes we sent may cause the GFW, or other middleboxes or end hosts, to crash or malfunction. We have discussed the first source of risks in Section Section IX-A. Below we discuss how we manage the second source of risks.

Given that the system we exploit is itself considered by many to be a source of harm [10, 11], even if our experiments result in damage to the GFW, it will essentially reduce harm to more than a billion people by hampering censorship. In particular, any crash of the GFW is unlikely to impede network traffic. Past research has shown that GFW DNS injectors are on-path devices [7, 8, 9, 12, 21, 39, 46, 47, 48]; that is, they work by getting a mirrored copy of traffic, and are not themselves a link in the transmission chain. Finally, prior work has exploited vulnerabilities in other harmful systems like botnets and middleboxes in order to study those problematic systems [29, 49, 50, 51, 52].

To minimize the risk of crashing other middleboxes and end hosts, we cautiously only sent traffic to hosts under our control during the first 18 months of experiments. Only after observing a lack of adverse effects did we start Internet-wide scans. Following best practices for Internet scanning [27], we limited the traffic volume to each host not under our control to only one UDP packet per 15 minutes. We hosted a web page at the source IP address of our scans, displaying a project description and explaining how to opt out of scanning. We received and honored one opt-out request in the course of the study.

C. Whether to disclose, and how

Disclosing a bug of this nature is also complicated. By reporting the vulnerability, are we ultimately “helping” the Great Firewall? There is also a trade-off to consider between immediate and delayed disclosure: remove the privacy risk to users now, or take time to gain a greater understanding of the censorship system, in order to perhaps avoid even greater risks and harm in the future?

We decided on a strategy of coordinated disclosure, but only after taking advantage of the opportunity occasioned by the vulnerability to learn as much about the DNS injection subsystem as possible. Two factors led us to the decision to eventually disclose. The first is the risk to the privacy of users. Once the unpatched bug was made public, it could be used by others who do not have regard for users’ safety. The second is that the Wallbleed vulnerability does not reduce the effectiveness of the DNS censorship system. With Wallbleed fixed, the injectors carry on interfering with connections as before, but they do not do more of it.

This ethical calculus is specific to this situation. Under other circumstances we might come to a different decision. If there were an implementation error in the Great Firewall that caused it to fail to censor some fraction of connections, and otherwise did not increase risk to users, we would not be obligated to report it. Our allegiance is not to bug-fixing in the abstract, but to the security of users. We maintain that the only correct fix for a bug like Wallbleed is the removal of affected devices (i.e., the GFW injectors) from the network: the real “bug” is their very presence, not in the specific implementation errors they undoubtedly have. The incomplete patch in November 2023 that led to the Wallbleed v2 variant reinforces the point: as long as the injectors exist, they will pose a risk to users.

In the end, our decision to disclose was made moot by the patching of the vulnerability, before we were able to report the issue to CNCERT. This paper, too, forms part of our disclosure strategy: documenting and publicizing this vulnerability will draw more attention to the many dangers of censorship.

X. Lesson learned for future work

Our study provides a unique case study of the balance between protecting user data and utility of research data in understanding a system. While in hindsight it is possible to see areas where we could have chosen to collect less data (and thus reduced the risk of collecting personal information), we note that it is difficult to know the optimal boundaries of unstructured data ahead of time. For instance, we learned of the 4-byte “digest bytes” feature by studying a large number of full payloads. In hindsight, we might still have discovered this feature of the GFW by leaking only 4 bytes, so it may appear unnecessary to collect more than that. But without knowledge of the nature of this feature ahead of time, it would be difficult to know that 4 bytes would be sufficient. Likewise, when choosing how many bytes to leak, we are faced with a difficult trade-off: leak more bytes at the risk of collecting personal data (but potentially learn more about a yet-unknown feature of the GFW), or leak fewer bytes at the risk of learning less (but limit the potential collection of sensitive data). This type of trade-off should be considered carefully for all work, and we hope that by documenting our thought process, we inspire further discussion and debate among the research community.

IRB decisions. We were asked to push back on our Institutional Review Board’s decision to mark our work as exempt, as reviewers felt that there were additional ethical considerations of our work not captured by that decision. We agree that our work has complex ethical considerations, but disagree that these considerations fall explicitly within the bounds of an IRB, or that authors should be required to push back on IRB decisions they disagree with.

We were transparent in the protocol we submitted to the IRB, including that the collected data may contain third-party network traffic. This is an excerpt from our submitted protocol:

“We have discovered that, in processing certain malformed DNS queries, the subsystem may include fragments of unrelated system memory in its injected response. In short, the firewall ‘leaks’ small fragments of memory, which may incidentally include other people’s network traffic that passes by the GFW. The discovery is significant both for network security and for understanding the Great Firewall. While the contents of the leaked memory are unpredictable, it is possible that they may contain personally identifiable information, such as IP addresses. Therefore, we are seeking the IRB’s guidance on how to proceed, and in particular, on whether this research requires full IRB review.”

We recognize that IRB exemption is not the same thing as the IRB making an ethical determination about the work, nor does it necessarily mean the IRB feels there is no potential harm or ethical considerations needed. Rather, an exemption means that the IRB has determined it does not fall within a narrow definition of “human subjects research” [53 § 219.102]. To this end, we treated the data we collected as sensitive, and have deleted it prior to publication as a precaution against potential abuse. Nonetheless, we feel it is important for our community to understand the limitations of IRBs, and to avoid using them as a stand-in for ethical decisions.

XI. Conclusion

In this work, we present and study Wallbleed, a buffer over-read vulnerability in the DNS injection subsystem of the Great Firewall of China (GFW). We conducted longitudinal and Internet-wide measurements to understand the cause and implications of Wallbleed. We also revealed details of the GFW’s internal architecture and operations that would not be possible to learn about without Wallbleed. Wallbleed exemplifies that the harm censorship middleboxes impose on Internet users goes even beyond the direct (and designed) harm of censorship: it can severely violate users’ privacy and confidentiality.

Availability

To encourage future research and promote transparency and reproducibility, we have made the code, anonymized data, and additional context about our work and publishing process publicly available. For improved accessibility, we offer both English and Chinese HTML versions of the paper. The project homepage is at: https://gfw.report/publications/ndss25/en.

Acknowledgments

We are deeply grateful to several colleagues who wish to remain unnamed for their valuable contributions and guidance throughout the entire project. We are also thankful to klzgrad from gfwrev for their inspiring pioneering work in 2010, and for providing rounds of thoughtful comments in this study. In addition, we thank Alberto Dainotti, Ali Zohaib, Cecylia Bocovich, Diogo Barradas, J. Alex Halderman, Jakub Dalek, Jeffrey Knockel, Michael Carl Tschantz, Nadia Heninger, Philipp Winter, ppmaootc, Prateek Mittal, Xiao Qiang, and Zakir Durumeric. We also thank the anonymous reviewers for their helpful comments and guidance.

References

Z. Durumeric, F. Li, J. Kasten, J. Amann, J. Beekman, M. Payer, N. Weaver, D. Adrian, V. Paxson, M. Bailey, and J. A. Halderman, “The matter of Heartbleed,” in Internet Measurement Conference. ACM, 2014. [Online]. Available: https://dl.acm.org/doi/10.1145/2663716.2663755.
F. Valsorda. (2016) Ticketbleed (CVE-2016-9244). [Online]. Available: https://filippo.io/Ticketbleed/.
J. Graham-Cumming. (2017, Feb.) Incident report on memory leak caused by Cloudflare parser bug. [Online]. Available: https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/.
M. Prince. (2017, Mar.) Quantifying the impact of “Cloudbleed”. [Online]. Available: https://blog.cloudflare.com/quantifying-the-impact-of-cloudbleed/.
gfwrev. (2010, Sep.) “gfw-looking-glass.sh: while true; do printf "\0\0\1\0\0\1\0\0\0\0\0\0\6wux.ru\300" | nc -uq1 $SOME_IP 53 | hd -s20; done”. [Online]. Available: https://twitter.com/gfwrev/status/25220534979/.
Anonymous. (2020, Mar.) GFW archaeology: gfw-looking-glass.sh. [Online]. Available: https://github.com/net4people/bbs/issues/25.
——, “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.
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.
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.
Internet Society. (2023, Dec.) When is the Internet not the Internet? [Online]. Available: https://www.internetsociety.org/resources/internet-fragmentation/the-chinese-firewall/.
D. Anderson, “Splinternet behind the Great Firewall of China: Once China opened its door to the world, it could not close it again,” Queue, vol. 10, no. 11, pp. 40–49, Nov. 2012. [Online]. Available: https://queue.acm.org/detail.cfm?id=2405036&doi=10.1145%2F2390756.2405036.
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.
gfwrev. (2009, Nov.) 深入理解GFW：DNS污染. [Online]. Available: https://gfwrev.blogspot.com/2009/11/gfwdns.html.
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.
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.
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.
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: https://github.com/net4people/bbs/issues/43.
A. Master and C. Garman, “A worldwide view of nation-state Internet censorship,” in Free and Open Communications on the Internet, 2023. [Online]. Available: https://www.petsymposium.org/foci/2023/foci-2023-0008.pdf.
S. Nourin, V. Tran, X. Jiang, K. Bock, N. Feamster, N. P. Hoang, and D. Levin, “Measuring and evading Turkmenistan’s internet censorship,” in The International World Wide Web Conference. ACM, 2023. [Online]. Available: https://dl.acm.org/doi/abs/10.1145/3543507.3583189.
P. Mockapetris, “Domain names - implementation and specification,” RFC 1035, Nov. 1987. [Online]. Available: https://www.rfc-editor.org/info/rfc1035.
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.
A. Bhaskar and P. Pearce, “Many roads lead to Rome: How packet headers influence DNS censorship measurement,” in USENIX Security Symposium. USENIX, 2022. [Online]. Available: https://www.usenix.org/system/files/sec22-bhaskar.pdf.
R. Moskowitz, D. Karrenberg, Y. Rekhter, E. Lear, and G. J. de Groot, “Address allocation for private Internets,” RFC 1918, Feb. 1996. [Online]. Available: https://www.rfc-editor.org/info/rfc1918.
hugsy, “Playing with canaries,” Jan. 2017. [Online]. Available: https://www.elttam.com/blog/playing-with-canaries/#glibc-analysis.
M. Phaedrus, “Some technical details behind the mundane Windows update,” 2022. [Online]. Available: https://great-computing.quora.com/Some-technical-details-behind-the-mundane-Windows-Update-https-www-quora-com-Does-the-Windows-update-use-HTTP-answer.
“MaxMind GeoLite2 geolocation database.” [Online]. Available: https://dev.maxmind.com/geoip/geolite2-free-geolocation-data.
Z. Durumeric, E. Wustrow, and J. A. Halderman, “ZMap: Fast Internet-wide scanning and its security applications,” in USENIX Security Symposium. USENIX, Aug. 2013. [Online]. Available: https://www.usenix.org/conference/usenixsecurity13/technical-sessions/paper/durumeric.
State Council of the People’s Republic of China, “互联网信息服务管理办法 (Measures for the Administration of Internet Information Services),” Sep. 2000. [Online]. Available: https://www.gov.cn/gongbao/content/2000/content_60531.htm.
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.
A. Alaraj, K. Bock, D. Levin, and E. Wustrow, “A global measurement of routing loops on the Internet,” in Passive and Active Measurement. Springer Nature Switzerland, 2023, pp. 373–399. [Online]. Available: https://link.springer.com/chapter/10.1007/978-3-031-28486-1_16.
“IP2Location LITE IP address geolocation database.” [Online]. Available: https://www.ip2location.com/database/ip2location.
CAIDA, “CAIDA AS to organization mapping dataset.” [Online]. Available: https://www.caida.org/catalog/datasets/request_user_info_forms/as_organizations/.
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.
Z. Weinberg, S. Cho, N. Christin, V. Sekar, and P. Gill, “How to catch when proxies lie: Verifying the physical locations of network proxies with active geolocation,” in Internet Measurement Conference. ACM, 2018. [Online]. Available: https://www.contrib.andrew.cmu.edu/~nicolasc/publications/Weinberg-IMC18.pdf.
“IPGeolocation.io IP geolocation API.” [Online]. Available: https://ipgeolocation.io/documentation/ip-geolocation-api.html.
Team Cymru, “Team Cymru IP to ASN lookup v1.0.” [Online]. Available: https://asn.cymru.com/.
Q. Lone. (2022, Apr.) Detecting DNS root manipulation. [Online]. Available: https://labs.ripe.net/author/qasim-lone/detecting-dns-root-manipulation/.
Y. Nosyk, Q. Lone, Y. Zhauniarovich, C. H. Gañán, E. Aben, G. C. M. Moura, S. Tajalizadehkhoob, A. Duda, and M. Korczy´nski, “Intercept and inject: DNS response manipulation in the wild,” in Passive and Active Measurement. Springer Nature Switzerland, 2023. [Online]. Available: https://link.springer.com/chapter/10.1007/978-3-031-28486-1_19.
B. Dong, “A report about national DNS spoofing in China on Sept. 28th,” Dynamic Internet Technology, Inc., Tech. Rep., Oct. 2002. [Online]. Available: https://web.archive.org/web/20021015121616/http://www.dit-inc.us/hj-09-02.html.
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.
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.
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/usenixsecurity17/sec17-pearce.pdf.
klzgrad. (2014, Nov.) DNS compression pointer mutation. [Online]. Available: https://gist.github.com/klzgrad/f124065c0616022b65e5.
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.
T. Kohno, Y. Acar, and W. Loh, “Ethical frameworks and computer security trolley problems: Foundations for conversations,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 5145–5162. [Online]. Available: https://securityethics.cs.washington.edu/.
M. C. Tschantz, S. Afroz, Anonymous, and V. Paxson, “SoK: Towards grounding censorship circumvention in empiricism,” in Symposium on Security & Privacy. IEEE, 2016. [Online]. Available: https://www.eecs.berkeley.edu/~sa499/papers/oakland2016.pdf.
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.
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.
B. Stone-Gross, M. Cova, L. Cavallaro, B. Gilbert, M. Szydlowski, R. Kemmerer, C. Kruegel, and G. Vigna, “Your botnet is my botnet: analysis of a botnet takeover,” in Proceedings of the 16th ACM conference on Computer and communications security, 2009, pp. 635–647. [Online]. Available: https://sites.cs.ucsb.edu/~chris/research/doc/ccs09_botnet.pdf.
A. Mirian, A. Ukani, I. Foster, G. Akiwate, T. Halicioglu, C. T. Moore, A. C. Snoeren, G. M. Voelker, and S. Savage, “In the line of fire: Risks of DPI-triggered data collection,” in Proceedings of the 16th Cyber Security Experimentation and Test Workshop, 2023, pp. 57–63. [Online]. Available: https://arianamirian.com/docs/cset2023_fireye.pdf.
C. Kanich, C. Kreibich, K. Levchenko, B. Enright, G. M. Voelker, V. Paxson, and S. Savage, “Spamalytics: An empirical analysis of spam marketing conversion,” in Proceedings of the 15th ACM conference on Computer and communications security, 2008, pp. 3–14. [Online]. Available: https://www.icir.org/christian/publications/2008-ccs-spamalytics.pdf.
K. 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.
U.S. Government, “Title 32 of the Code of Federal Regulations § 219.102: Definitions,” 2024. [Online]. Available: https://www.ecfr.gov/on/2024-11-27/title-32/subtitle-A/chapter-I/subchapter-M/part-219/section-219.102.

Appendix A An example ordered pool of fake IP address

Below are the ordered lists of 592 IPv4 and 30 IPv6 addresses used by the Wallbleed-affected DNS injectors when forging responses to A and AAAA queries, respectively, for the DNS name 4.tt. The pools for other injectors and other query names may differ [8 § 3.2] [9 § 5.2]. When an injector process injects a DNS response, it takes the next IP address from its ordered list, cycling back to the beginning after reaching the end. This fact becomes evident when collecting injected responses at a sufficiently high sample rate (around 100 packets per second or more). The selection of a “first” address in each cycle is arbitrary.

We put the ordered lists to two uses: in Section VI-C, to filter Wallbleed-related DNS responses from other responses; and in Section V-B, to isolate the multiple independent processes within each injector device. Machine-readable versions are included with the data published alongside this paper.

1): 208.77.47.172
2): 173.252.88.133
3): 173.252.88.67
4): 108.160.170.45
5): 157.240.10.32
6): 174.36.196.242
7): 174.36.228.136
8): 174.37.154.236
9): 174.37.175.229
10): 174.37.54.20
11): 185.60.216.11
12): 185.60.216.50
13): 199.16.158.12
14): 199.16.158.182
15): 199.16.158.8
16): 199.16.158.9
17): 199.59.148.96
18): 199.59.148.229
19): 199.59.148.20
20): 157.240.17.35
21): 31.13.94.37
22): 31.13.68.169
23): 31.13.88.26
24): 31.13.88.169
25): 31.13.94.36
26): 31.13.94.49
27): 31.13.94.41
28): 31.13.94.10
29): 31.13.73.169
30): 31.13.73.9
31): 31.13.112.9
32): 31.13.106.4
33): 31.13.96.195
34): 31.13.82.169
35): 31.13.86.21
36): 31.13.85.169
37): 31.13.85.53
38): 31.13.96.194
39): 31.13.96.208
40): 31.13.96.193
41): 31.13.96.192
42): 31.13.112.4
43): 31.13.80.169
44): 31.13.95.169
45): 104.244.43.136
46): 199.96.61.1
47): 104.244.43.52
48): 104.244.43.6
49): 157.240.0.18
50): 104.244.43.231
51): 104.244.43.35
52): 66.220.148.145
53): 31.13.95.34
54): 31.13.95.48
55): 173.252.105.21
56): 31.13.95.35
57): 157.240.0.35
58): 173.252.108.21
59): 157.240.11.40
60): 104.244.43.167
61): 199.59.150.39
62): 199.59.149.230
63): 199.59.149.208
64): 199.16.158.104
65): 199.16.156.38
66): 96.44.137.28
67): 69.50.221.20
68): 69.30.25.21
69): 69.197.153.180
70): 69.162.134.178
71): 65.49.26.99
72): 65.49.26.98
73): 65.49.26.97
74): 50.23.209.199
75): 199.59.150.45
76): 199.59.150.44
77): 199.59.150.43
78): 199.59.150.40
79): 199.59.150.13
80): 199.59.150.12
81): 199.59.149.239
82): 199.59.149.238
83): 199.59.149.237
84): 199.59.149.236
85): 199.59.149.235
86): 199.59.149.234
87): 199.59.149.232
88): 199.59.149.231
89): 199.59.149.210
90): 199.59.149.207
91): 199.59.149.206
92): 199.59.149.205
93): 199.59.149.203
94): 199.59.149.202
95): 199.59.149.201
96): 199.59.148.9
97): 199.59.148.89
98): 199.59.148.8
99): 199.59.148.7
100): 199.59.148.6
101): 199.59.148.247
102): 199.59.148.246
103): 199.59.148.222
104): 199.59.148.206
105): 199.59.148.202
106): 199.59.148.201
107): 199.59.148.15
108): 199.59.148.147
109): 199.59.148.106
110): 199.59.148.102
111): 199.16.156.75
112): 199.16.156.71
113): 199.16.156.39
114): 199.16.156.11
115): 199.16.156.103
116): 184.72.1.148
117): 182.50.139.56
118): 173.255.213.90
119): 173.255.209.47
120): 173.252.248.244
121): 173.236.212.42
122): 173.236.182.137
123): 173.234.53.168
124): 173.231.12.107
125): 173.208.182.68
126): 168.143.171.93
127): 168.143.171.189
128): 168.143.171.186
129): 168.143.171.154
130): 168.143.162.58
131): 168.143.162.42
132): 128.242.250.157
133): 128.242.250.155
134): 128.242.250.148
135): 128.242.245.93
136): 128.242.245.43
137): 128.242.245.29
138): 128.242.245.253
139): 128.242.245.244
140): 128.242.245.221
141): 128.242.245.212
142): 128.242.245.189
143): 128.242.245.180
144): 128.242.245.157
145): 128.242.245.125
146): 128.242.240.93
147): 128.242.240.61
148): 128.242.240.29
149): 128.242.240.253
150): 128.242.240.244
151): 128.242.240.221
152): 128.242.240.218
153): 128.242.240.212
154): 128.242.240.189
155): 128.242.240.180
156): 128.242.240.157
157): 128.242.240.125
158): 128.121.243.77
159): 128.121.243.76
160): 128.121.243.75
161): 128.121.243.107
162): 128.121.243.106
163): 122.248.226.57
164): 159.106.121.75
165): 59.24.3.173
166): 66.220.146.94
167): 66.220.147.11
168): 66.220.149.18
169): 66.220.149.32
170): 69.171.224.40
171): 69.171.227.37
172): 69.171.228.74
173): 69.171.229.11
174): 69.171.229.73
175): 69.171.234.48
176): 69.171.242.11
177): 69.171.247.32
178): 69.171.247.71
179): 69.63.176.143
180): 69.63.176.15
181): 69.63.176.59
182): 69.63.178.13
183): 69.63.180.173
184): 69.63.181.12
185): 69.63.184.14
186): 69.63.184.142
187): 69.63.184.30
188): 69.63.186.30
189): 69.63.186.31
190): 69.63.187.12
191): 69.63.190.26
192): 67.15.100.252
193): 67.15.129.210
194): 199.16.156.40
195): 199.16.156.7
196): 199.16.158.190
197): 199.59.148.209
198): 199.59.148.97
199): 199.59.149.136
200): 199.59.149.244
201): 199.59.150.49
202): 88.191.249.182
203): 88.191.249.183
204): 208.101.21.43
205): 208.101.60.87
206): 208.43.170.231
207): 208.43.237.140
208): 67.228.102.32
209): 67.228.235.91
210): 67.228.235.93
211): 74.86.118.24
212): 74.86.12.172
213): 74.86.12.173
214): 74.86.142.55
215): 74.86.151.162
216): 74.86.151.167
217): 74.86.17.48
218): 74.86.226.234
219): 74.86.228.110
220): 74.86.3.208
221): 75.126.115.192
222): 75.126.124.162
223): 75.126.135.131
224): 75.126.150.210
225): 75.126.164.178
226): 75.126.33.156
227): 205.186.152.122
228): 64.13.192.74
229): 64.13.192.76
230): 104.16.252.55
231): 104.16.251.55
232): 210.56.51.193
233): 23.234.30.58
234): 210.56.51.192
235): 202.53.137.209
236): 156.233.67.243
237): 154.85.102.32
238): 154.92.16.97
239): 154.83.15.20
240): 154.85.102.30
241): 154.83.15.45
242): 154.83.14.134
243): 103.214.168.106
244): 150.107.3.176
245): 103.97.176.73
246): 103.73.161.52
247): 103.200.31.172
248): 52.175.9.80
249): 159.65.107.38
250): 59.188.250.54
251): 4.78.139.50
252): 93.179.102.140
253): 148.163.48.215
254): 54.89.135.129
255): 4.78.139.54
256): 23.101.24.70
257): 199.193.116.105
258): 162.220.12.226
259): 98.159.108.61
260): 50.87.93.246
261): 47.88.58.234
262): 98.159.108.58
263): 67.230.169.182
264): 159.138.20.20
265): 124.11.210.175
266): 98.159.108.57
267): 111.243.214.169
268): 103.42.176.244
269): 210.209.84.142
270): 107.181.166.244
271): 98.159.108.71
272): 23.225.141.210
273): 114.43.24.59
274): 45.77.186.255
275): 202.182.98.125
276): 45.114.11.25
277): 203.111.254.117
278): 103.240.180.117
279): 45.114.11.238
280): 43.226.16.8
281): 116.89.243.8
282): 80.87.199.46
283): 198.27.124.186
284): 39.109.122.128
285): 103.228.130.27
286): 118.107.180.216
287): 103.97.3.19
288): 103.56.16.112
289): 115.126.100.160
290): 118.193.202.219
291): 118.184.78.78
292): 118.193.240.41
293): 118.184.26.113
294): 103.39.76.66
295): 103.240.182.55
296): 103.230.123.190
297): 103.246.246.144
298): 103.200.30.143
299): 118.193.240.37
300): 198.44.185.131
301): 211.104.160.39
302): 103.228.130.61
303): 122.10.85.4
304): 103.226.246.99
305): 208.31.254.33
306): 50.117.117.42
307): 157.240.15.8
308): 157.240.13.8
309): 157.240.1.33
310): 157.240.12.5
311): 31.13.87.34
312): 31.13.91.33
313): 31.13.90.33
314): 31.13.87.33
315): 31.13.90.19
316): 31.13.95.18
317): 31.13.87.19
318): 31.13.83.34
319): 31.13.84.34
320): 31.13.85.34
321): 31.13.82.33
322): 31.13.76.99
323): 31.13.76.65
324): 31.13.75.12
325): 31.13.71.19
326): 31.13.70.33
327): 157.240.7.5
328): 31.13.70.13
329): 31.13.67.33
330): 157.240.7.8
331): 31.13.92.5
332): 31.13.91.6
333): 31.13.84.2
334): 31.13.87.9
335): 31.13.83.2
336): 31.13.85.2
337): 31.13.75.5
338): 31.13.70.9
339): 104.244.43.57
340): 199.59.149.204
341): 202.160.128.16
342): 199.96.58.15
343): 185.45.6.103
344): 202.160.128.203
345): 104.244.46.165
346): 199.96.63.177
347): 103.252.115.53
348): 104.244.46.17
349): 202.160.128.210
350): 104.244.46.211
351): 202.160.130.52
352): 104.244.46.5
353): 199.96.59.19
354): 104.244.46.85
355): 202.160.129.6
356): 103.252.114.101
357): 103.252.115.59
358): 103.252.115.49
359): 199.96.63.53
360): 192.133.77.197
361): 199.96.62.41
362): 104.244.43.234
363): 202.160.128.40
364): 202.160.128.96
365): 192.133.77.189
366): 202.160.128.14
367): 199.96.59.95
368): 104.244.43.104
369): 192.133.77.191
370): 192.133.77.145
371): 104.244.46.57
372): 185.45.7.185
373): 104.244.46.208
374): 104.244.46.186
375): 104.244.43.208
376): 103.252.114.11
377): 202.160.129.37
378): 199.96.62.75
379): 199.96.58.85
380): 104.244.46.185
381): 185.45.7.97
382): 104.244.46.93
383): 104.244.43.229
384): 104.244.43.182
385): 202.160.128.195
386): 185.45.6.57
387): 199.96.63.163
388): 199.96.58.177
389): 199.96.59.61
390): 199.96.63.75
391): 104.244.46.9
392): 202.160.128.238
393): 104.244.46.21
394): 103.252.115.153
395): 199.96.58.157
396): 192.133.77.59
397): 202.160.128.205
398): 199.96.62.21
399): 202.160.130.118
400): 104.244.43.228
401): 202.160.130.66
402): 185.45.7.189
403): 192.133.77.133
404): 185.45.7.165
405): 202.160.130.145
406): 104.244.43.128
407): 202.160.129.36
408): 103.252.115.221
409): 103.252.114.61
410): 199.96.58.105
411): 103.252.115.169
412): 104.244.46.246
413): 104.244.43.248
414): 104.244.46.63
415): 202.160.130.117
416): 104.244.46.52
417): 199.96.62.17
418): 202.160.129.164
419): 179.60.193.16
420): 157.240.3.50
421): 157.240.16.50
422): 157.240.2.50
423): 185.60.218.50
424): 162.125.83.1
425): 162.125.6.1
426): 162.125.8.1
427): 31.13.95.17
428): 157.240.17.14
429): 157.240.2.36
430): 185.60.216.36
431): 185.60.219.36
432): 157.240.2.14
433): 185.60.216.169
434): 157.240.8.50
435): 157.240.8.41
436): 157.240.3.8
437): 185.60.219.41
438): 157.240.12.50
439): 31.13.95.38
440): 31.13.81.4
441): 31.13.67.19
442): 157.240.6.35
443): 31.13.94.7
444): 157.240.20.18
445): 179.60.193.9
446): 31.13.94.23
447): 31.13.80.54
448): 31.13.69.169
449): 31.13.67.41
450): 31.13.64.7
451): 157.240.21.9
452): 157.240.20.8
453): 157.240.17.41
454): 157.240.18.18
455): 157.240.10.41
456): 157.240.1.50
457): 157.240.12.35
458): 157.240.1.9
459): 173.244.217.42
460): 173.244.209.150
461): 209.95.56.60
462): 31.13.95.37
463): 31.13.80.37
464): 157.240.8.36
465): 157.240.9.36
466): 157.240.17.36
467): 157.240.12.36
468): 157.240.10.36
469): 173.252.108.3
470): 31.13.69.245
471): 104.244.46.244
472): 104.244.45.246
473): 104.244.46.71
474): 162.125.32.6
475): 162.125.18.129
476): 162.125.80.5
477): 162.125.32.10
478): 162.125.17.131
479): 162.125.32.15
480): 162.125.2.6
481): 162.125.80.6
482): 162.125.80.3
483): 162.125.2.3
484): 162.125.34.133
485): 162.125.32.12
486): 162.125.1.8
487): 162.125.18.133
488): 162.125.32.2
489): 162.125.2.5
490): 162.125.32.5
491): 162.125.32.13
492): 162.125.32.9
493): 162.125.82.7
494): 162.125.7.1
495): 119.28.87.227
496): 31.13.95.33
497): 104.23.124.189
498): 104.23.125.189
499): 130.211.15.150
500): 104.31.142.88
501): 38.121.72.166
502): 65.49.68.152
503): 204.79.197.217
504): 54.234.18.200
505): 52.58.1.161
506): 184.173.136.86
507): 174.37.243.85
508): 69.171.224.36
509): 108.160.161.20
510): 108.160.161.83
511): 108.160.162.104
512): 108.160.162.102
513): 108.160.162.109
514): 108.160.162.115
515): 108.160.163.106
516): 108.160.162.98
517): 108.160.162.31
518): 108.160.163.102
519): 108.160.163.112
520): 108.160.163.108
521): 108.160.163.116
522): 108.160.163.117
523): 108.160.165.147
524): 108.160.165.11
525): 108.160.165.139
526): 108.160.165.141
527): 108.160.165.211
528): 108.160.165.173
529): 108.160.165.212
530): 108.160.165.189
531): 108.160.165.48
532): 108.160.165.53
533): 108.160.165.62
534): 108.160.165.8
535): 108.160.165.9
536): 108.160.166.137
537): 108.160.166.253
538): 108.160.166.61
539): 108.160.166.148
540): 108.160.166.42
541): 108.160.166.142
542): 108.160.167.147
543): 108.160.166.49
544): 108.160.166.57
545): 108.160.166.62
546): 108.160.166.9
547): 108.160.167.30
548): 108.160.167.156
549): 108.160.167.148
550): 108.160.167.165
551): 108.160.167.158
552): 108.160.169.171
553): 108.160.167.159
554): 108.160.167.167
555): 108.160.167.174
556): 108.160.169.178
557): 108.160.169.175
558): 108.160.169.174
559): 108.160.169.179
560): 108.160.169.181
561): 108.160.170.39
562): 108.160.170.33
563): 108.160.169.37
564): 108.160.169.185
565): 108.160.169.186
566): 108.160.169.46
567): 108.160.169.55
568): 108.160.169.54
569): 108.160.170.26
570): 108.160.170.41
571): 108.160.170.43
572): 108.160.170.44
573): 108.160.172.1
574): 108.160.170.52
575): 128.121.146.101
576): 108.160.172.200
577): 108.160.172.232
578): 108.160.172.208
579): 108.160.172.204
580): 108.160.173.207
581): 128.121.146.235
582): 128.121.243.228
583): 128.121.146.109
584): 128.121.146.228
585): 128.242.240.20
586): 128.242.240.59
587): 128.121.243.235
588): 128.242.240.117
589): 128.242.240.155
590): 128.242.240.149
591): 128.242.240.85
592): 128.242.240.91

Every entry in the IPv6 pool contains the pattern ‘face:b00c’, which is characteristic of genuine IP addresses of facebook.com. The GFW’s use of well-known addresses of Internet companies has been noted in the past [8 §3.2], [9 §5.1].

1): 2a03:2880:f130:0083:face:b00c:0:25de
2): 2a03:2880:f12c:0083:face:b00c:0:25de
3): 2a03:2880:f12c:0183:face:b00c:0:25de
4): 2a03:2880:f127:0083:face:b00c:0:25de
5): 2a03:2880:f126:0083:face:b00c:0:25de
6): 2a03:2880:f129:0083:face:b00c:0:25de
7): 2a03:2880:f12a:0083:face:b00c:0:25de
8): 2a03:2880:f11f:0083:face:b00c:0:25de
9): 2a03:2880:f127:0283:face:b00c:0:25de
10): 2a03:2880:f11c:8083:face:b00c:0:25de
11): 2a03:2880:f11c:8183:face:b00c:0:25de
12): 2a03:2880:f11b:0083:face:b00c:0:25de
13): 2a03:2880:f11a:0083:face:b00c:0:25de
14): 2a03:2880:f10e:0083:face:b00c:0:25de
15): 2a03:2880:f117:0083:face:b00c:0:25de
16): 2a03:2880:f10c:0083:face:b00c:0:25de
17): 2a03:2880:f112:0083:face:b00c:0:25de
18): 2a03:2880:f111:0083:face:b00c:0:25de
19): 2a03:2880:f10f:0083:face:b00c:0:25de
20): 2a03:2880:f10d:0083:face:b00c:0:25de
21): 2a03:2880:f10d:0183:face:b00c:0:25de
22): 2a03:2880:f10c:0283:face:b00c:0:25de
23): 2a03:2880:f10a:0083:face:b00c:0:25de
24): 2a03:2880:f102:0183:face:b00c:0:25de
25): 2a03:2880:f107:0083:face:b00c:0:25de
26): 2a03:2880:f134:0083:face:b00c:0:25de
27): 2a03:2880:f136:0083:face:b00c:0:25de
28): 2a03:2880:f12d:0083:face:b00c:0:25de
29): 2a03:2880:f134:0183:face:b00c:0:25de
30): 2a03:2880:f131:0083:face:b00c:0:25de

Appendix B Reverse-engineered DNS parsing and injection algorithm

The below C code is our attempt to reverse-engineer the faulty DNS query processing algorithm that caused Wallbleed. It reproduces the behavior of the DNS injectors affected by Wallbleed in all important respects. If PATCHED is false, the code implements the Wallbleed v1 vulnerability; if true, the partially patched Wallbleed v2 (see Section III-C and Section VII).

Having observed a DNS query and copied it to memory, the injection device parses out the QNAME to decide whether the query is one to be censored, and prepares a response if so. There are several bugs, the most significant of which is a failure to bounds-check DNS name label lengths against the message size.

 1// Check if msg is a DNS query for a name that should be censored.
 2// If so, change msg into a response in place and return the length
 3// of the response. If not, return 0.
 4size_t response(unsigned char *msg, size_t msg_len)
 5{
 6    if (msg_len < 12 || (msg[2] & 0x80) != 0)No response if message is too short or not a query.
 7        return 0;
 8
 9    char qname[126];The dot-delimited, null-terminated representation of 
 QNAME will be stored in qname.
10    size_t qname_i = 0;
11    // QNAME parsing loop.
12    size_t msg_i = 12;msg_ptr is meant to track msg_i and point just past 
 QNAME at the end of the loop.
13    unsigned char *msg_ptr;
14    for (;;) {
15        size_t label_len = msg[msg_i++];Bug: no check that msg_i is in bounds.
16        msg_ptr = &msg[msg_i];Sync msg_ptr with msg_i.
17
18        if (label_len == 0)Exit condition 1: an empty label.
19            break;
20        if (msg_i > msg_len)Exit condition 2: the label length prefix just parsed 
 was outside the end message bounds.
21            break;
22
23#if !PATCHED
24        if (qname_i + 1 > 124)Exit condition 3: not enough room for at least one 
 byte of label (with a dot and a null terminator). 
 Append a dot to qname, except before the first label.
25            break;
26#else
27        msg_i += MIN(label_len, 124 - qname_i);Take as much of the label as will fit, leaving room for 
 a dot and a null terminator.
28
29        if (qname_i + label_len > 124)Exit condition 4: label too long to fit in qname. 
 Bug: msg_ptr ≠ msg + msg_i in this case.
30            break;
31#endif
32
33        if (qname_i > 0)Append a dot to qname, if not the first label.
34            qname[qname_i++] = ’.’;
35        size_t n = MIN(label_len, 125 - qname_i);Copy as much of the label as will fit in qname. 
 Bug: no check that msg_ptr + n is in bounds.
36        memcpy(qname + qname_i, msg_ptr, n);
37        qname_i += n;
38#if !PATCHED
39        msg_i += n;
40        if (n < label_len)Exit condition 4: label too long to fit in qname. 
 Bug: qname_ptr ≠ msg_ptr in this case.
41            break;
42#endif
43    }
44    qname[qname_i] = ’\0’;Null-terminate the dot-delimited name string.
45
46    if (!name_matches_blocklist(qname))Does the extracted QNAME string match the blocklist? 
 If not, do not send a response.
47        return 0;
48
49    // Read QTYPE.
50    uint16_t qtype  = ntohs(*(uint16_t *) msg_ptr);msg_ptr may not agree with msg_i here.
51#if PATCHED
52    // Read QCLASS, enforce QCLASS == 1.
53    uint16_t qclass = ntohs(*(uint16_t *) (msg_ptr + 2));
54    if (qclass != 1)
55        return 0;
56#endif
57    // Change the query into a response.
58    size_t resp_len = msg_i + 4;Add 4 bytes for the query’s QTYPE and QCLASS.
59    if ((msg[2] & 0x01) == 0)If the RD flag was not set in the query, set AD in the 
 response.
60        *(uint16_t *) &msg[2] = htons(0x8400);
61    elseIf RD was set in the query, set RD and RA in the 
 response.
62        *(uint16_t *) &msg[2] = htons(0x8180);
63    *(uint16_t *) &msg[ 4] = htons(1);QDCOUNT = 1
64    *(uint16_t *) &msg[ 6] = htons(1);ANCOUNT = 1
65    *(uint16_t *) &msg[ 8] = htons(0);NSCOUNT = 0
66    *(uint16_t *) &msg[10] = htons(0);ARCOUNT = 0
67    // Append an answer section according to QTYPE.
68    const unsigned char *rdata;
69    uint32_t rdlength;
70    if (qtype == 28) {Type AAAA queries get a type AAAA response.
71        rdlength = 16;
72        rdata = next_aaaa_address();Get the next IPv6 address from the cyclic pool.
73    } else {All other QTYPEs get a type A response.
74        qtype = 1;
75        rdlength = 4;
76        rdata = next_a_address();Get the next IPv4 address from the cyclic pool.
77    }
78    uint32_t ttl = rand_in_range(64, 254);TTL is random between 64 and 254 inclusive.
79    unsigned char rr[] = {Construct a resource record.
80        0xc0, 0x0c, // NAMECompression pointer pointing back to QNAME.
81        0, 0,      // TYPE placeholder
82        0x00, 0x01, // CLASS = IN
83        0, 0, 0, 0, // TTL placeholder
84        0, 0,      // RDLENGTH placeholder
85    };
86    *(uint16_t *) &rr[ 2] = htons(qtype);Set QTYPE.
87    *(uint32_t *) &rr[ 6] = htonl(ttl);Set TTL.
88    *(uint16_t *) &rr[10] = htons(rdlength);Set RDLENGTH.
89    memcpy(msg + resp_len, rr, sizeof(rr));Append the resource record up to RDATA.
90    resp_len += sizeof(rr);
91    memcpy(msg + resp_len, rdata, rdlength);Append the RDATA (the false IP address).
92    resp_len += rdlength;
93
94    return resp_len;This query gets an injected response.
95}

We do not know exactly how a packet payload arrives in memory after being observed. It may be, for example, a software copy, or an automatic DMA transfer from the network interface. However it happens, a few minor peculiarities of the DNS injectors’ behavior are best explained as artifacts of how packets are copied into memory. These are: that the 18th byte of the memory buffer is always zero footnote 3; that at one time, the first 4 bytes of leaked memory were different from the others (“digest” bytes, Section IV-B); and that the msg_len limit in the response function above comes from the UDP header, not the number of bytes actually available in the packet (when those quantities differ).

 1// Copy an observed UDP packet payload to memory for analysis and
 2// possible modification, and inject a response if it is a DNS
 3// query for a name on the blocklist. hdr_len is the size of the
 4// payload in the UDP header (not counting the header itself).
 5void udp_packet_callback(const void *data, size_t data_len, size_t hdr_len)
 6{
 7    data_len = MIN(data_len, hdr_len);Trim packet payload to the size in the header.
 8    void *work = allocate_memory(hdr_len + 28);Memory for the query and a response record.
 9    memset(work, 0x00, 18);Clear the beginning of the buffer; see footnote 3.
10    memcpy(work, data, data_len);Copy the packet to working memory. The copy uses 
 data_len, but parsing uses hdr_len.
11
12    if (USE_DIGEST)“Digest” bytes (Section IV-B), when present, are just 
 after the query. We are using a fixed byte pattern.
13        memset(work + data_len, ’D’, 4);
14    size_t resp_len = response(work, hdr_len);Is this packet a DNS query that needs a response?
15    if (resp_len > 0)If so, inject the response. We are omitting details of 
 spoofing the source address, etc.
16        inject(work, resp_len);
17    free_memory(work);
18}

Wallbleed（墙出血）：中国防火长城中的内存数据泄露漏洞

Tue, 25 Feb 2025 00:00:00 +0000

Wallbleed（墙出血）：中国防火长城中的内存数据泄露漏洞

Shencha Fan

GFW Report

gfw.report@protonmail.com

Jackson Sippe

University of Colorado Boulder

Jackson.Sippe@colorado.edu

Sakamoto San

Shinonome Lab

54k4m070@proton.me

Jade Sheffey

University of Massachusetts Amherst

jsheffey@cs.umass.edu

David Fifield

david@bamsoftware.com

Amir Houmansadr

University of Massachusetts Amherst

amir@cs.umass.edu

Elson Wedwards

ElsonWedwards@proton.me

Eric Wustrow

University of Colorado Boulder

ewust@colorado.edu

摘要

我们发现了一个名为Wallbleed（墙出血）的缓冲区过度读取漏洞，该漏洞存在于中国防火长城（GFW）的DNS注入子系统中。Wallbleed导致某些影响全国范围的审查设备在处理特制的DNS请求时会泄露至多125字节的内存数据。这一漏洞为我们提供了一个难得的机会，以深入了解防火长城最著名的网络攻击手段之一——DNS注入——的内部架构，以及审查者的操作行为。

为了理解Wallbleed的形成原因和影响，我们从2021年10月开始进行了为期两年的持续性、全网范围的测量。我们（1）逆向工程了DNS注入器的解析逻辑，（2）评估了哪些信息被泄露以及中国国内和海外的互联网用户受到何种影响，并且（3）实时监测审查者的修补行为。我们识别出可能来自审查系统内部的流量，分析了审查系统的内存管理和负载均衡机制，并观察到注入节点的进程级变化。为了协助分析，我们还利用了一个新的旁路信道来区分注入器的不同进程。我们的监测显示审查者在2023年11月对Wallbleed进行了一次不正确的修补，并在2024年3月完成了彻底修复。

Wallbleed漏洞例证了审查设备对互联网用户造成的危害不仅在于其对言论自由的明显侵犯。如果实现不当，审查设备还会对互联网用户的隐私和保密性构成严重威胁。

I. 引言

中国的国家互联网审查系统，通称为防火长城（GFW），由多个部分和子系统组成，每个部分都采用不同的技术来控制对在线信息的访问。其中一个主要组成部分是DNS注入子系统，该系统伪造对被审查域名的DNS查询响应。直到2024年3月，某些DNS注入设备一直存在一个解析漏洞，该漏洞在特定条件下能使发送的伪造DNS响应包含多达125字节的设备内存。我们将这一漏洞称为Wallbleed，以此向类似的缓冲区过度读取漏洞如Heartbleed [1]，Ticketbleed [2]和Cloudbleed [3, 4]致敬。

在本研究中，¹我们分析了Wallbleed的成因和影响。我们的研究证实Wallbleed至少存在了两年。（类似漏洞的报告最早可追溯到2010年[5], [6]）。我们在2021年10月至2024年4月期间进行了持续监测。该漏洞在2023年11月得到部分修补，但DNS注入器仍然容易受到某些特制查询的攻击，直到2024年3月漏洞才得到彻底修复。

¹ 项目主页：https://gfw.report/publications/ndss25/en/.

Wallbleed为我们提供了前所未有的机会来了解防火长城（GFW），包括其内部架构和审查者的操作行为。虽然先前的研究已经探讨了中国封锁了哪些域名和资源，但对防火长城网络中间设备的内部运作机制知之甚少[7, 8, 9]。通过分析Wallbleed泄露的数据，我们能够辨识防火长城的底层架构，我们还逆向工程了导致Wallbleed的解析漏洞，用C语言创建了一个行为完全相同的实现。在研究过程中，我们发现了防火长城DNS注入的一些此前未知特征，例如每个注入进程都独立地按固定顺序循环使用一个虚假IP地址列表，这构成了一个可以区分注入器节点中多个进程的旁路信道。最后，我们进行了长期的、全网范围的测量来监控审查者的修补活动，以利用这个难得的机会来深入了解审查者如何维护防火长城。

我们检查了Wallbleed泄露的内存内容，发现了明显的网络协议头、载荷数据、x86_64栈帧和可执行代码（尽管我们提供了证据表明这不是防火长城本身的代码）。我们发送了带有可识别字节模式的流量，让其通过防火长城，并在某些情况下在后续的Wallbleed响应中找到了这些标记。这一观察证明了该漏洞泄露的数据中至少包含了一些被防火长城看到的流量。在Wallbleed泄露的内存中，我们看到了明文网络流量和协议的样本，包括IP、TCP、UDP和HTTP，并非所有泄漏的流量都与DNS审查有关。我们还进行了全IPv4范围的扫描，以估计中国内外可能有多少IP地址的流量被带有Wallbleed漏洞的审查设备处理。我们发现，即使是源IP地址和目标IP地址都在中国之外的某些流量也可能受到影响，因为这些流量通过中国的网络边界进行路由。

进行此类研究伴随着重大的伦理考量。我们在第IX节中对此进行了深入讨论。讨论的内容包括了是否应披露一个存在于被许多人视为有害系统的漏洞[10, 11]。注入伪造的DNS响应是防火长城每天进行的众多持续性网络攻击中的一种。这些攻击的意图和效果是众所周知的：限制人们获取信息。Wallbleed可以作为一个例子，说明审查设备不仅明显侵犯言论自由，而且还会带来安全和隐私风险。虽然这个特定的漏洞最终得到了修复，但只要此类设备存在，就仍然还是一个隐患。

II. 背景

A. DNS注入攻击

GFW的DNS注入子系统是部署在中国的网络边界的一系列中间设备，这些设备监控对被封锁域名的DNS查询。当它们检测到这样的查询时，会注入一个DNS响应返回给客户端，伪造源地址，使其看似来自预期的DNS解析服务器。注入的响应是对查询的错误回答，包含一个错误且无用的IP地址。当客户端随后尝试连接到该IP地址时，它不会连接到预期的目标服务器，而是会遇到错误。这些注入的中间设备是“旁路（on-path）”设备，而非“直通（in-path）”设备：它们不会阻止查询到达合法的DNS解析器服务器，也不会阻止真实的响应到达客户端。但由于注入的伪造响应会更快到达客户端（因为它们的注入地点在网络路径中比真正的解析服务器更靠近客户端），所以其抢答会“胜出” [12]。在正常情况下，每个查询仅预期接收一个DNS响应，因此客户端会接受最先收到的响应。

DNS注入子系统是双向的：它对离开中国或进入中国的查询都做出响应。这一特性为分析该系统提供了便利：相比于在中国境内获取和维护一个网络观察点，从外部向中国发送数据包要容易得多。通过向中国境内的非活动IP地址发送DNS查询，我们可以确保收到的任何响应都是中间设备伪造的，而非终端主机的真实回复。

正如GFW由不同的组件组成，DNS注入也是由至少三种不同类型的DNS注入器完成的。关于DNS注入这个主题的基础研究包括2009年gfwrev的工作[13]，2014年Anonymous的工作[7]，2020年Anonymous等人的“三重审查(Triplet censors)”[8]，以及2021年Hoang等人的“防火长城有多强大？（How great is the Great Firewall?）”[9]。不同类型的注入器在封锁列表、IP和DNS层的网络指纹以及解析逻辑的特性上均有所不同。Wallbleed漏洞仅存在于其中一种注入器中，即Anonymous等人称为“3号注入器”("Injector 3")的那种[8 §4.1]。

DNS注入长期以来一直是GFW的主要技术之一。但仅仅绕过它是不够的，因为还有其他审查系统在运作。即使客户端能够通过某种方式获得正确的DNS响应，其通信仍可能被其他审查方式阻断，例如IP地址过滤[14 §4.1]，TLS SNI过滤[14, 15, 16]或TLS ESNI过滤[14, 17]。在本文中，我们只关注DNS注入，并且只关注这一种DNS注入器。

中国政府并不是唯一使用DNS注入进行审查的国家。例如，请参阅Master和Garman在2023年调查中的表1“DNS篡改”一栏[18]，以及Nourin等人对土库曼斯坦的审查设备对DNS和其他协议进行双向注入的研究[19]。

B. DNS消息的格式

由于Wallbleed漏洞源于低级别的解析错误，了解DNS消息在传输线和内存中的表示方式将非常重要。DNS消息的格式在RFC 1035中指定[20]。查询和响应具有相同的基本格式：一个12字节的头部，后跟四个可变长度的部分：问题（question）、答案（answer）、授权（authority）和附加（additional）。我们将只关注问题（question）和答案（answer）部分。问题（question）部分包含被查询的DNS名称（或在响应中，响应所针对的名称）。答案（answer）部分仅在响应中存在，包含查询请求的信息（通常是一个IP地址），以一种称为resource record（资源记录）的数据结构表示。

图1是一个注入的DNS响应示例。它展示了理解本研究中出现的DNS消息所需的一切。我们将一致地使用这些字段名称和背景颜色。

1234 ID
8180 flags
0001 QDCOUNT
0001 ANCOUNT
0000 NSCOUNT
0000 ARCOUNT
03 r s f 03 o r g 00 QNAME
0001 QTYPE (A, IPv4 address)
0001 QCLASS (IN)
c00c NAME (pointer to QNAME)
0001 TYPE (A, IPv4 address)
0001 CLASS (IN)
000000ec TTL (236 seconds)
0004 RDLENGTH
1f0d 5b 21 RDATA (31.13.91.33)

Fig. 1: The structure of an injected DNS response.

该消息是一个DNS响应（而不是查询），这可以通过标志的最高有效位被设置来识别。它有一个问题（question）和一个答案（answer）；授权（authority）和附加（additional）部分是空的。问题（question）部分中的QNAME是DNS客户端请求解析的名称，rsf.org。答案（answer）部分由GFW注入器构建。它声称客户端的QNAME解析为一个不正确的IPv4地址（注入器可能使用的数百个地址之一）。

最重要的是理解DNS名称的编码。名称在DNS协议中无处不在：每个问题（question）部分（QNAME字段）中都有一个，且每个资源记录（NAME字段）中至少有一个。名称是标签的序列。标签是字节的序列，以一个字节的长度前缀。名称在一个空标签处结束，即仅由长度前缀00组成。名称example.com 有三个标签，分别为7、3和0字节。其编码长度为13字节：07 e x a m p l e 03 c o m00。

名称长度前缀编码有一个例外。如果长度前缀的两个最高有效位被设置，那么该字节的其他6位和下一个字节的8位形成一个14位的压缩指针，指示名称中剩余的标签从消息中的给定字节偏移开始。消息压缩很有用，因为DNS消息中通常包含多次相同的名称，或几个具有共同后缀的名称。压缩指针模式 c00c是一个需要识别的模式。它指向字节偏移12，即问题（question）部分的QNAME字段的偏移量。Wallbleed易受攻击的注入器不会将QNAME复制到答案（answer）部分，而是用一个 c00c压缩指针开始答案（answer）部分。（使用压缩指针并不是GFW独有的；合法的解析器也会使用它们。在GFW中存在的各种DNS注入器中，有些使用 c00c，有些则复制QNAME[8 §4.1]。）

DNS名称的格式，带有长度前缀和指针间接，容易导致解析器的内存安全错误。在处理标签长度前缀时，必须检查标签的结尾是否在消息的边界内。缺乏这样的检查是Wallbleed溢出漏洞的根本原因。

III. 演示溢出

这是一个格式良好的查询，其QNAME，rsf.org，在GFW的封锁列表上：

1234 0100 0001 0000 0000 0000 03 r s f 03 o r g 00 0001 0001

如果我们将这些字节通过UDP数据报发送到目的端口53，从中国境外的主机发送到中国境内的主机，我们会收到一个注入的DNS响应。（实际上会收到多个响应，因为这个QNAME在多种注入器的封锁列表上。）任何中国境内的目标IP地址都可以，即使是一个无响应的地址——查询只需经过一个在途的注入中间设备即可。

一个注入的响应如下所示（这是图1的更紧凑形式）：

1234 8180 0001 0001 0000 0000 03 r s f 03 o r g 00 0001 0001 c00c 0001 0001 000000ec 0004 1f 0d 5b 21

ID和问题（question）部分是从查询中复制的。标志已设置为适合响应。答案（answer）部分错误地声称名称rsf.org （由压缩指针 c00c表示）解析为IPv4地址31.13.91.33（1f0d 5b 21 ）。如附录A中详细说明的，这个假地址是注入器可能使用的众多地址之一。如果我们再次发送查询，可能会得到不同的地址。

现在看看如果我们人为地将org 标签的长度前缀从03（3）增加到20（32）会发生什么：

1234 0100 0001 0000 0000 0000 03 r s f 20 o r g 00 0001 0001

首先，我们现在只得到一个注入的响应：格式错误的查询被Wallbleed以外的注入器忽略。答案部分的TTL和IP地址与之前不同，这是预期的：这些通常在每个响应中都会变化。更重要的是，注入的响应在答案部分之前包含29个额外字节。这些字节来自处理查询的注入设备的内存。在这个例子中，泄露的字节是一个UPnP HTTP头的片段：

12348180 0001 0001 0000 0000 03 r s f 20 o r g 00 0001 0001 C u s t o m / 1 . 0 U P n P / 1 . 0 P r o c / V e r 0d c00c 0001 0001 000000820004 68 f4 2e a5

每当注入器响应这样的查询时，它都会暴露出其内存的一小部分，每次内容都不同。

我们假设注入器设备内部可能发生了如下过程。在其网络接口上观察到DNS查询后，注入器将数据包复制到内存中进行处理。其目标是从查询中解析QNAME，与封锁列表进行比对，并在需要时注入响应。在解析QNAME时，注入器首先看到3字节的标签rsf：到目前为止，一切正常。但长度前缀20表示下一个标签长32字节，这超出了org 标签和空标签、QTYPE和QCLASS字段，并超过了查询的末尾。由于未能执行边界检查，注入器将内存中数据包后面的字节视为查询的一部分——就好像QNAME是38字节 03 r s f 20 o r g 00 00 01 ⋅⋅⋅ P r o c / 。尽管名称末尾有多余的字节，但它仍然匹配封锁列表，原因将在第III-A节中解释。注入器将整个QNAME（如其所见）复制到DNS响应中。接下来的4字节（在此示例中， V e r 0d ）被解释为查询的QTYPE和QCLASS，并也被复制到响应中。

为什么解析器在 / 字节处停止，而不是将其视为长度前缀并读取另一个标签？我们在附录B中提供了解析算法的精确逆向工程描述，回答了这个和其他问题。在这种情况下，这是因为QNAME解析器在第一个超过查询末尾的标签长度前缀后停止。

A. 封锁列表匹配

当注入器检查名称是否在其封锁列表中时，它不会使用名称的有线格式表示。相反，它将QNAME展平为一个以00字节结尾的点分隔字符串。这个字符串被传递给封锁列表查找函数。证据是，当查询中的标签包含ASCII点字符 . 或空字节00时，封锁列表匹配器分别将其解释为标签分隔符或名称终止符。例如，如果名称example.com 在封锁列表上，以下任一QNAME 07 e x a m p l e 03 c o m 00 或 0f e x a m p l e . c o m 00 a b c 00 会引发注入。尽管这些名称在DNS级别是不同的（第一个由三个标签组成，分别为7、3和0字节；第二个由两个标签组成，分别为15和0字节），但它们都被展平为相同的有效字符串“example.com”。

这解释了为什么QNAME 03 r s f 20 o r g 00 00 01 ⋅⋅⋅ P r o c / 在前一个示例中被注入器理解为匹配封锁列表规则rsf.org。尽管第二个标签不仅仅是org，而是org加上许多额外的字节，但这些额外字节中的第一个是00，当它被展平为字符串时终止了名称。额外的字节包含在注入的DNS响应中，但它们不影响封锁列表匹配。

这也解释了为什么我们修改了org标签的长度前缀，而不是rsf标签。如果我们延长了rsf标签，03在 o r g 之前会被解释为展平名称字符串中的一个字面字符——因为字符串“rsf\x03org”不匹配封锁列表上的任何内容，它不会得到响应。而通过延长org标签，rsf和org仍然是单独的标签，最后的空标签00成为字符串终止符。改变第一个长度前缀是可行的，但随后第二个长度前缀也必须更改为一个点，以便在最终字符串中分隔标签： 20 r s f . o r g 00。

封锁列表规则不是字面名称，而是模式，类似于正则表达式[9 §4.1]。例如，单个规则可以封锁整个域及其子域。模式的构建并不统一（显示出易错的人为管理迹象）。我们一直使用的rsf.org 模式是结尾锚定和标签锚定的：rsf.org 和x.rsf.org 匹配该模式，但xrsf.org、rsf.org.x和rsf.orgx 不匹配。作为正则表达式，它可能是(.*\.)*rsf\.org$。相比之下，shadowvpn.com的模式是开始锚定而不是标签锚定的：shadowvpn.com、shadowvpn.comx和shadowvpn.com.x匹配它，但xshadowvpn.com和x.shadowvpn.com不匹配。它的正则表达式将是^shadowvpn\.com.*。

B. 最大化每个响应泄露的字节数

单个响应中可能泄露的最大字节数是125。这是因为注入响应中的问题（question）部分最大为131字节，而触发响应的查询中最短的问题（question）部分长度为6字节。响应中的问题（question）部分在开头包含查询中问题（question）部分的副本；其余部分是泄露的内存。为了最大化泄露的内存量，需最小化查询中问题（question）部分的大小（查询实际有多大），并最大化响应中问题（question）部分的大小（注入器认为查询有多大）。

最小化查询大小的第一步是省略QTYPE和QCLASS字段。当这些字段缺失时，注入器会从其自身内存中读取它们。QCLASS没有影响，而QTYPE仅控制注入器是生成类型A（IPv4）还是类型AAAA（IPv6）的响应。对于未知的QTYPE，注入器默认为类型A；只有当QTYPE是 001c时，它们才发送类型AAAA的响应。在任何情况下，问题（question）部分的大小都是相同的。

最小化查询大小的另一部分是使用短的QNAME。为了找到触发注入响应的短DNS名称，我们枚举了所有形式为a.b、a.bc和ab.c的名称，其中a、b和c的范围包括字符‘a’–‘z’、‘0’–‘9’、‘-’和‘_’，并将它们发送到中国的DNS查询中。我们找到了八个有效的短名称：3.tt、4.tt、5.tt、6.tt、7.tt、8.tt、9.tt和x.co。 ² 这些名称中的每一个都需要6字节来编码（例如，01 3 02t t00）。 ³

² 我们在2021年11月3日进行了这个实验。名称3.tt自2023年8月7日起不再触发注入：详见第IV节。
³ 这里有一个小细节。对于这样短的名称，技术上可以省略末尾的00字节，否则需要用于终止从查询解析的平坦名称字符串。注入器似乎会在将查询复制到内存之前将目标缓冲区的第18个字节置零，因此，长度仅为17字节的查询实际上具有隐式空终止符。由于DNS标头占用12个字节，因此，此技巧仅适用于QNAME短至5个字节的情况。但由于在这种情况下，第一个泄漏的字节是一个常量00，所以将QNAME从6个字节缩短到5个字节并不会增加泄漏的信息字节数量。有关此及其他底层细节的算法描述请参见附录B。

在第III节的开头，我们通过将QNAME标签的长度前缀从3增加到32，导致注入器泄露了29个字节。直观地说，为了泄露更多字节，应该进一步增加标签的长度。这种直觉是正确的，但仅在某个程度上有效。图2显示了随着查询中标签长度的增加，响应中的问题（question）部分大小会发生变化。（我们关注的注入器不会强制执行RFC 1035对标签的63字节长度限制[20 §4.1.4]，而是简单地将每个字节值解释为长度。）它们逐一增加，直到响应问题（question）部分达到最大131字节。超过该点后，问题（question）部分会略小于最大值，为130字节。

图2: 注入DNS响应中的问题（question）部分大小与查询中标签长度前缀x的关系。我们使用第III节中的“嵌入点字符”和“嵌入空终止符”技巧，将变长标签长度前缀置于问题（question）部分的开头。在QNAME查询中x r s f . o r g 00 。我们使用了第III-A节中的“嵌入点字符”和“嵌入空终止符”技巧，以便将可变标签长度前缀放置在问题（question）部分的开头。

这种奇怪的行为是由于查询解析算法的混乱逻辑造成的（见附录B）。导致算法主循环终止的两个条件是：在处理标签内容时，QNAME的总长度超过127字节，以及解析器刚刚读取的长度前缀超出查询的范围。当QNAME恰好为127字节（包括最终的标签长度前缀）时，131字节的sweet spot（最佳点）出现了。在这种情况下，第一个退出条件被避免，允许循环的下一次迭代在退出之前读取1个额外的字节。QNAME的127个字节，加上缺失的QTYPE和QCLASS的4个字节，使得问题（question）部分的总长度为131个字节。

QNAME长度限制是这种类型注入器的一般特性，与Wallbleed解析错误无关。我们向中国发送了逐渐增长长度的良好格式的查询（a.google.sm、aa.google.sm、aaa.google.sm，...），使用一个已知与封锁列表匹配的基本域google.sm。一旦最后一个标签的末尾的 m 字节被推出前127个字节，注入器就停止响应。对于类型A和类型AAAA的查询，以及QNAME中的任何标签数量，限制都是相同的。RFC 1035规定的最大名称长度为255字节[20 §2.3.4]。

虽然知道绝对限制及其原因令人满意，但在实践中，130字节和131字节之间几乎没有区别。在本文的许多实验中（一些是在我们理解解析算法的细微差别之前进行的），我们使用了ff的标签长度前缀，这比最大可能值少1字节。对于足够大的长度前缀，130字节的问题（question）部分响应与2012年klzgrad的发现一致[6]。

C. 不完整的补丁（Wallbleed v2）

GFW尝试在2023年9月至11月之间修补Wallbleed，增加了对DNS消息解析算法的限制。我们在第VII节中记录了补丁的进展。QTYPE和QCLASS字段不再可以省略，且QCLASS必须为 0001。此外，标签长度前缀溢出查询末尾但未达到127字节QNAME长度阈值的查询将被忽略。如下查询不再能泄露DNS注入器内存：

00000120 0001 0000 0000 0000 03 w w w 06 g o o g l e ff c o m 00

但第一个补丁忽略了解析循环中的一个退出条件。一个带有QTYPE和QCLASS的查询，且最终标签长度前缀超过127字节阈值，仍然会导致解析器认为查询比实际大。稍微修改的探测格式仍然可以引出内存内容：

00000120 0001 0000 0000 0000 03 w w w 06 g o o g l e 03 c o m ff0001 0001

我们将补丁前和补丁后的漏洞分别命名为Wallbleed v1和Wallbleed v2。我们在本文描述的大多数实验中使用了Wallbleed v1探测。在补丁后，我们能够使用修改后的探测恢复实验，直到Wallbleed v2在2024年3月最终被修补。在Wallbleed v2中，只有最大长度溢出是可能的：标签长度为ff有效，但20无效。我们发现最短的域名，如3.tt，不再能作为触发器，因此在后来的实验中使用了te.rs，下一个最短的有效域名。

D. 注入触发的其他细节

这里我们评论了一些触发注入条件的其他细节。请注意，GFW中还有其他类型的DNS注入器[8, 9]，它们有自己的封锁列表和实现上的怪癖。

注入器默认响应类型为A。 DNS注入器仅响应QNAME与某个封锁列表匹配的查询。易受攻击的注入器对类型AAAA的查询注入类型AAAA的响应，对所有其他类型的查询注入类型A的响应。

注入器适用于IPv4和IPv6。承载DNS查询的UDP数据报可以通过IPv4或IPv6发送；注入器对两者都响应，并根据查询伪造IPv4或IPv6响应。（这里我们指的是查询发送的IP版本，而不是查询的QTYPE。通过IPv4发送的查询可能请求IPv6地址，反之亦然。）2023年5月9日，我们发送了QNAME为 ff g o o g l e . s m 00 的Wallbleed探针到阿里云（北京，AS37963）的一个IPv6主机和中国的一个非DNS服务器2400:dd01:103a:4041::101。在这两种情况下，我们都得到了包含泄露内存的注入DNS响应。然而，我们无法在相反方向触发DNS注入，即从中国的VPS发送查询到美国的VPS或其他IPv6地址。这可能是因为注入器没有部署在我们从中国VPS到我们测试的外国目的地的路径上。

仅查看目标端口53。 2023年5月9日，我们从美国的VPS向中国的VPS发送了google.sm 的查询，UDP目标端口在0到65535之间变化。只有发送到端口53的查询导致了注入。这一观察结果与Lowe等人在2007年[21 §6.4]和Anonymous等人在2020年[8 §2.1]的先前发现一致。

IV. 洩露了哪些信息？

为了更好地理解漏洞泄露了哪些信息，我们进行了为期两年的纵向测量，从2021年11月21日到2023年11月29日。表I总结了这个实验以及后续章节的实验。

表I：实验时间线和观察点。总共，我们在腾讯云（TC，北京）（AS45090）使用了三个VPS，在科罗拉多大学博尔德分校（Scan，CO）（AS104）和马萨诸塞大学阿默斯特分校（Long，MA）（AS1249）各使用了一台机器。

实验	时间跨度		持续时间		中国主机	美国主机	章节
特征化	2021年10月2日 – 2022年2月10日		4	月	1 (TC，北京)	1 (Long, MA)	§III-B
重新特征化	2023年5月9日 – 9月10日	& 2024年2月	5	月	1 (TC，北京)	1 (Long, MA)	§III
纵向	2021年11月21日 – 2024年4月16日		2	年	3 (TC，北京)	1 (Long, MA)	§IV
观察我们自己的	2023年8月12日 – 9月8日	& 2024年3月13日	4	周	1 (TC，北京)	1 (Scan, CO)	§V
互联网扫描	2023年6月25日 & 8月23日	& 2024年3月6日	3	天	-	1 (Scan, CO)	§VI
补丁行为	2023年9月6日 – 11月7日	& 2024年3月6日 – 4月16日 2024	3	月	2 (TC，北京)	2 (Scan & Long)	§VII, §III-C

基于第III-B节中的观察，我们设计了以下Wallbleed探针来触发漏洞：

00000120 0001 0000 0000 0000 01 3 ff t t

该探针是对3.tt的查询，但在QNAME的终止空标签之前被截断（省略了QCLASS和QTYPE字段），并且将tt标签长度前缀从02增加到ff。（根据脚注3，对于这么短的QNAME，不需要最终的00标签。）如在第III-B节中解释的那样，这个探针导致了124字节的内存泄漏。

实验设置。我们从美国大学的主机向中国的一个IP地址发送了Wallbleed探针。中国的地址是腾讯云（AS45090）下我们控制的一个VPS。我们在一千个端口号（从10001到11000）的范围内变化探针的UDP源端口，因为之前的工作表明源端口号可能会影响DNS注入[22]。我们以每秒100个数据包（pps）的速率发送探针，并在两年内收集了51亿个Wallbleed响应。

查询名称。我们最初使用的QNAME 3.tt显然已经从注入器的封锁列表中删除，并于2023年8月7日11:04:01（中国标准时间，UTC+8）停止引发注入响应。我们将QNAME更改为4.tt，这是来自第III-B节的另一个短名称。

A. Wallbleed泄露网络流量

查看124字节泄露的内存片段样本，可以立即发现它们包含网络流量片段。这些片段至少部分来源于通过注入设备的包：在第V节中，我们展示了我们自己通过GFW发送的包负载的恢复。然而，协议的混合与预期的所有进入或离开中国的流量的统一样本不同。

在对响应样本进行初步手动分析后，我们使用正则表达式搜索常见或敏感字符串。为了降低分析可识别个人信息的风险，我们的程序仅输出匹配的数量。如表II所示，我们发现了UPnP、SSDP、HTTP、SMTP、SSH和TLS的实例，以及可能的敏感信息，如HTTP cookies和密码。

表II：对观察到的51亿个Wallbleed响应进行正则表达式匹配的次数，历时两年。

正则表达式	协议	计数		比例
ssdp:discover	SSDP	184	M	3.61%
UPnP/IGD\xml	UPnP	174	M	3.41%
(?s)[3-4]\xfftt.....-CONTROL	(§IV-B)	121	M	2.37%
\x45\x00	(§IV-A)	2.8	M	0.05%
uuid:WAN	SSDP	34	M	0.67%
Host:␣	HTTP	21	M	0.41%
(?i)Date:\s* …	(§IV-C)	16	M	0.31%
\x7f\x00\x00	(§IV-D)	2.8	M	0.05%
Cookie:␣	HTTP	2.0	M	0.04%
RCPT␣TO	SMTP	72.5	k	0.0014%
&key=	URL	58.1	k	0.0011%
MAIL␣FROM	SMTP	42.4	k	0.0008%
&password=	URL	26.9	k	0.0005%

值得注意的是，内存中包含了除DNS之外的应用层协议。由于注入器仅在UDP端口53上响应DNS查询（第III-D节），我们可能预期只会看到DNS或仅有UDP端口53的流量；但实际上，我们看到了各种协议，包括那些通常在不同端口和传输协议上运行的协议。相当大的一部分由UPnP（通用即插即用）和SSDP（简单服务发现协议）组成。UPnP使用HTTP——但UPnP的数量比其他形式的HTTP多一个数量级。第III节中的示例响应就是一个这样的UPnP实例。我们从1.66亿个UPnP片段中提取了HTTP Location头：在每个案例中，URL的主机部分是RFC 1918[23]的私有范围内的字面IP地址。私有地址与UPnP和SSDP一致，后者通常用于本地网络中的服务发现。然而，很难解释为什么它们在易受攻击的注入器的内存中以如此高的频率出现。

除了应用层协议，还有网络层和传输层的头和数据包。例如，有IPv4头。为了找到这些，我们首先寻找通常开始于IPv4头的两字节模式4500 ，然后（将后续字节解释为头）过滤出有效的IP校验和。表III显示了181,834个IPv4头中协议字段的分布。TCP、UDP和ICMP是最常见的，还有43个其他协议的长尾。

表III：IPv4头部中最常见的 protocol（协议）字段。只显示计数超过10次的。

编号	协议名称	计数
6	TCP	120,087
17	UDP	59,882
1	ICMP	1,735
50	ESP	38
0	IPv6 Hop-by-Hop Option	36
47	GRE	12

有7,743个案例中，IP头后面跟着TCP头和足够的数据，形成了一个完整的TCP段，具有一致的长度字段和有效的IP和TCP校验和。TCP头包含标志和端口号，我们可以通过这些启发式地推断出IP头中的两个IP地址哪个是服务器，哪个是客户端。为了避免分析可识别个人信息，我们将IP地址匿名化为两种粗略的类别：私有（RFC 1918）和公共。然后我们统计了客户端/服务器和私有/公共的比例；结果如表IV所示。

表IV：从7743个完整的TCP段推断出的客户端/服务器和私有/公共流量。

客户端地址	服务器地址	计数
私有	私有	384
私有	公共	6,276
公共	私有	193
公共	公共	890

由于DNS注入器监控公共互联网流量，我们预期从其内存中恢复的TCP段大多会有公共IP地址；然而，只有11%的TCP段是公共到公共的。大多数实际上涉及一个私有客户端和一个公共服务器。因为私有IP地址不是全球可路由的，人们可能会怀疑它们代表了GFW的内部流量（这与上面关于UPnP的观察一致）。然而，内存泄漏的有限大小意味着我们只能统计相对较短的TCP段（最多125字节）。也有可能我们看到的TCP段被封装在一个更高级别的协议中，如GRE，而不是直接路由通过中间设备。

B. 四个“摘要”字节

在纵向实验的开始，Wallbleed响应中泄露数据的前4个字节与其他字节不同。它们通常看起来更随机，这在泄漏的其他部分由可读的ASCII组成时尤其明显。不同的字节序列可能归因于部分覆盖的内存，但这不同：它始终是前4个字节，⁴并且它们不像其他字节那样包含网络协议的片段。我们称这些字节为“摘要”字节，假设它们代表查询包的哈希，可能用于负载均衡目的。（这只是一个猜测——我们尝试过，但没有找到能再现摘要字节的哈希算法。）摘要字节在2022年和2023年分两个阶段从Wallbleed响应中消失。

⁴ 在17字节查询的特殊情况下，包括本节中使用的探针，摘要字节出现在最初的00之后，如脚注3中所述。

摘要字节实际上并不是随机的，而是由DNS查询的内容决定的，包括其UDP四元组。在2022年2月15日（当时所有Wallbleed响应都有摘要字节），我们发送了具有相同有效载荷和源、目标IP地址和端口的Wallbleed探针。在所有114,717个结果注入中，前4个字节完全是d8fd d0 41 。然而，保持四元组不变并改变有效载荷中的一位，会导致摘要字节发生变化。⁵这可以与第V-A节中的注入器进程分配进行比较，后者依赖于四元组而不是有效载荷。

⁵ 改变有效载荷的一位也会改变IP校验和，因此摘要字节可能仅依赖于IP和UDP头，或依赖于头和有效载荷。

我们通过寻找一个特定的字符串ACHE-CONTROL （HTTP Cache-Control头的一部分）来测量摘要字节随时间的普遍性，该字符串经常出现在Wallbleed响应的开头（表II）。当摘要字节存在时，字符串的前4个字节会被覆盖。图3显示了摘要字节在九个月内分两个阶段消失的过程。当我们开始测量时，所有响应都有摘要字节。第一个缺少摘要字节的响应是在2022年9月3日星期六01:31（中国标准时间，UTC+8）。此后，摘要字节的存在与否取决于探针的源端口，在任何给定时间点，大约一半的端口会引发摘要字节。导致摘要字节的端口映射偶尔会发生变化，但始终保持在50%的比例——我们怀疑这代表了负载均衡。在2023年6月8日星期四15:33（UTC+8）之后，摘要字节几乎完全消失。

图3：下图显示了Wallbleed响应中带有摘要字节的比例，按一天内所有探针源端口的平均值计算。在2022年9月3日之前，所有响应都有摘要字节；在2023年6月8日之后，没有响应有摘要字节；在此期间，一半有，一半没有。在过渡期内，给定源端口是否引发摘要字节在短时间内是一致的。上图显示了按探针源端口和日期的摘要响应率，始终接近0%或100%。

C. 字节在内存中停留的时间

我们通过寻找自然出现的时间戳来估计字节在内存中停留的时间，即HTTP Date头。这些字符串的格式为Date: Wed, 21 Apr 2021 00:00:00 GMT，表示HTTP响应生成的时间。图4显示了包含完整Date头的1630万Wallbleed响应的年龄分布：即响应接收时间与其Date头中编码的时间戳之间的差异。大多数Date头来自最近的过去：75%在0到5秒之间，7%更老。大约10%在捕获时间相对的未来几乎正好8小时，这可能是服务器错误地将本地时间报告为UTC的结果。

在第V-A节中，我们进行了类似的内存年龄实验，使用我们自己故意放置的时间戳。

图4：HTTP Date时间戳相对于捕获时间的累积分布。上图的刻度为秒；下图的刻度为小时。大多数时间戳小于5秒。时区错误使得一些看起来在未来8小时。

D. 推断GFW的内部架构

泄露的内存偶尔包含看起来像x86_64指针的内容。这些是小端字节序的64位值，其最高有效的16位为零，并且位于常规地址范围内。在Linux上，典型的栈指针地址范围是0x00007f0000000000–0x00007fffffffffff，而代码和堆指针的地址范围是0x0000550000000000–0x000056ffffffffff。

在Linux上，典型的栈包含一个栈地址，后跟一个代码地址（分别对应于保存的帧指针和返回地址）。我们在泄露的有效载荷中寻找这些模式。我们找到了70,497个例子，并注意到几个常见的模式。我们基于每个有效载荷中存在的14个64位字创建了模式模板。例如，一个栈地址（在典型的Linux栈指针范围内的64位值）被替换为单个字符‘s’。以这种方式，代码指针（‘c’）和常见数字，包括零（‘0’）、−128（‘1’）、22（‘2’）和4（‘4’）被替换，剩余未标记的字被转换为‘_’。这产生了3,559个独特的模式，我们在图5中绘制了最常出现的模式。

图5：泄露内存中常见栈帧模式的计数，按周时间显示。‘s’和‘c’分别对应于栈和代码地址，数字对应于我们观察到的特定常见64位值。红色垂直线表示我们观察到摘要字节模式变化的时间（图3）。

两条红线表示摘要字节转换的阶段，来自图3。第一条线在2023年9月3日，与最常见的栈帧模式的变化相吻合；第二条线在2023年6月8日，没有显示出明显的模式变化。我们无法从这些变化的模式中得出更具体的结论；它们可能纯属巧合。

我们看到的栈帧与启用了ASLR的Linux栈帧一致，表明给定模式在某些位上看到随机化：在栈/代码指针中，最低有效的12位是一致的，对应于4KB页面中的一致偏移。在一些栈帧中，我们还观察到似乎是glibc栈金丝雀[24]，由一个随机值指示，其最低有效的8位设置为0，位于栈/代码地址对之前。

我们还观察到x86_64指令序列，如函数序言。我们认为这些是GFW在网络上看到的代码，而不是GFW本身的代码，原因有二。首先，在基于栈的内存泄露中指令泄露是不可能的，因为Linux在分配前清除页面，并且不允许在可写页面中执行代码。其次，我们还在大学网络监听中观察到x86_64代码，这似乎是微软代码更新发送（签名的）明文二进制文件[25]。

V. 观察我们自己的流量

在第IV-A节中，我们看到Wallbleed泄露了至少一些网络流量，甚至是非DNS流量，这些流量通过了注入设备。这里我们通过一个专门的实验确认了这一事实。我们将自己标记的流量发送到中国境内，后来能够在Wallbleed响应中恢复其中的一部分。

标记流量只能在发送后的几秒钟内恢复。恢复率很低，并且随时间变化。注入设备在内部被划分为多个独立的进程，我们通过一个先前未记录的侧信道揭示了这一点，该侧信道在注入的虚假IP地址的排序中。每个进程都有自己的内存：只有当Wallbleed探针恰好被分配到同一进程时，才能恢复过去的流量。数据包到进程的分配是确定性的，并且至少取决于探针的源端口。通过IPv6发送的探针可能会恢复最初通过IPv4发送的流量，反之亦然。

A. 带时间戳的魔法序列探针

我们为这个实验开发了一个新的探针。魔法序列探针是一个UDP数据包，发送到端口53，其40字节的有效载荷是20字节序列的两个副本：

G F W B l e e d exp pkt rep timestamp

其中exp是实验ID，pkt是递增的数据包ID，rep在探针中为序列的第一个副本时为0，第二个副本时为1，timestamp是一个纪元时间戳。固定字符串“GFWBleed”和唯一ID使得在Wallbleed响应中识别魔法序列变得容易。时间戳让我们可以估计恢复的魔法序列在内存中存在多久。虽然魔法序列探针使用UDP和目标端口53，但其结构与DNS不同。

在发送魔法序列探针的同时，我们也发送了Wallbleed探针，如第IV节中所述，以恢复我们试图放入内存中的序列。我们从美国的一所大学向中国的目的地发送了探针，时间从2023年8月12日到9月8日（表I）。目的地主机与第IV节中使用的不同，以避免两个实验之间的潜在干扰。我们以平均30个数据包每秒的速率从单个源端口10000发送魔法序列探针。我们从199个源端口（范围为20001至20199）以100个数据包每秒的速率发送Wallbleed探针。选择使用单个源端口进行魔法序列探针的决定最终变得非常重要，因为它有助于揭示离散的注入器进程的存在。我们收集了包含魔法序列的3,521个Wallbleed响应。

恢复的流量通常不超过1秒钟。图6显示了魔法序列探针中编码的时间戳与在Wallbleed响应中恢复的时间之间的差异。与第IV-C节中的HTTP Date时间戳一样，流量在注入器的内存中存活时间很短：99%的恢复的魔法序列时间戳在过去1.5秒内。−1秒到0秒之间的均匀斜率是timestamp一秒粒度的结果。与HTTP Date实验不同，这里不存在时区混淆的可能性。

图6：魔法序列中存储的时间戳与我们在Wallbleed响应中恢复它时的时间差的累积分布。图中显示了2023年8月12日至9月8日期间收集的3,521个包含魔法序列的Wallbleed响应的分布。时间差的范围是−10.19秒到−0.23秒。

恢复流量的可能性在一天的周期中变化。图7显示了28天内每小时包含魔法序列的Wallbleed响应的数量。虽然我们以恒定速率发送Wallbleed探针和魔法序列探针，但每小时恢复的探针数量在24小时周期中变化，峰值在04:00到05:00之间，谷值在22:00到23:00之间（中国标准时间，UTC+8）。这与中国互联网流量量的反向昼夜模式一致：注入器处理的流量越多，我们观察到自己数据包的可能性就越小。

图7：观察到魔法序列的可能性取决于一天中的时间。淡色背景点代表了从2023年8月14日开始的四周内每小时收到的包含魔法序列的Wallbleed响应数量。深色前景点是所有28天中相应小时的平均值。

数据包在内存中具有一致的对齐方式。当我们恢复一个魔法序列时，我们无法获得完整的40字节。几乎总是，开头部分被触发响应的Wallbleed探针的字节覆盖。使用第IV节中的Wallbleed探针，前18字节被覆盖，最后22字节保持完整。注入设备可能在内存中将数据包的第一个字节对齐到一致的位置。其他观察支持这一假设：在第IV-B节中，我们利用了常见的ACHE-CONTROL字符串的对齐来测试摘要字节的存在。

只有一部分源端口曾经看到过魔法序列。我们从单个源端口（10000）发送魔法序列探针。尽管我们从199个不同的源端口（20001–20199）发送了Wallbleed探针，但只有64个源端口曾经恢复过魔法序列。（那些恢复的平均恢复了55个魔法序列。）进一步的调查使我们相信，每个DNS注入设备由多个独立的进程组成，每个进程都有自己的内存缓冲区，并且数据包根据包括源端口在内的特征被确定性地分配到一个进程。（但不是有效载荷，因为魔法序列探针具有可变的有效载荷。这与第IV-B节的摘要字节形成对比，后者确实依赖于有效载荷。）只有当Wallbleed探针被分配到与原始魔法序列探针相同的进程时，它才有机会恢复它。（这可以解释图3中的水平带：在一段时间内，一半的进程使用摘要字节，一半没有。）在下一小节中，我们将展示更多关于多进程假设的证据，以注入的DNS响应的虚假IP地址中一个先前未知的侧信道的形式。

B. 虚假IP地址的排序

先前的研究表明，GFW的DNS注入从一个固定的池中提取虚假响应IP地址，并且根据查询的名称使用池的不同子集[8 §3.2]，[9 §5.3]。现在尚未被理解的是，这些池也是有序的和循环的。当以足够高的速率（每秒约100个查询或更多——远高于注入器的自然注入速率）进行探测时，使用一致的查询名称和源/目标IP地址和端口元组，注入的响应会以相同的顺序反复循环通过IP地址（偶尔会有注入器响应其他用户查询的间隙）。通过重复探测，可以获得序列的多个副本，调和间隙，并恢复给定查询名称的完整虚假IP地址有序列表。4.tt查询名称的592个IP地址的示例有序列表出现在附录A中。

选择任何IP地址作为循环中的“第一个”，我们可以从IP地址构建到其索引的反向映射。独立于Wallbleed泄漏，每个DNS响应在注入时揭示了注入器的内部索引变量。图8显示了在从199个源端口以高速率探测时，Wallbleed响应中包含的IP地址的索引在45秒间隔内的变化。我们看到的不是一个，而是三个大致线性的序列。它们是循环的：当一个达到顶部时，它会回绕到底部。相同的源端口始终映射到相同的序列。对我们来说，这看起来像是注入设备内多个进程上的基于哈希的负载平衡。负载平衡分配的输入包括数据包的UDP四元组，但不包括其数据有效载荷（因为魔法序列探针的有效载荷是可变的）。保持四元组的其余部分不变，源端口根据它们被分配到的注入器进程分为少数等价类。这解释了为什么只有199个源端口中的64个恢复了魔法序列：那些是恰好被分配到与源端口10000的魔法序列探针相同的进程的端口。

图8：2023年8月23日，在45秒内从199个不同的源端口进行高频率探测后收到的Wallbleed响应样本。每个响应中的IP地址已被反向映射到其在附录A中的有序列表中的索引（从1到592）。这些索引不是随机的，而是形成了三个不同的循环序列——每个源端口始终映射到其中一个。每个序列代表DNS注入器中的一个进程，具有自己的地址列表迭代器和内存分配。只有199个源端口中的64个映射到正确的进程以恢复第V-A节的魔法序列探针。

C. IPv4和IPv6

Wallbleed提供了一种方法来判断IPv4和IPv6数据包是否在相同的GFW节点上处理。如果我们通过GFW发送一个独特的IPv4有效载荷，并在基于IPv6的Wallbleed查询中看到该有效载荷的部分泄露在内存中，那么我们就知道有节点在相同的内存中处理IPv4和IPv6。

我们从MaxMind的GeoLite2国家代码数据库[26]（下载于2024年3月12日）中收集了一组地理定位到中国的IPv6前缀，排除了基于RouteViews BGP数据（下载于2024年3月13日）未路由的前缀。我们向每个IPv6前缀中的8个随机地址发送了一个Wallbleed v2探针。如果至少6个响应了Wallbleed泄漏，我们就保留该前缀。我们从这些610个IPv6前缀中抽样得到133k个随机IPv6地址，这些地址很可能通过GFW节点。对于IPv4地址，我们随机抽样了126k个响应于2024年3月6日进行的IPv4范围ZMap扫描的IPv4地址。

对每个IPv4和IPv6地址，我们发送了一个针：一个UDP端口53数据包，具有900字节的有效载荷，由一个8字节字符串、2字节实验ID和4字节索引的重复序列组成，用于标识我们将针发送到哪个IP地址。同时，我们以每秒50个数据包的速度向每个地址发送Wallbleed v2探针，并收集响应以查看是否包含先前发送的针。我们在80分钟内重复了五次这个过程。

有70个实例显示，一个地址接收到的Wallbleed泄漏有效载荷包含一个最初发送到不同地址的针。在这些实例中，12个从IPv4针泄漏到IPv4探测地址，47个从IPv6泄漏到IPv6，8个从IPv4泄漏到IPv6，3个从IPv6泄漏到IPv4。IPv4到IPv6和IPv6到IPv4泄漏的存在表明，易受Wallbleed影响的DNS注入器在相同的内存空间中处理IPv4和IPv6流量。

VI. 受Wallbleed影响的IP地址

易受Wallbleed影响的DNS注入器是GFW的一部分。这些注入器是否影响了中国的每个部分，或者中国以外的任何地方？有多少IP地址可能通过了易受攻击的注入器，从而可能被泄露？我们从中国境外进行了IPv4范围的扫描以回答这些问题。Wallbleed v1和v2都影响了中国各地的IP地址，这与在网络边界部署DNS注入的假设一致。在许多情况下，即使是从美国发送到中国以外地方的探针也得到了Wallbleed注入，因为网络路径经过了边界。

A. IPv4范围扫描

我们使用ZMap[27]从美国的一所大学扫描了公共IPv4地址空间。为了发现受Wallbleed v1影响的IP地址，我们将以下有效载荷发送到UDP端口53：

00000120 0001 0000 0000 0000 01 4 10 t t

该有效载荷旨在从Wallbleed注入器中引发溢出，仅需少量（14字节）的溢出即可确认漏洞。如脚注3中所述，这个非常短的QNAME不需要尾随的00即可生效。我们以250 Mbps的速率发送数据包，扫描耗时三个小时。

我们选择了名称4.tt ，因为它不太可能出现在中国以外国家的DNS封锁列表中。直到2020年11月，4.tt 还是一个中文赌博网站。⁶ （赌博是GFW封锁的主题之一[28 Art. 15]， [9 §4.2]。）该名称不再解析为IP地址，自至少2023年7月以来一直如此。在我们的扫描中使用一个以中国为重点且已失效的名称减少了触发其他国家DNS注入器的可能性。

⁶ https://web.archive.org/web/2020*/http://4.tt/

为了发现受Wallbleed v2影响的IP地址，我们将以下有效载荷发送到UDP端口53：

00000100 0001 0000 0000 0000 02 t e 02 r s ff 0001 0001

如第III-C节中介绍，te.rs 是Wallbleed v2的最短有效QNAME，标签长度前缀必须超过解析器中的一个常量阈值。⁷

限制。我们仅进行了三次扫描：2023年6月25日和2023年8月23日针对Wallbleed v1，2024年3月6日针对Wallbleed v2。我们从美国的一个主机进行扫描：其他位置与中国的不同网络路径可能会得到不同的结果。这项快照研究的结果反映了扫描时的路由模式，我们无法预测它们随时间的变化。类似的注入器中间盒——无论是否具有类似Wallbleed的漏洞——可能存在于其他国家，但我们的扫描不会发现它们，因为我们使用了一个特定于中国的被封锁域名。

⁷ 我们未能像对Wallbleed v1那样限制Wallbleed v2探针的溢出量，这可能是通过在QNAME前添加前缀以使其长度接近注入器的最大长度阈值来实现的。

B. Wallbleed响应分析

除非另有说明，本节的分析基于2023年8月23日的扫描。2023年6月25日的Wallbleed v1扫描和2024年3月6日的Wallbleed v2扫描的结果在质量上相似。⁸ 该扫描从245.4百万个不同的IP地址中引发了248.3百万个响应。2.17百万个IP地址有多个响应，最多的一个案例有20,270个响应，这可能是路由环路的结果。[29, 30]。

⁸ 我们未能像对Wallbleed v1那样限制Wallbleed v2探针的溢出量，这可能是通过在QNAME前添加前缀以使其长度接近注入器的最大长度阈值来实现的。

我们使用了两步过滤来将Wallbleed注入与其他响应分开。首先，我们过滤了响应中答案部分包含Wallbleed注入器已知使用的虚假IP地址的响应。具体来说，我们保留了以资源记录形式结束的响应c00c 0001 0001 TTL 0004 a b c d (类型A)，或c00c 001c 0001 TTL 0010 a b c d e f g h (类型AAAA)，其中a.b.c.d 或a:b:c:d:e:f:g:h 是附录A中的IP地址之一。（类型A和类型AAAA响应都是可能的，尽管探针没有指定QTYPE。）接下来，我们过滤了以字节模式开头的响应 00008180 0001 0001 0000 0000 01 4 10 t t ；即探针的QNAME和ID字段的响应，标志等于 8180，这是受影响注入器的特征。

过滤后，剩下244,911,941个响应（占所有响应的98.6%）来自242,442,549个不同的IP地址，这些是确定的Wallbleed注入。表V显示了UDP有效载荷长度和DNS答案资源记录类型的分布。

表V：Wallbleed v1扫描中Wallbleed响应的UDP长度和DNS资源记录类型。

UDP负载长度（字节）	响应数量	类型
52	244,881,083	A
64	30,837	AAAA
33	8	A
48	7	A
45, 46, 50, 51, 158	1	A
68	1	AAAA

在几乎所有情况下（99.99%），对我们探针的响应是一个52字节的A型（IPv4）响应。52字节是预期的长度，考虑到探针中的标签长度前缀和注入器回答部分的固定大小。在少数情况下，响应是64字节的AAAA型（IPv6）响应。对此效果有一个解释：因为我们的探针没有包含QTYPE字段，注入器从探针后内存中的字节中获取QTYPE。注入器默认是A型响应，但在特殊情况下，如果QTYPE对应的字节值为 001c，注入器会生成一个AAAA型响应。

C. 响应IP地址分析

我们使用IP地理定位和IP到ASN映射来查找在水平扫描中接收到Wallbleed响应的IP地址的位置（在过滤掉非Wallbleed响应后，如前一小节所述）。不出所料，几乎所有的IP地址都报告在中国，并且代表了该国的每个地理区域。少数响应的IP地址报告在中国以外（经过多数据库交叉检查以减少地理定位错误的可能性）。

我们在国家级IP2Location LITE DB5数据库[31]（2023年6月30日）和CAIDA ASN数据库[32]（2023年7月18日）中查找了每个受Wallbleed响应影响的IP地址。接收到Wallbleed响应的2.42亿个IP地址映射到32个国家或地区，属于381个AS，拥有554个不同的ASN。表VI显示了按响应IP地址数量排列的前十个AS，全部位于中国。

表VI：拥有最多Wallbleed受影响IP地址的自治系统（AS）。所有这些自治系统都位于中国，根据地理定位数据库的信息。当一个自治系统拥有多个编号（ASN）时，我们展示受影响IP地址最多的那个编号。

自治系统名称	自治系统编号	# IP数量
China Telecom	4134, …	104.2 M
China Unicom Backbone	4837, …	54.9 M
China Mobile	9808, …	23.9 M
China TieTong	9394, …	12.8 M
China Unicom	4837, …	12.7 M
Alibaba	37963, …	7.3 M
Tencent	45090, …	5.2 M
China Networks IX	4847	3.7 M
CERNET	4538	3.1 M
Oriental Cable Network	9812	1.7 M

为了更精细的粒度，我们抽样了10,000个IP地址，这些地址在国家级地理定位中被放置在中国，并在城市和省级IP2Location LITE DB5数据库中查找[31]（2023年8月24日）。抽样的IP地址代表了中国的所有22个省、5个自治区和4个直辖市。因此，我们推测易受Wallbleed影响的DNS注入器影响了整个国家，而不仅仅是某些地区。

表VII：在美国进行水平扫描时接收到Wallbleed响应的中国以外的网络。表中展示了2023年6月25日和2023年8月23日的两次扫描。表格显示了受影响IP地址数量最多的十个自治系统（AS）。在6月的扫描中，总共有来自37个国家的104个非中国自治系统，在8月的扫描中，有来自31个国家的99个自治系统。

自治系统名称	自治系统编号	国家代码	# 独立IP数量
六月	八月
Dreamline	9457	KR	1,534	1,086
MASTER-7-AS	26380	AU	315	489
Anpple Tech	133847	MY	243	257
Chinanet Backbone	4134	HK	235	248
AZT	53587	US	186	168
Network Joint	133762	HK	63	61
HK Broadband	9269	HK	50	85
STACKS-INC-01	398704	HK	31	78
Viettel Group	7552	VN	31	30
Aofei Data	135391	HK	29	28

只有110,676个（0.05%）IP地址在国家级地理定位中被映射到中国以外的国家。考虑到DNS注入已知会影响仅仅经过中国的网络路径，地址在中国以外受到影响并非不可能[33]。但由于地理定位数据库可能不准确[34 §6.2]，我们应用了额外的过滤来消除不太确定在中国以外的地址：

1): 我们使用了三个不同的数据库：MaxMind GeoLite2 city[26]（2023年9月1日）、IP2Location LITE DB5[31]（2023年8月24日）和IPGeolocation.io[35]（2023年10月2日）。如果一个IP地址在任何数据库中被映射到中国，我们就排除其整个/24网络。
2): 我们在Team Cymru[36]（2023年10月2日）和CAIDA[32]（2023年6月27日）的ASN数据库中查找了每个IP地址。当一个ASN的注册国家是中国时，我们也排除其整个/24网络。

过滤器设计为保守型，即它倾向于将IP地址归类为中国。经过过滤后，还剩下6,822个IP地址。表VII按AS对其进行了总结，图9展示了它们的地理位置。

图9：在美国主机扫描时接收到Wallbleed响应的中国以外IP地址的城市级地理定位。

尽管可能仍然存在一些错误的地理定位，但很明显，一些中国以外的流量可能已暴露于Wallbleed所代表的隐私风险中。2010年，Sparks等人观察到109个地区存在DNS污染，主要是由于GFW在通往TLD服务器的传输路径上进行的DNS注入[33 §4.4]。2021年，墨西哥的主机无法访问whatsapp.net ，因为GFW向中国的根DNS服务器查询注入了伪造的响应[37, 38]。

VII. 监控审查者的补丁行为

我们预计GFW最终会修补Wallbleed漏洞。通过持续监控和全中国范围的扫描，我们记录了2023年9月/10月对Wallbleed v1的补丁过程，以及2024年3月对Wallbleed v2的补丁过程。

实验设置。为了持续监控，我们从美国向我们在中国控制的IP地址发送Wallbleed探针和普通DNS查询，速率为100 pps。我们使用4.tt 进行v1探针，使用te.rs 进行v2探针。普通DNS查询作为对照，用于区分漏洞的修补与注入器离线或QNAME从封锁列表中移除的情况。如果注入器停止响应Wallbleed探针，但继续不间断地响应普通探针，这表明审查者可以在最小停机时间内对GFW进行热补丁。另一方面，如果注入器在一段时间内对两者都停止响应，随后仅恢复对普通探针的响应，那么我们可以测量与补丁相关的停机时间。我们在UMass Amherst使用一台机器，对2023年9月6日至11月7日的Wallbleed v1和2024年3月6日至4月16日的Wallbleed v2进行了持续监控。

我们还对中国的约一百万个地址进行了扫描。这些扫描旨在测试补丁是否会在不同地区的不同时间发生，或在全国范围内同时发生。我们从第VI节中发现的2.15亿个响应的IPv4地址中，每个/24子网选择一个代表，得到1,130,343个IP地址。我们使用ZMap[27]每15分钟向这些IP地址发送一个Wallbleed探针。我们在科罗拉多大学博尔德分校进行这些扫描，时间为2023年9月6日至11月7日的Wallbleed v1，以及2024年3月28日至4月16日的Wallbleed v2。

实验结果。图10显示了在ZMap扫描中响应Wallbleed v1探针的/24子网数量，以及每小时的流失率：即在一个小时内响应但在下一个小时内不响应的IP地址数量，反之亦然。我们按小时聚合响应的IP地址，以减少因数据包丢失导致的假阴性。

图10：我们跟踪了响应Wallbleed v1探针的IPv4 /24子网数量随时间的变化。我们在2023年9月6日至11月7日期间，每15分钟扫描1,130,343个IP地址（每个子网一个）。我们未能在2023年9月17日至10月4日期间收集数据。Wallbleed v1的补丁分为两个主要阶段：2023年9月6日至14日；以及2023年10月22日至11月1日。

在10月23日之前，响应率有一些变化，当时Wallbleed漏洞在大约一周内被修补。从10月23日开始，我们观察到响应率逐步下降，因为漏洞逐步被修补。最后三个步骤发生在10月30日（星期一）、10月31日（星期二）和11月1日（星期三），每天在同一时间：10:00到12:00（中国标准时间，UTC+8）。在11月1日12:00之后，我们不再看到任何我们扫描的IP地址的Wallbleed v1响应。我们检查了在10月30日步骤中变为无响应的IP地址。39,000个地址中有86%属于一个不再响应的/20子网，这表明这些离散步骤对应于大块IP地址的同步变化，而不是更随机的负载平衡更新方式。

Wallbleed v2在2024年3月28日被完全修补。不幸的是，我们只捕获了补丁过程的最后60分钟，在四次水平扫描中。与Wallbleed v1类似，Wallbleed v2也是在离散步骤中修补的。我们将Wallbleed v2最终修补的时间隔离在2024年3月28日16:01:30到16:16:30之间（与v1不同的时间）。

在最后一小时的捕获中，42,084个IP地址引发了Wallbleed v2响应。有趣的是，其中33,779个（80.3%）地址属于AS4538（CERNET，中国教育和科研网中心），以及属于中国移动和中国各大学的49个自治系统的长尾。这一观察支持了CERNET维护国家GFW基础设施子集的假设。CERNET中的DNS注入器与GFW的其他部分具有共同的Wallbleed v2漏洞，表明统一的管理和协调的补丁。同时，其独特的补丁时间表显示了其在操作和维护中的一定独立性。

VIII. 相关工作

GFW的DNS注入是互联网审查中最古老且研究最多的形式之一。我们所知的最早文献记录来自2002年的两个独立研究，一个由Dong进行[39]，另一个由Zittrain和Edelman进行[40]，两者都发现所有注入响应中使用了一个虚假的IP地址。2009年，gfwrev发现了中国的两种DNS注入器，具有不同的指纹，并记录了除2002年使用的IP地址外的另外七个响应IP地址[13]。2014年，Anonymous等人分析了注入响应中的IP ID和TTL模式，推断出存在367个独立的注入过程，每秒注入0到60个虚假DNS响应[7 §7]。到2016年，使用的虚假IP地址数量已增长到至少174个[41, 42]。Anonymous等人在2020年区分了至少三种DNS注入器的指纹[8]。Hoang等人在2021年的大规模测量显示，跟踪GFW的DNS域名封锁列表的变化有助于理解中国的审查趋势[9]。

最类似并确实启发了我们工作的过去研究是gfw-looking-glass.sh，这是由gfwrev的klzgrad在2010年发布的一个单行shell脚本[5, 6]。据我们所知，这是GFW中第一个内存转储漏洞。名称在2字节压缩指针的第一个字节后截断的DNS查询导致GFW的DNS解析器将附近的内存视为名称的一部分，并在注入响应中泄露出来。在我们发现Wallbleed之前，该漏洞已被修复。该脚本顺便证明了包含嵌入点字符的查询名称， 06 w u x . r u ，与正确分成独立标签的名称相同， 03 w u x 02 r u ，表明当时GFW也是在将名称序列化为点分字符串后再与封锁列表匹配，而不是在结构化标签上匹配。2014年，klzgrad发现GFW的DNS注入器已停止解释压缩指针，开启了使用非常规方式使用指针的查询来规避DNS注入的机会[43]。

Wallbleed由Sakamoto和Wedwards在2023年独立发现[44]。他们分析了泄露的数据，推断出GFW进程的特征，并提出了利用该漏洞的几种攻击。除了确认他们的观察外，我们还通过自2021年10月以来超过两年的纵向和全网测量进一步研究了Wallbleed。我们揭示了Wallbleed的根本原因，重建了C代码中的解析逻辑，使用了一种新颖的旁路信道来识别易受攻击的注入器中的单个进程，检查了受影响的IP地址，并在2023年11月的第一次不完整补丁后发现了Wallbleed v2漏洞。

Wallbleed的命名类似于其他类似的内存泄露漏洞。Heartbleed是OpenSSL中的一个漏洞，允许客户端一次泄露多达64 KB的TLS服务器内存[1]。Cloudbleed是2017年在Cloudflare内容分发网络的边缘服务器上使用的HTML解析器中的一个漏洞[3, 4]。类似地，Ticketbleed记录了F5中间盒中的一个漏洞[2]。

IX. 伦理

本研究中出现了三个主要的伦理考量。首先是实验数据的处理，例如我们在纵向实验中收集的两年数据。如果我们认为Wallbleed对通过易受攻击注入器的用户流量构成隐私风险，那么泄露数据的存储和分析需要谨慎和小心。第二个是是否或在何种情况下可以利用一个可能被视为敌对网络攻击者的系统中的安全漏洞[10, 11]——在这种情况下是GFW。第三个是如何进行披露。

A. 数据处理

第V节的实验表明，Wallbleed泄露给第三方的至少一些数据源自通过防火墙的流量。这带来了隐私问题：网络流量可能包含敏感信息，如用户名、密码或网页请求。我们将研究计划提交给我们的机构审查委员会（IRB），该委员会豁免了这项研究，因为它不涉及人类受试者。以下是我们对这些数据的考虑和保护措施。

数据收集。在减少数据收集和进行有意义的分析之间存在不可避免的权衡。一旦了解了Wallbleed漏洞，泄露一个字节就足以确认其存在，但这种有限的测量无法让我们研究防火墙的架构或互联网用户受到的影响。对内存中（而非存储的）数据的即时分析可以让我们报告一些结果，但我们不会注意到也无法分析意外的变化，例如第IV-B节中“摘要”字节的逐渐消失。因此，我们专注于保护收集的数据，而不是人为地限制收集的内容。最终，在团队内部和与审稿人讨论后，我们决定在本工作发表后删除收集的数据。

B. 利用的伦理

利用此类漏洞在伦理上是复杂的。从道义论的角度来看[45 §4.1]，安全研究人员可能会决定在任何情况下都不利用他们无法控制的系统中的漏洞，因为这样做可能会产生难以预测的意外和负面影响。或者，从结果论的角度来看[45 §4.1]，必须权衡研究的好处与其风险。

我们在研究中识别出两个潜在危害和负面影响的高层次来源：（1）我们收集的数据可能包含敏感信息，可能会泄露；（2）我们发送的探针可能导致GFW或其他中间设备或终端主机崩溃或故障。我们在第IX-A节中讨论了第一个风险来源。下面我们讨论如何管理第二个风险来源。

鉴于我们利用的系统本身被许多人视为危害的来源[10, 11]，即使我们的实验对GFW造成损害，也将通过阻碍审查来减少对超过十亿人的危害。特别是，GFW的任何崩溃都不太可能阻碍网络流量。过去的研究表明，GFW的DNS注入器是路径设备[7, 8, 9, 12, 21, 39, 46, 47, 48]；也就是说，它们通过获取流量的镜像副本工作，而不是传输链中的一个环节。最后，先前的工作已经利用其他有害系统中的漏洞，如僵尸网络和中间设备，以研究这些问题系统[29, 49, 50, 51, 52]。

为了最大限度地减少其他中间设备和终端主机崩溃的风险，我们在实验的前18个月内谨慎地仅向我们控制的主机发送流量。只有在观察到没有不利影响后，我们才开始进行全网扫描。遵循互联网扫描的最佳实践[27]，我们将每个不在我们控制下的主机的流量量限制为每15分钟仅一个UDP数据包。我们在扫描的源IP地址上托管了一个网页，显示项目描述并解释如何选择退出扫描。在研究过程中，我们收到并尊重了一次选择退出请求。

C. 是否披露以及如何披露

披露此类漏洞也是复杂的。通过报告该漏洞，我们是否最终在“帮助”GFW？还需要考虑立即披露和延迟披露之间的权衡：现在消除用户的隐私风险，还是花时间更深入地了解审查系统，以便可能在未来避免更大的风险和危害？

我们决定采取协调披露的策略，但只有在利用漏洞的机会尽可能多地了解DNS注入子系统之后。两个因素促使我们最终决定披露。第一个是用户隐私的风险。一旦未修补的漏洞被公开，可能会被不关心用户安全的其他人利用。第二个是Wallbleed漏洞并没有降低DNS审查系统的有效性。修复Wallbleed后，注入器继续像以前一样干扰连接，但它们不会做得更多。

这种伦理计算是特定于这种情况的。在其他情况下，我们可能会做出不同的决定。如果GFW存在实现错误，导致它未能审查一部分连接，并且未增加对用户的风险，我们就没有义务报告它。我们的义务不是针对抽象的错误修复，而是针对用户的安全。我们坚持认为，像Wallbleed这样的漏洞的唯一正确修复方法是将受影响的设备（即GFW注入器）从网络中移除：真正的“bug”是这些设备的存在，而不是它们无疑存在的特定实现错误。它们无疑存在。2023年11月的不完整补丁导致了Wallbleed v2变种的出现，这进一步证明了这一点：只要注入器存在，它们就会对用户构成风险。

最终，我们披露的决定被漏洞修补所无效化，因为我们无法在向CNCERT报告问题之前就已修补了漏洞。这篇论文也是我们披露策略的一部分：记录和公开这个漏洞将引起更多人对审查的许多危险的关注。

X. 未来工作的经验教训

我们的研究提供了一个独特的案例研究，展示了在保护用户数据和研究数据的实用性之间的平衡。在事后看来，我们可以看到一些地方我们本可以选择收集更少的数据（从而降低收集个人信息的风险），但我们注意到，事先很难知道非结构化数据的最佳边界。例如，我们通过研究大量完整的负载数据了解到4字节“摘要字节”特性。事后看来，我们可能只需泄露4字节就能发现GFW的这一特性，因此可能看起来不需要收集更多的数据。但如果事先不了解这一特性的性质，就很难知道4字节是否足够。同样，在选择泄露多少字节时，我们面临一个困难的权衡：泄露更多字节可能会收集到个人数据的风险（但可能会更多地了解GFW的未知特性），或者泄露更少字节可能会学到更少（但限制了潜在的敏感数据收集）。这种权衡应该在所有工作中仔细考虑，我们希望通过记录我们的思考过程，激发研究界的进一步讨论和辩论。

IRB的决定。我们被要求对机构审查委员会（IRB）将我们的工作标记为豁免的决定提出异议，因为审稿人认为我们的工作中还有其他伦理考虑未被该决定涵盖。我们同意我们的工作有复杂的伦理考虑，但不同意这些考虑明确属于IRB的范围，或作者应被要求对他们不同意的IRB决定提出异议。

我们在提交给IRB的协议中是透明的，包括收集的数据可能包含第三方网络流量。这是我们提交的协议的摘录：

“我们发现，在处理某些格式错误的DNS查询时，子系统可能在其注入响应中包含不相关的系统内存片段。简而言之，防火墙‘泄露’了小片段的内存，这些内存可能偶然包含通过GFW的其他人的网络流量。该发现对网络安全和理解GFW都具有重要意义。虽然泄露内存的内容是不可预测的，但它们可能包含个人身份信息，如IP地址。因此，我们正在寻求IRB的指导，特别是关于这项研究是否需要全面的IRB审查。”

我们认识到IRB豁免并不等同于IRB对工作的伦理判断，也不一定意味着IRB认为不需要考虑潜在的危害或伦理问题。相反，豁免意味着IRB已确定它不属于“人类受试者研究”的狭义定义[53 § 219.102]。为此，我们将收集的数据视为敏感数据，并在发表前删除，以防止潜在的滥用。尽管如此，我们认为让我们的社区了解IRB的局限性很重要，并避免将其作为伦理决策的替代。

XI. 结论

在这项工作中，我们呈现并研究了Wallbleed，这是中国GFW的DNS注入子系统中的一个缓冲区过读漏洞。我们进行了纵向和全网测量，以了解Wallbleed的成因和影响。我们还揭示了GFW内部架构和操作的细节，这些细节在没有Wallbleed的情况下是不可能了解的。Wallbleed说明了审查设备对互联网用户造成的危害不仅仅局限于审查本身的直接（且预期的）影响：它还可以严重侵犯用户的隐私和保密性。

可用性

为了鼓励未来的研究并提倡透明性和可重复性，我们已公开提供代码、匿名化数据以及关于我们研究过程和论文发表过程的额外背景信息。为了提高可访问性，我们提供了论文的英文和中文HTML版本。项目主页在： https://gfw.report/publications/ndss25/en。

致谢

我们深深感谢几位希望保持匿名的同事，他们在整个项目中提供了宝贵的贡献和指导。我们还感谢来自gfwrev的klzgrad，其在2010年的开创性工作激励了我们，并在本次研究中提供了多轮深思熟虑的评论。此外，我们感谢Alberto Dainotti、Ali Zohaib、Cecylia Bocovich、Diogo Barradas、J. Alex Halderman、Jakub Dalek、Jeffrey Knockel、Michael Carl Tschantz、Nadia Heninger、Philipp Winter、ppmaootc、Prateek Mittal、Xiao Qiang和Zakir Durumeric。我们也感谢匿名审稿人提供的有益评论和指导。

引用

Z. Durumeric, F. Li, J. Kasten, J. Amann, J. Beekman, M. Payer, N. Weaver, D. Adrian, V. Paxson, M. Bailey, and J. A. Halderman, “The matter of Heartbleed,” in Internet Measurement Conference. ACM, 2014. [Online]. Available: https://dl.acm.org/doi/10.1145/2663716.2663755.
F. Valsorda. (2016) Ticketbleed (CVE-2016-9244). [Online]. Available: https://filippo.io/Ticketbleed/.
J. Graham-Cumming. (2017, Feb.) Incident report on memory leak caused by Cloudflare parser bug. [Online]. Available: https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/.
M. Prince. (2017, Mar.) Quantifying the impact of “Cloudbleed”. [Online]. Available: https://blog.cloudflare.com/quantifying-the-impact-of-cloudbleed/.
gfwrev. (2010, Sep.) “gfw-looking-glass.sh: while true; do printf "\0\0\1\0\0\1\0\0\0\0\0\0\6wux.ru\300" | nc -uq1 $SOME_IP 53 | hd -s20; done”. [Online]. Available: https://twitter.com/gfwrev/status/25220534979/.
Anonymous. (2020, Mar.) GFW archaeology: gfw-looking-glass.sh. [Online]. Available: https://github.com/net4people/bbs/issues/25.
——, “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.
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.
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.
Internet Society. (2023, Dec.) When is the Internet not the Internet? [Online]. Available: https://www.internetsociety.org/resources/internet-fragmentation/the-chinese-firewall/.
D. Anderson, “Splinternet behind the Great Firewall of China: Once China opened its door to the world, it could not close it again,” Queue, vol. 10, no. 11, pp. 40–49, Nov. 2012. [Online]. Available: https://queue.acm.org/detail.cfm?id=2405036&doi=10.1145%2F2390756.2405036.
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.
gfwrev. (2009, Nov.) 深入理解GFW：DNS污染. [Online]. Available: https://gfwrev.blogspot.com/2009/11/gfwdns.html.
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.
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.
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.
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: https://github.com/net4people/bbs/issues/43.
A. Master and C. Garman, “A worldwide view of nation-state Internet censorship,” in Free and Open Communications on the Internet, 2023. [Online]. Available: https://www.petsymposium.org/foci/2023/foci-2023-0008.pdf.
S. Nourin, V. Tran, X. Jiang, K. Bock, N. Feamster, N. P. Hoang, and D. Levin, “Measuring and evading Turkmenistan’s internet censorship,” in The International World Wide Web Conference. ACM, 2023. [Online]. Available: https://dl.acm.org/doi/abs/10.1145/3543507.3583189.
P. Mockapetris, “Domain names - implementation and specification,” RFC 1035, Nov. 1987. [Online]. Available: https://www.rfc-editor.org/info/rfc1035.
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.
A. Bhaskar and P. Pearce, “Many roads lead to Rome: How packet headers influence DNS censorship measurement,” in USENIX Security Symposium. USENIX, 2022. [Online]. Available: https://www.usenix.org/system/files/sec22-bhaskar.pdf.
R. Moskowitz, D. Karrenberg, Y. Rekhter, E. Lear, and G. J. de Groot, “Address allocation for private Internets,” RFC 1918, Feb. 1996. [Online]. Available: https://www.rfc-editor.org/info/rfc1918.
hugsy, “Playing with canaries,” Jan. 2017. [Online]. Available: https://www.elttam.com/blog/playing-with-canaries/#glibc-analysis.
M. Phaedrus, “Some technical details behind the mundane Windows update,” 2022. [Online]. Available: https://great-computing.quora.com/Some-technical-details-behind-the-mundane-Windows-Update-https-www-quora-com-Does-the-Windows-update-use-HTTP-answer.
“MaxMind GeoLite2 geolocation database.” [Online]. Available: https://dev.maxmind.com/geoip/geolite2-free-geolocation-data.
Z. Durumeric, E. Wustrow, and J. A. Halderman, “ZMap: Fast Internet-wide scanning and its security applications,” in USENIX Security Symposium. USENIX, Aug. 2013. [Online]. Available: https://www.usenix.org/conference/usenixsecurity13/technical-sessions/paper/durumeric.
State Council of the People’s Republic of China, “互联网信息服务管理办法 (Measures for the Administration of Internet Information Services),” Sep. 2000. [Online]. Available: https://www.gov.cn/gongbao/content/2000/content_60531.htm.
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.
A. Alaraj, K. Bock, D. Levin, and E. Wustrow, “A global measurement of routing loops on the Internet,” in Passive and Active Measurement. Springer Nature Switzerland, 2023, pp. 373–399. [Online]. Available: https://link.springer.com/chapter/10.1007/978-3-031-28486-1_16.
“IP2Location LITE IP address geolocation database.” [Online]. Available: https://www.ip2location.com/database/ip2location.
CAIDA, “CAIDA AS to organization mapping dataset.” [Online]. Available: https://www.caida.org/catalog/datasets/request_user_info_forms/as_organizations/.
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.
Z. Weinberg, S. Cho, N. Christin, V. Sekar, and P. Gill, “How to catch when proxies lie: Verifying the physical locations of network proxies with active geolocation,” in Internet Measurement Conference. ACM, 2018. [Online]. Available: https://www.contrib.andrew.cmu.edu/~nicolasc/publications/Weinberg-IMC18.pdf.
“IPGeolocation.io IP geolocation API.” [Online]. Available: https://ipgeolocation.io/documentation/ip-geolocation-api.html.
Team Cymru, “Team Cymru IP to ASN lookup v1.0.” [Online]. Available: https://asn.cymru.com/.
Q. Lone. (2022, Apr.) Detecting DNS root manipulation. [Online]. Available: https://labs.ripe.net/author/qasim-lone/detecting-dns-root-manipulation/.
Y. Nosyk, Q. Lone, Y. Zhauniarovich, C. H. Gañán, E. Aben, G. C. M. Moura, S. Tajalizadehkhoob, A. Duda, and M. Korczy´nski, “Intercept and inject: DNS response manipulation in the wild,” in Passive and Active Measurement. Springer Nature Switzerland, 2023. [Online]. Available: https://link.springer.com/chapter/10.1007/978-3-031-28486-1_19.
B. Dong, “A report about national DNS spoofing in China on Sept. 28th,” Dynamic Internet Technology, Inc., Tech. Rep., Oct. 2002. [Online]. Available: https://web.archive.org/web/20021015121616/http://www.dit-inc.us/hj-09-02.html.
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.
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.
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/usenixsecurity17/sec17-pearce.pdf.
klzgrad. (2014, Nov.) DNS compression pointer mutation. [Online]. Available: https://gist.github.com/klzgrad/f124065c0616022b65e5.
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.
T. Kohno, Y. Acar, and W. Loh, “Ethical frameworks and computer security trolley problems: Foundations for conversations,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 5145–5162. [Online]. Available: https://securityethics.cs.washington.edu/.
M. C. Tschantz, S. Afroz, Anonymous, and V. Paxson, “SoK: Towards grounding censorship circumvention in empiricism,” in Symposium on Security & Privacy. IEEE, 2016. [Online]. Available: https://www.eecs.berkeley.edu/~sa499/papers/oakland2016.pdf.
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.
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.
B. Stone-Gross, M. Cova, L. Cavallaro, B. Gilbert, M. Szydlowski, R. Kemmerer, C. Kruegel, and G. Vigna, “Your botnet is my botnet: analysis of a botnet takeover,” in Proceedings of the 16th ACM conference on Computer and communications security, 2009, pp. 635–647. [Online]. Available: https://sites.cs.ucsb.edu/~chris/research/doc/ccs09_botnet.pdf.
A. Mirian, A. Ukani, I. Foster, G. Akiwate, T. Halicioglu, C. T. Moore, A. C. Snoeren, G. M. Voelker, and S. Savage, “In the line of fire: Risks of DPI-triggered data collection,” in Proceedings of the 16th Cyber Security Experimentation and Test Workshop, 2023, pp. 57–63. [Online]. Available: https://arianamirian.com/docs/cset2023_fireye.pdf.
C. Kanich, C. Kreibich, K. Levchenko, B. Enright, G. M. Voelker, V. Paxson, and S. Savage, “Spamalytics: An empirical analysis of spam marketing conversion,” in Proceedings of the 15th ACM conference on Computer and communications security, 2008, pp. 3–14. [Online]. Available: https://www.icir.org/christian/publications/2008-ccs-spamalytics.pdf.
K. 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.
U.S. Government, “Title 32 of the Code of Federal Regulations § 219.102: Definitions,” 2024. [Online]. Available: https://www.ecfr.gov/on/2024-11-27/title-32/subtitle-A/chapter-I/subchapter-M/part-219/section-219.102.

附录A 一个虚假IP地址的有序池示例

以下是拥有Wallbleed漏洞的DNS注入器在伪造对A类和AAAA类查询的响应包时使用的592个IPv4和30个IPv6地址的有序列表，针对查询名称4.tt。其他注入器和其他查询名称的池可能有所不同[8 § 3.2] [9 § 5.2]。当一个注入器进程注入DNS响应包时，它从其有序列表中获取下一个IP地址，到达末尾后循环回到开头。当以足够高的采样率（大约每秒100个数据包或更多）收集注入的响应时，这一事实变得显而易见。每个池中"第一个"地址是我们任意选择的。

我们将有序列表用于两个目的：在第VI-C节中，用于从其他响应中过滤与Wallbleed相关的DNS响应；在第V-B节中，用于分辨每个注入器设备内的多个独立进程。我们将机器可读版本的序列池实例包含在与本文一起发布的数据中。

1): 208.77.47.172
2): 173.252.88.133
3): 173.252.88.67
4): 108.160.170.45
5): 157.240.10.32
6): 174.36.196.242
7): 174.36.228.136
8): 174.37.154.236
9): 174.37.175.229
10): 174.37.54.20
11): 185.60.216.11
12): 185.60.216.50
13): 199.16.158.12
14): 199.16.158.182
15): 199.16.158.8
16): 199.16.158.9
17): 199.59.148.96
18): 199.59.148.229
19): 199.59.148.20
20): 157.240.17.35
21): 31.13.94.37
22): 31.13.68.169
23): 31.13.88.26
24): 31.13.88.169
25): 31.13.94.36
26): 31.13.94.49
27): 31.13.94.41
28): 31.13.94.10
29): 31.13.73.169
30): 31.13.73.9
31): 31.13.112.9
32): 31.13.106.4
33): 31.13.96.195
34): 31.13.82.169
35): 31.13.86.21
36): 31.13.85.169
37): 31.13.85.53
38): 31.13.96.194
39): 31.13.96.208
40): 31.13.96.193
41): 31.13.96.192
42): 31.13.112.4
43): 31.13.80.169
44): 31.13.95.169
45): 104.244.43.136
46): 199.96.61.1
47): 104.244.43.52
48): 104.244.43.6
49): 157.240.0.18
50): 104.244.43.231
51): 104.244.43.35
52): 66.220.148.145
53): 31.13.95.34
54): 31.13.95.48
55): 173.252.105.21
56): 31.13.95.35
57): 157.240.0.35
58): 173.252.108.21
59): 157.240.11.40
60): 104.244.43.167
61): 199.59.150.39
62): 199.59.149.230
63): 199.59.149.208
64): 199.16.158.104
65): 199.16.156.38
66): 96.44.137.28
67): 69.50.221.20
68): 69.30.25.21
69): 69.197.153.180
70): 69.162.134.178
71): 65.49.26.99
72): 65.49.26.98
73): 65.49.26.97
74): 50.23.209.199
75): 199.59.150.45
76): 199.59.150.44
77): 199.59.150.43
78): 199.59.150.40
79): 199.59.150.13
80): 199.59.150.12
81): 199.59.149.239
82): 199.59.149.238
83): 199.59.149.237
84): 199.59.149.236
85): 199.59.149.235
86): 199.59.149.234
87): 199.59.149.232
88): 199.59.149.231
89): 199.59.149.210
90): 199.59.149.207
91): 199.59.149.206
92): 199.59.149.205
93): 199.59.149.203
94): 199.59.149.202
95): 199.59.149.201
96): 199.59.148.9
97): 199.59.148.89
98): 199.59.148.8
99): 199.59.148.7
100): 199.59.148.6
101): 199.59.148.247
102): 199.59.148.246
103): 199.59.148.222
104): 199.59.148.206
105): 199.59.148.202
106): 199.59.148.201
107): 199.59.148.15
108): 199.59.148.147
109): 199.59.148.106
110): 199.59.148.102
111): 199.16.156.75
112): 199.16.156.71
113): 199.16.156.39
114): 199.16.156.11
115): 199.16.156.103
116): 184.72.1.148
117): 182.50.139.56
118): 173.255.213.90
119): 173.255.209.47
120): 173.252.248.244
121): 173.236.212.42
122): 173.236.182.137
123): 173.234.53.168
124): 173.231.12.107
125): 173.208.182.68
126): 168.143.171.93
127): 168.143.171.189
128): 168.143.171.186
129): 168.143.171.154
130): 168.143.162.58
131): 168.143.162.42
132): 128.242.250.157
133): 128.242.250.155
134): 128.242.250.148
135): 128.242.245.93
136): 128.242.245.43
137): 128.242.245.29
138): 128.242.245.253
139): 128.242.245.244
140): 128.242.245.221
141): 128.242.245.212
142): 128.242.245.189
143): 128.242.245.180
144): 128.242.245.157
145): 128.242.245.125
146): 128.242.240.93
147): 128.242.240.61
148): 128.242.240.29
149): 128.242.240.253
150): 128.242.240.244
151): 128.242.240.221
152): 128.242.240.218
153): 128.242.240.212
154): 128.242.240.189
155): 128.242.240.180
156): 128.242.240.157
157): 128.242.240.125
158): 128.121.243.77
159): 128.121.243.76
160): 128.121.243.75
161): 128.121.243.107
162): 128.121.243.106
163): 122.248.226.57
164): 159.106.121.75
165): 59.24.3.173
166): 66.220.146.94
167): 66.220.147.11
168): 66.220.149.18
169): 66.220.149.32
170): 69.171.224.40
171): 69.171.227.37
172): 69.171.228.74
173): 69.171.229.11
174): 69.171.229.73
175): 69.171.234.48
176): 69.171.242.11
177): 69.171.247.32
178): 69.171.247.71
179): 69.63.176.143
180): 69.63.176.15
181): 69.63.176.59
182): 69.63.178.13
183): 69.63.180.173
184): 69.63.181.12
185): 69.63.184.14
186): 69.63.184.142
187): 69.63.184.30
188): 69.63.186.30
189): 69.63.186.31
190): 69.63.187.12
191): 69.63.190.26
192): 67.15.100.252
193): 67.15.129.210
194): 199.16.156.40
195): 199.16.156.7
196): 199.16.158.190
197): 199.59.148.209
198): 199.59.148.97
199): 199.59.149.136
200): 199.59.149.244
201): 199.59.150.49
202): 88.191.249.182
203): 88.191.249.183
204): 208.101.21.43
205): 208.101.60.87
206): 208.43.170.231
207): 208.43.237.140
208): 67.228.102.32
209): 67.228.235.91
210): 67.228.235.93
211): 74.86.118.24
212): 74.86.12.172
213): 74.86.12.173
214): 74.86.142.55
215): 74.86.151.162
216): 74.86.151.167
217): 74.86.17.48
218): 74.86.226.234
219): 74.86.228.110
220): 74.86.3.208
221): 75.126.115.192
222): 75.126.124.162
223): 75.126.135.131
224): 75.126.150.210
225): 75.126.164.178
226): 75.126.33.156
227): 205.186.152.122
228): 64.13.192.74
229): 64.13.192.76
230): 104.16.252.55
231): 104.16.251.55
232): 210.56.51.193
233): 23.234.30.58
234): 210.56.51.192
235): 202.53.137.209
236): 156.233.67.243
237): 154.85.102.32
238): 154.92.16.97
239): 154.83.15.20
240): 154.85.102.30
241): 154.83.15.45
242): 154.83.14.134
243): 103.214.168.106
244): 150.107.3.176
245): 103.97.176.73
246): 103.73.161.52
247): 103.200.31.172
248): 52.175.9.80
249): 159.65.107.38
250): 59.188.250.54
251): 4.78.139.50
252): 93.179.102.140
253): 148.163.48.215
254): 54.89.135.129
255): 4.78.139.54
256): 23.101.24.70
257): 199.193.116.105
258): 162.220.12.226
259): 98.159.108.61
260): 50.87.93.246
261): 47.88.58.234
262): 98.159.108.58
263): 67.230.169.182
264): 159.138.20.20
265): 124.11.210.175
266): 98.159.108.57
267): 111.243.214.169
268): 103.42.176.244
269): 210.209.84.142
270): 107.181.166.244
271): 98.159.108.71
272): 23.225.141.210
273): 114.43.24.59
274): 45.77.186.255
275): 202.182.98.125
276): 45.114.11.25
277): 203.111.254.117
278): 103.240.180.117
279): 45.114.11.238
280): 43.226.16.8
281): 116.89.243.8
282): 80.87.199.46
283): 198.27.124.186
284): 39.109.122.128
285): 103.228.130.27
286): 118.107.180.216
287): 103.97.3.19
288): 103.56.16.112
289): 115.126.100.160
290): 118.193.202.219
291): 118.184.78.78
292): 118.193.240.41
293): 118.184.26.113
294): 103.39.76.66
295): 103.240.182.55
296): 103.230.123.190
297): 103.246.246.144
298): 103.200.30.143
299): 118.193.240.37
300): 198.44.185.131
301): 211.104.160.39
302): 103.228.130.61
303): 122.10.85.4
304): 103.226.246.99
305): 208.31.254.33
306): 50.117.117.42
307): 157.240.15.8
308): 157.240.13.8
309): 157.240.1.33
310): 157.240.12.5
311): 31.13.87.34
312): 31.13.91.33
313): 31.13.90.33
314): 31.13.87.33
315): 31.13.90.19
316): 31.13.95.18
317): 31.13.87.19
318): 31.13.83.34
319): 31.13.84.34
320): 31.13.85.34
321): 31.13.82.33
322): 31.13.76.99
323): 31.13.76.65
324): 31.13.75.12
325): 31.13.71.19
326): 31.13.70.33
327): 157.240.7.5
328): 31.13.70.13
329): 31.13.67.33
330): 157.240.7.8
331): 31.13.92.5
332): 31.13.91.6
333): 31.13.84.2
334): 31.13.87.9
335): 31.13.83.2
336): 31.13.85.2
337): 31.13.75.5
338): 31.13.70.9
339): 104.244.43.57
340): 199.59.149.204
341): 202.160.128.16
342): 199.96.58.15
343): 185.45.6.103
344): 202.160.128.203
345): 104.244.46.165
346): 199.96.63.177
347): 103.252.115.53
348): 104.244.46.17
349): 202.160.128.210
350): 104.244.46.211
351): 202.160.130.52
352): 104.244.46.5
353): 199.96.59.19
354): 104.244.46.85
355): 202.160.129.6
356): 103.252.114.101
357): 103.252.115.59
358): 103.252.115.49
359): 199.96.63.53
360): 192.133.77.197
361): 199.96.62.41
362): 104.244.43.234
363): 202.160.128.40
364): 202.160.128.96
365): 192.133.77.189
366): 202.160.128.14
367): 199.96.59.95
368): 104.244.43.104
369): 192.133.77.191
370): 192.133.77.145
371): 104.244.46.57
372): 185.45.7.185
373): 104.244.46.208
374): 104.244.46.186
375): 104.244.43.208
376): 103.252.114.11
377): 202.160.129.37
378): 199.96.62.75
379): 199.96.58.85
380): 104.244.46.185
381): 185.45.7.97
382): 104.244.46.93
383): 104.244.43.229
384): 104.244.43.182
385): 202.160.128.195
386): 185.45.6.57
387): 199.96.63.163
388): 199.96.58.177
389): 199.96.59.61
390): 199.96.63.75
391): 104.244.46.9
392): 202.160.128.238
393): 104.244.46.21
394): 103.252.115.153
395): 199.96.58.157
396): 192.133.77.59
397): 202.160.128.205
398): 199.96.62.21
399): 202.160.130.118
400): 104.244.43.228
401): 202.160.130.66
402): 185.45.7.189
403): 192.133.77.133
404): 185.45.7.165
405): 202.160.130.145
406): 104.244.43.128
407): 202.160.129.36
408): 103.252.115.221
409): 103.252.114.61
410): 199.96.58.105
411): 103.252.115.169
412): 104.244.46.246
413): 104.244.43.248
414): 104.244.46.63
415): 202.160.130.117
416): 104.244.46.52
417): 199.96.62.17
418): 202.160.129.164
419): 179.60.193.16
420): 157.240.3.50
421): 157.240.16.50
422): 157.240.2.50
423): 185.60.218.50
424): 162.125.83.1
425): 162.125.6.1
426): 162.125.8.1
427): 31.13.95.17
428): 157.240.17.14
429): 157.240.2.36
430): 185.60.216.36
431): 185.60.219.36
432): 157.240.2.14
433): 185.60.216.169
434): 157.240.8.50
435): 157.240.8.41
436): 157.240.3.8
437): 185.60.219.41
438): 157.240.12.50
439): 31.13.95.38
440): 31.13.81.4
441): 31.13.67.19
442): 157.240.6.35
443): 31.13.94.7
444): 157.240.20.18
445): 179.60.193.9
446): 31.13.94.23
447): 31.13.80.54
448): 31.13.69.169
449): 31.13.67.41
450): 31.13.64.7
451): 157.240.21.9
452): 157.240.20.8
453): 157.240.17.41
454): 157.240.18.18
455): 157.240.10.41
456): 157.240.1.50
457): 157.240.12.35
458): 157.240.1.9
459): 173.244.217.42
460): 173.244.209.150
461): 209.95.56.60
462): 31.13.95.37
463): 31.13.80.37
464): 157.240.8.36
465): 157.240.9.36
466): 157.240.17.36
467): 157.240.12.36
468): 157.240.10.36
469): 173.252.108.3
470): 31.13.69.245
471): 104.244.46.244
472): 104.244.45.246
473): 104.244.46.71
474): 162.125.32.6
475): 162.125.18.129
476): 162.125.80.5
477): 162.125.32.10
478): 162.125.17.131
479): 162.125.32.15
480): 162.125.2.6
481): 162.125.80.6
482): 162.125.80.3
483): 162.125.2.3
484): 162.125.34.133
485): 162.125.32.12
486): 162.125.1.8
487): 162.125.18.133
488): 162.125.32.2
489): 162.125.2.5
490): 162.125.32.5
491): 162.125.32.13
492): 162.125.32.9
493): 162.125.82.7
494): 162.125.7.1
495): 119.28.87.227
496): 31.13.95.33
497): 104.23.124.189
498): 104.23.125.189
499): 130.211.15.150
500): 104.31.142.88
501): 38.121.72.166
502): 65.49.68.152
503): 204.79.197.217
504): 54.234.18.200
505): 52.58.1.161
506): 184.173.136.86
507): 174.37.243.85
508): 69.171.224.36
509): 108.160.161.20
510): 108.160.161.83
511): 108.160.162.104
512): 108.160.162.102
513): 108.160.162.109
514): 108.160.162.115
515): 108.160.163.106
516): 108.160.162.98
517): 108.160.162.31
518): 108.160.163.102
519): 108.160.163.112
520): 108.160.163.108
521): 108.160.163.116
522): 108.160.163.117
523): 108.160.165.147
524): 108.160.165.11
525): 108.160.165.139
526): 108.160.165.141
527): 108.160.165.211
528): 108.160.165.173
529): 108.160.165.212
530): 108.160.165.189
531): 108.160.165.48
532): 108.160.165.53
533): 108.160.165.62
534): 108.160.165.8
535): 108.160.165.9
536): 108.160.166.137
537): 108.160.166.253
538): 108.160.166.61
539): 108.160.166.148
540): 108.160.166.42
541): 108.160.166.142
542): 108.160.167.147
543): 108.160.166.49
544): 108.160.166.57
545): 108.160.166.62
546): 108.160.166.9
547): 108.160.167.30
548): 108.160.167.156
549): 108.160.167.148
550): 108.160.167.165
551): 108.160.167.158
552): 108.160.169.171
553): 108.160.167.159
554): 108.160.167.167
555): 108.160.167.174
556): 108.160.169.178
557): 108.160.169.175
558): 108.160.169.174
559): 108.160.169.179
560): 108.160.169.181
561): 108.160.170.39
562): 108.160.170.33
563): 108.160.169.37
564): 108.160.169.185
565): 108.160.169.186
566): 108.160.169.46
567): 108.160.169.55
568): 108.160.169.54
569): 108.160.170.26
570): 108.160.170.41
571): 108.160.170.43
572): 108.160.170.44
573): 108.160.172.1
574): 108.160.170.52
575): 128.121.146.101
576): 108.160.172.200
577): 108.160.172.232
578): 108.160.172.208
579): 108.160.172.204
580): 108.160.173.207
581): 128.121.146.235
582): 128.121.243.228
583): 128.121.146.109
584): 128.121.146.228
585): 128.242.240.20
586): 128.242.240.59
587): 128.121.243.235
588): 128.242.240.117
589): 128.242.240.155
590): 128.242.240.149
591): 128.242.240.85
592): 128.242.240.91

IPv6池中的每个地址都包含模式‘face:b00c’，这是facebook.com真实IP地址的特征。GFW使用互联网公司知名地址的情况在过去已被注意到[8 §3.2]，[9 §5.1]。

1): 2a03:2880:f130:0083:face:b00c:0:25de
2): 2a03:2880:f12c:0083:face:b00c:0:25de
3): 2a03:2880:f12c:0183:face:b00c:0:25de
4): 2a03:2880:f127:0083:face:b00c:0:25de
5): 2a03:2880:f126:0083:face:b00c:0:25de
6): 2a03:2880:f129:0083:face:b00c:0:25de
7): 2a03:2880:f12a:0083:face:b00c:0:25de
8): 2a03:2880:f11f:0083:face:b00c:0:25de
9): 2a03:2880:f127:0283:face:b00c:0:25de
10): 2a03:2880:f11c:8083:face:b00c:0:25de
11): 2a03:2880:f11c:8183:face:b00c:0:25de
12): 2a03:2880:f11b:0083:face:b00c:0:25de
13): 2a03:2880:f11a:0083:face:b00c:0:25de
14): 2a03:2880:f10e:0083:face:b00c:0:25de
15): 2a03:2880:f117:0083:face:b00c:0:25de
16): 2a03:2880:f10c:0083:face:b00c:0:25de
17): 2a03:2880:f112:0083:face:b00c:0:25de
18): 2a03:2880:f111:0083:face:b00c:0:25de
19): 2a03:2880:f10f:0083:face:b00c:0:25de
20): 2a03:2880:f10d:0083:face:b00c:0:25de
21): 2a03:2880:f10d:0183:face:b00c:0:25de
22): 2a03:2880:f10c:0283:face:b00c:0:25de
23): 2a03:2880:f10a:0083:face:b00c:0:25de
24): 2a03:2880:f102:0183:face:b00c:0:25de
25): 2a03:2880:f107:0083:face:b00c:0:25de
26): 2a03:2880:f134:0083:face:b00c:0:25de
27): 2a03:2880:f136:0083:face:b00c:0:25de
28): 2a03:2880:f12d:0083:face:b00c:0:25de
29): 2a03:2880:f134:0183:face:b00c:0:25de
30): 2a03:2880:f131:0083:face:b00c:0:25de

附录B 逆向工程DNS解析和注入算法

下面的 C 代码是我们对导致 Wallbleed 的错误 DNS 查询处理算法进行逆向工程的尝试。该代码在所有重要方面复现了受 Wallbleed 影响的 DNS 注入器的行为。如果PATCHED为false，则代码实现的是Wallbleed v1漏洞；如果为true，则实现的是部分修复的Wallbleed v2（参见第III-C节和第VII节）。

在观察到DNS查询并将其复制到内存后，注入设备解析出QNAME以决定查询是否需要被审查，如果需要则准备一个响应。GFW的实现中存在多个漏洞，其中最严重的是未能对DNS名称标签长度进行边界检查，以确保其不超出消息本身的大小。

 1// 检查msg是否为应被审查的名称的DNS查询。
 2// 如果是，则将msg就地更改为响应并返回响应的长度。
 3// 如果不是，则返回0。
 4size_t response(unsigned char *msg, size_t msg_len)
 5{
 6    if (msg_len < 12 || (msg[2] & 0x80) != 0)如果 msg 太短或不是查询，则不会响应。
 7        return 0;
 8
 9    char qname[126];QNAME 的点分隔、空终止表示将存储在 qname 中。
10    size_t qname_i = 0;
11    // 循环解析QNAME。
12    size_t msg_i = 12;msg_ptr 旨在跟踪 msg_i 并指向循环末尾的 QNAME。
13    unsigned char *msg_ptr;
14    for (;;) {
15        size_t label_len = msg[msg_i++];Bug：没有检查 msg_i 是否在范围内。
16        msg_ptr = &msg[msg_i];将 msg_ptr 与 msg_i 同步。
17
18        if (label_len == 0)退出条件 1：空标签（label）。
19            break;
20        if (msg_i > msg_len)退出条件2：刚刚解析的标签长度前缀超出了结束消息的边界。
21            break;
22
23#if !PATCHED
24        if (qname_i + 1 > 124)退出条件3：没有足够的空间来至少容纳一个字节的标签
（带有一个点和一个空终止符）。
在 qname 后追加一个点，除了在第一个标签之前。
25            break;
26#else
27        msg_i += MIN(label_len, 124 - qname_i);尽可能多地获取标签内容，留出一个点和一个空终止符的空间。
28
29        if (qname_i + label_len > 124)退出条件4：标签太长，无法放入qname中。
Bug：在这种情况下，msg_ptr ≠ msg + msg_i。
30            break;
31#endif
32
33        if (qname_i > 0)如果不是第一个标签，则在qname中追加一个点。
34            qname[qname_i++] = ’.’;
35        size_t n = MIN(label_len, 125 - qname_i);复制尽可能多的标签内容以适应 qname。
Bug：没有检查 msg_ptr + n 是否在范围内。
36        memcpy(qname + qname_i, msg_ptr, n);
37        qname_i += n;
38#if !PATCHED
39        msg_i += n;
40        if (n < label_len)退出条件4：标签太长，无法容纳在qname中。
Bug：在这种情况下，qname_ptr ≠ msg_ptr。
41            break;
42#endif
43    }
44    qname[qname_i] = ’\0’;空终止点分隔的名称字符串。
45
46    if (!name_matches_blocklist(qname))提取的QNAME字符串与阻止列表匹配吗？
如果不匹配，则不发送响应。
47        return 0;
48
49    // 读取QTYPE。.
50    uint16_t qtype  = ntohs(*(uint16_t *) msg_ptr);msg_ptr 可能与此处的 msg_i 不一致。
51#if PATCHED
52    // 读取QCLASS，强制QCLASS == 1。
53    uint16_t qclass = ntohs(*(uint16_t *) (msg_ptr + 2));
54    if (qclass != 1)
55        return 0;
56#endif
57    // 将查询更改为响应。
58    size_t resp_len = msg_i + 4;为查询的QTYPE和QCLASS添加4个字节。
59    if ((msg[2] & 0x01) == 0)如果查询中未设置RD标志，则在响应中设置AD。
60        *(uint16_t *) &msg[2] = htons(0x8400);
61    else如果查询中设置了RD，则在响应中设置RD和RA。
62        *(uint16_t *) &msg[2] = htons(0x8180);
63    *(uint16_t *) &msg[ 4] = htons(1);QDCOUNT = 1
64    *(uint16_t *) &msg[ 6] = htons(1);ANCOUNT = 1
65    *(uint16_t *) &msg[ 8] = htons(0);NSCOUNT = 0
66    *(uint16_t *) &msg[10] = htons(0);ARCOUNT = 0
67    // 根据QTYPE附加一个答案部分。
68    const unsigned char *rdata;
69    uint32_t rdlength;
70    if (qtype == 28) {AAAA类型的查询会得到一个AAAA类型的响应。
71        rdlength = 16;
72        rdata = next_aaaa_address();从循环池中获取下一个IPv6地址。
73    } else {所有其他QTYPE类型都会得到一个A类型的响应。
74        qtype = 1;
75        rdlength = 4;
76        rdata = next_a_address();从循环池中获取下一个IPv4地址。
77    }
78    uint32_t ttl = rand_in_range(64, 254);TTL在64到254之间（包括64和254）随机选择。
79    unsigned char rr[] = {构造一个资源记录。
80        0xc0, 0x0c, // NAME指向QNAME的压缩指针。
81        0, 0,      // TYPE占位符
82        0x00, 0x01, // CLASS = IN
83        0, 0, 0, 0, // TTL占位符
84        0, 0,      // RDLENGTH占位符
85    };
86    *(uint16_t *) &rr[ 2] = htons(qtype);设置QTYPE.
87    *(uint32_t *) &rr[ 6] = htonl(ttl);设置TTL.
88    *(uint16_t *) &rr[10] = htons(rdlength);设置RDLENGTH.
89    memcpy(msg + resp_len, rr, sizeof(rr));将资源记录追加到RDATA。
90    resp_len += sizeof(rr);
91    memcpy(msg + resp_len, rdata, rdlength);追加RDATA（虚假的IP地址）。
92    resp_len += rdlength;
93
94    return resp_len;这个查询会得到一个注入的响应。
95}

我们并不确切知道数据包的载荷在被观察到后是如何存入内存的。例如，它可能是通过软件复制，或者是网络接口的自动 DMA 传输。无论具体过程如何，DNS 注入器的一些细微行为特征，可以用数据包被复制到内存的方式来解释。这些特征包括：内存缓冲区的第 18 个字节始终为零脚注 3；曾经有一段时间，泄露的内存中前 4 个字节与其他部分不同（“摘要”字节，第 IV-B 节）；以及上述 response 函数中的 msg_len 限制来自 UDP 头部，而不是数据包实际可用的字节数（当这两个值不同时）。

 1// 将观察到的UDP数据包载荷复制到内存中进行分析，并可能修改，
 2// 如果它是一个在阻止名单上的DNS查询，则注入一个响应。
 3// hdr_len是UDP头部中代表载荷长度的值（不包括头本身的长度）。
 4 
 5void udp_packet_callback(const void *data, size_t data_len, size_t hdr_len)
 6{
 7    data_len = MIN(data_len, hdr_len);将数据包负载修剪到头部中指定的大小。
 8    void *work = allocate_memory(hdr_len + 28);为查询和响应记录分配内存。
 9    memset(work, 0x00, 18);清除缓冲区开头的内容；请参阅脚注3。
10    memcpy(work, data, data_len);将数据包复制到工作内存中。复制使用 
 data_len，但解析使用 hdr_len。
11
12    if (USE_DIGEST)“Digest”字节(Section IV-B)，如果存在，就
紧接在查询之后。我们使用的是固定字节模式。
13        memset(work + data_len, ’D’, 4);
14    size_t resp_len = response(work, hdr_len);这个数据包是需要响应的DNS查询吗？
15    if (resp_len > 0)如果是，则注入响应。我们省略了伪造源地址等细节。
16        inject(work, resp_len);
17    free_memory(work);
18}

Many Popular Censorship Circumvention Tools Deleted or Archived since November 2, 2023

Thu, 02 Nov 2023 00:00:00 +0000

A significant number of censorship circumvention tools maintained by Chinese developers have been either deleted or archived since Thursday, November 2, 2023 (Beijing Time). These tools have been used by millions of users in China and other heavily censored regions on a daily basis.

As summarized in the table below, this chain of incidents started with the developer @Fndroid deleted the repo Clash For Windows – a highly popular tool with thousands of stars and forks on Github – on Thursday, November 2, 2023 (Beijing Time). This incident was followed by further upheaval on November 3, 2023, as a series of other popular censorship circumvention tools developed by Chinese developers, were either completely deleted, archived, or stripped of all commits across their branches.

We encourage the anti-censorship community to come together for an open dialogue on these emerging incidents, to explore mitigation strategies, and to consider the long-term implications. This collective effort is crucial for developing a resilient response to these incidents.

Project Name	Developer	URL	Repo Status	Archive Link	Date (Beijing Time)
Clash For Windows	@Fndroid	Fndroid/clash_for_windows_pkg	Deleted	Link	Thursday, November 2, 2023
Clash Core	@Dreamacro	Dreamacro/clash	Deleted	Link	Friday, November 3, 2023
GUI.for.Clash	@openrhc	openrhc/GUI.for.Clash	Deleted	Link	Friday, November 3, 2023
clash-dashboard	@Dreamacro	Dreamacro/clash-dashboard	Deleted	Link	Friday, November 3, 2023
Clash Chinese Patch	@BoyceLig	BoyceLig/Clash_Chinese_Patch	Deleted	Link	Friday, November 3, 2023
tpclash	@mritd	mritd/tpclash	Deleted	Link	Friday, November 3, 2023
CatBoxForAndroid	@AntiNeko	AntiNeko/CatBoxForAndroid	Deleted	Link	Friday, November 3, 2023
Fclash	@Fclash	Fclash/Fclash	Deleted	Link	Friday, November 3, 2023
ClashForAndroid	@Kr328	Kr328/ClashForAndroid	Repo Deleted and Remove from Google Play	Link	Friday, November 3, 2023
homebridger	@immortalwrt	immortalwrt/homebridger	Archived + Removed + Set `rm` as the default branch	None	Friday, November 3, 2023
Clash.Meta	@MetaCubeX	MetaCubeX/Clash.Meta	Archived + Set `rm` as the default branch	Link	Friday, November 3, 2023
Clash Verge	@zzzgydi	zzzgydi/clash-verge	Archived + Set `rm` as the default branch	Link	Friday, November 3, 2023
tuic	@EAimTY	EAimTY/tuic	Archived + Cleared the default `master` branch	Link	Friday, November 3, 2023
ClashMetaForAndroid	@MetaCubeX	MetaCubeX/ClashMetaForAndroid	Archived + Set `init` as the default branch	Link	Friday, November 3, 2023
helloworld	@fw876	fw876/helloworld	Clear the default master branch	Link	Friday, November 3, 2023
ShellClash	@juewuy	juewuy/ShellClash	Renamed to `ShellCrash` + Set `rm` as the default branch	Link	Friday, November 3, 2023
ClashCross	@clashcross	clashcross/ClashCross	Archived	Link	Friday, November 3, 2023
ClashX	@yichengchen	yichengchen/clashX	Archived	Link	Friday, November 3, 2023
ClashF	@ModuleList	ModuleList/ClashF	Archived + Set `rm` as the default branch	Link	Friday, November 3, 2023
Box4Magisk	@CHIZI-0618	CHIZI-0618/box4magisk	Archived + Set `rm` as the default branch	Link	Friday, November 3, 2023
Clash For Windows Chinese	@Z-Siqi	Z-Siqi/Clash-for-Windows_Chinese	Archived	Link	Friday, November 3, 2023

In addition:

Clash Multiplatform Alpha Android: The Telegram channel has been cleared and the Telegram group has been deleted.

The table was last updated on November 5, 2023, thanks to the reports and updates from @travislee8964 @clashcross @MuaPyapSrii @al0rid4l @showgood163 @mega-optimus @markpash @wgll000 .

自2023年11月2日起，中国开发者在GitHub上删除或存档翻墙工具

Thu, 02 Nov 2023 00:00:00 +0000

自2023年11月2日星期四（北京时间）以来，由中国开发者维护的大量翻墙工具要么被删除，要么被存档。这些工具曾被来自中国及其他审查严重地区的数百万用户用于绕过审查。

如下表所总结，这一系列事件始于开发者@Fndroid在2023年11月2日删除了其在Github上拥有数千星标和分支的热门工具Clash For Windows的仓库。紧接着在2023年11月3日，更多由中国开发者开发的流行翻墙工具被彻底删除、存档或删除了其分支上的所有提交。

我们鼓励反审查社区一起讨论这些正在发生的事件，探索缓解策略，并思考长期影响。

项目名称	开发者	网址	仓库状态	快照链接	日期（北京时间）
Clash For Windows	@Fndroid	Fndroid/clash_for_windows_pkg	已删除	链接	2023年11月2日星期四
Clash Core	@Dreamacro	Dreamacro/clash	已删除	链接	2023年11月3日星期五
GUI.for.Clash	@openrhc	openrhc/GUI.for.Clash	已删除	链接	2023年11月3日星期五
clash-dashboard	@Dreamacro	Dreamacro/clash-dashboard	已删除	链接	2023年11月3日星期五
Clash Chinese Patch	@BoyceLig	BoyceLig/Clash_Chinese_Patch	已删除	链接	2023年11月3日星期五
tpclash	@mritd	mritd/tpclash	已删除	链接	2023年11月3日星期五
CatBoxForAndroid	@AntiNeko	AntiNeko/CatBoxForAndroid	已删除	链接	2023年11月3日星期五
Fclash	@Fclash	Fclash/Fclash	已删除	链接	2023年11月3日星期五
ClashForAndroid	@Kr328	Kr328/ClashForAndroid	仓库已删除，已从Google Play移除	链接	2023年11月3日星期五
homebridger	@immortalwrt	immortalwrt/homebridger	已存档 + 移除 + 设置`rm`为默认分支	无	2023年11月3日星期五
Clash Verge	@zzzgydi	zzzgydi/clash-verge	已存档 + 设置`rm`为默认分支	链接	2023年11月3日星期五
tuic	@EAimTY	EAimTY/tuic	已存档 + 清除了默认的`master`分支	链接	2023年11月3日星期五
ClashMetaForAndroid	@MetaCubeX	MetaCubeX/ClashMetaForAndroid	已存档 + 设置`init`为默认分支	链接	2023年11月3日星期五
helloworld	@fw876	fw876/helloworld	清除了默认的master分支	链接	2023年11月3日星期五
ShellClash	@juewuy	juewuy/ShellClash	重命名为`ShellCrash` + 设置`rm`为默认分支	链接	2023年11月3日星期五
ClashCross	@clashcross	clashcross/ClashCross	已存档	链接	2023年11月3日星期五
ClashX	@yichengchen	yichengchen/clashX	已存档	链接	2023年11月3日星期五
ClashF	@ModuleList	ModuleList/ClashF	已存档 + 设置`rm`为默认分支	链接	2023年11月3日星期五
Box4Magisk	@CHIZI-0618	CHIZI-0618/box4magisk	已存档 + 设置`rm`为默认分支	链接	2023年11月3日星期五
Clash For Windows Chinese	@Z-Siqi	Z-Siqi/Clash-for-Windows_Chinese	已存档	链接

此外：

Clash Multiplatform Alpha Android（非开源，Telegram 频道已清空，Telegram 群组已被删除。）

该表格最后更新于 2023 年 11 月 5 日。万分感谢 @travislee8964、@clashcross、@MuaPyapSrii、@al0rid4l、@showgood163、@mega-optimus、@markpash、@wgll000 的报告和更新。

The blocking of 1.1.1.1 in China, starting from 2023-10-01

Sun, 01 Oct 2023 00:00:00 +0000

There have been many reports of a blocking of 1.1.1.1 in China, starting from October 1, 2023.

As discussed in a different post on Net4People, China injected TCP RST packets to block 1.1.1.1:443 from September 5 to 20, 2023.

Major observations

Below is our observation from a VPS in Tencent Cloud Beijing (ASN AS45090) on October 1, 2023:

Different from @5e2t ’s observation, we have not been able to observe the TCP RSTs on the 1.1.1.1:443 from our vantage point. In particular, we can successfully retrieve a complete webpage using curl -v https://1.1.1.1. This shows inconsistency of this new censorship incident across different geo-locations or ASes.
We observed that there was a chance that the TCP port 80 of 1.1.1.1 got injected with a "302 Moved Temporarily" or "301 Moved Permanently" message, attempting to redirect users to the National Anti-Fraud Center website (wiki).

Analysis on the injection to `1.1.1.1:80`

Here is one example when no injection happens:

ubuntu@VM-32-5-ubuntu:~$ curl -v http://1.1.1.1
*   Trying 1.1.1.1:80...
* TCP_NODELAY set
* Connected to 1.1.1.1 (1.1.1.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 1.1.1.1
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Server: cloudflare
< Date: Sun, 01 Oct 2023 22:49:54 GMT
< Content-Type: text/html
< Content-Length: 167
< Connection: keep-alive
< Location: https://1.1.1.1/
< CF-RAY: **REDACTED**-SJC
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>cloudflare</center>
</body>
</html>
* Connection #0 to host 1.1.1.1 left intact

This is one example when the "302 Moved Temporarily" got injected.

ubuntu@VM-32-5-ubuntu:~$ curl -v http://1.1.1.1
*   Trying 1.1.1.1:80...
* TCP_NODELAY set
* Connected to 1.1.1.1 (1.1.1.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 1.1.1.1
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Moved Temporarily
< Connection: close
< Location: http://182.43.124.6/fzyujing?parameter2=REDACTED
<
* Closing connection 0

In particular, the redacted parameter in the output consists of 319 characters. Querying from the same vantage point across time, only the 129th to 150th characters (22 characters) and the 257th to 278th characters (22 characters) in the 319 character message got changed. It is still unclear to us what information got encoded in this parameter.

The real 301 Moved Permanently response from the 1.1.1.1 will eventually get to the client (but arrived later than the injected message), indicating the censor doesn’t drop the real response from 1.1.1.1:80.

The ASN of the IP 182.43.124.6 that hosts the National Anti-Fraud Center website:

host	asn	asname	cc	registry
182.43.124.6	AS58519	CHINATELECOM-CTCLOUD Cloud Computing Corporation, CN	CN	apnic

Experiment

We conducted an ongoing experiment from a vantage point in Tencent Cloud Beijing (ASN AS45090). Specifically, we curl https://1.1.1.1 and curl http://1.1.1.1 every minute and capture the network traffic.

Below is an analyis based on the data we collected between Sunday, October 1, 2023 19:54 PM (Beijing Time, UTC+8) and Friday, October 6, 2023 2:43 PM (Beijing Time, UTC+8). In total, we made 6169 HTTP requests. We received 559 HTTP/1.1 301 Moved Permanently injected packets and 1760 HTTP/1.1 302 Moved Temporarily.

This table summarizes all possible values seen in each type of injected responses:

HTTP Status Code	301	302
Total Number of Injections	559	1760
Injection Ratio (over 6169 requests)	9.06%	28.5%
IP ID	0X99b3	0x4c57
IP TTL	251	251
IP Flags	0x0	0x0
TCP Flags	0x18 (PSH+ACK)	0x19 (PSH+ACK+FIN)
TCP Window Size	502	65535

In comparision with @klzgrad ’s observation that:

Injected HTTP/1.1 301 Moved Permanently packets have IP ids of 0x99d1, 0x99d2, 0x99d3, 0x99d4. Injected HTTP/1.1 302 Moved Temporarily packets have IP id of 0x4c57.

We only observed one IP ID value 0x99b3 for the HTTP/1.1 301 Moved Permanently injection, which is dffierent from the four reported values.

They also have consistent TTLs.

We also observed consistent TTLs and its value is the same as the packets sent by the real 1.1.1.1 server.

The figure below shows the number of injections we received in each hour. We send around 60 requests in each hour and the average injection rate for 301 and 302 responses are only 9.06% and 28.5% respectively:

The blocking of 1.1.1.1 in China, starting from 2023-10-01

Sun, 01 Oct 2023 00:00:00 +0000

中国的防火长城自2023年10月1日起封锁了1.1.1.1

Sun, 01 Oct 2023 00:00:00 +0000

自 2023 年 10 月 1 日起，已有许多报告称中国开始屏蔽 1.1.1.1。

在 Net4People的另一篇帖子的讨论中提到，中国在 2023 年 9 月 5 日至 20 日期间通过注入 TCP RST 包来阻断 1.1.1.1:443。

主要观察结果

以下是我们在 2023 年 10 月 1 日，从腾讯云北京（AS45090）的一台 VPS 上的观察：

与 @5e2t 的观察不同，我们未能在 1.1.1.1:443 上看到 TCP RST 注入。尤其是，我们能够使用 curl -v https://1.1.1.1 成功获取完整网页。这表明此次新的审查事件在不同地理位置或不同 AS 之间存在不一致性。
我们观察到，1.1.1.1 的 TCP 端口 80 有可能被注入 "302 Moved Temporarily" 或 "301 Moved Permanently" 消息，试图将用户重定向到国家反诈中心网站（维基）。

对 `1.1.1.1:80` 注入的分析

以下是一个没有注入的例子：

ubuntu@VM-32-5-ubuntu:~$ curl -v http://1.1.1.1
...

这是一个 "302 Moved Temporarily" 被注入的例子：

ubuntu@VM-32-5-ubuntu:~$ curl -v http://1.1.1.1
...

特别地，输出中 已编辑 的参数总共有 319 个字符。从同一观察点跨时间查询时，只有 第129到150个字符（22个字符） 和 第257到278个字符（22个字符） 发生变化。目前尚不清楚该参数编码了什么信息。

来自 1.1.1.1 的真实 301 Moved Permanently 响应最终仍会到达客户端（但比注入消息更晚到达），表明审查方并没有丢弃来自 1.1.1.1:80 的真实响应。

承载国家反诈中心网站的 IP 182.43.124.6 的 ASN：

host	asn	asname	cc	registry
182.43.124.6	AS58519	CHINATELECOM-CTCLOUD Cloud Computing Corporation, CN	CN	apnic

实验

我们在腾讯云北京（ASN AS45090）的一个观察点进行了持续实验。具体来说，我们每分钟执行一次 curl https://1.1.1.1 和 curl http://1.1.1.1，并捕获网络流量。

以下是基于我们在 2023 年 10 月 1 日星期日 19:54（北京时间，UTC+8）到 10 月 6 日星期五 14:43（北京时间，UTC+8）收集到的数据的分析。总共进行了 6169 个 HTTP 请求，其中我们接收到 559 个被注入的 HTTP/1.1 301 Moved Permanently 报文和 1760 个 HTTP/1.1 302 Moved Temporarily 报文。

下表总结了每种注入响应的所有可能值：

HTTP 状态码	301	302
注入总次数	559	1760
注入比例（6169 请求中占比）	9.06%	28.5%
IP ID	0X99b3	0x4c57
IP TTL	251	251
IP Flags	0x0	0x0
TCP Flags	0x18 (PSH+ACK)	0x19 (PSH+ACK+FIN)
TCP 窗口大小	502	65535

与 @klzgrad 的观察对比：

注入的 HTTP/1.1 301 Moved Permanently 报文的 IP ID 为 0x99d1、0x99d2、0x99d3、0x99d4。注入的 HTTP/1.1 302 Moved Temporarily 报文的 IP ID 为 0x4c57。

我们仅观察到 HTTP/1.1 301 Moved Permanently 注入的 IP ID 值为 0x99b3，与报告的四个值不同。

它们也有一致的 TTL。

我们同样观察到 TTL 值一致，并且其值与真实的 1.1.1.1 服务器发出的报文相同。

下图展示了我们每小时接收到的注入数量。我们每小时大约发送 60 个请求，301 和 302 响应的平均注入率仅分别为 9.06% 和 28.5%：

How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic

Fri, 28 Apr 2023 00:00:00 +0000

How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic

Mingshi Wu

GFW Report

Jackson Sippe

University of Colorado Boulder

Danesh Sivakumar

University of Maryland

Jack Burg

University of Maryland

Peter Anderson

Independent researcher

Xiaokang Wang

V2Ray Project

Kevin Bock

University of Maryland

Amir Houmansadr

University of Massachusetts Amherst

Dave Levin

University of Maryland

Eric Wustrow

University of Colorado Boulder

Abstract

One of the cornerstones in censorship circumvention is fully encrypted protocols, which encrypt every byte of the payload in an attempt to “look like nothing”. In early November 2021, the Great Firewall of China (GFW) deployed a new censorship technique that passively detects—and subsequently blocks—fully encrypted traffic in real time. The GFW’s new censorship capability affects a large set of popular censorship circumvention protocols, including but not limited to Shadowsocks, VMess, and Obfs4. Although China had long actively probed such protocols, this was the first report of purely passive detection, leading the anti-censorship community to ask how detection was possible.

In this paper, we measure and characterize the GFW’s new system for censoring fully encrypted traffic. We find that, instead of directly defining what fully encrypted traffic is, the censor applies crude but efficient heuristics to exempt traffic that is unlikely to be fully encrypted traffic; it then blocks the remaining non-exempted traffic. These heuristics are based on the fingerprints of common protocols, the fraction of set bits, and the number, fraction, and position of printable ASCII characters. Our Internet scans reveal what traffic and which IP addresses the GFW inspects. We simulate the inferred GFW’s detection algorithm on live traffic at a university network tap to evaluate its comprehensiveness and false positives. We show evidence that the rules we inferred have good coverage of what the GFW actually uses. We estimate that, if applied broadly, it could potentially block about 0.6% of normal Internet traffic as collateral damage.

Our understanding of the GFW’s new censorship mechanism helps us derive several practical circumvention strategies. We responsibly disclosed our findings and suggestions to the developers of different anti-censorship tools, helping millions of users successfully evade this new form of blocking.

1 Introduction

Fully encrypted circumvention protocols are a cornerstone of censorship circumvention solutions. Whereas protocols like TLS begin with a handshake that comprises plaintext bytes, fully encrypted (randomized) protocols—such as VMess [23], Shadowsocks [22], and Obfs4 [7]—are designed such that every byte in the connection is functionally indistinguishable from random. The idea behind these “looks like nothing” protocols is that they should be difficult for censors to fingerprint and therefore costly to block.

On November 6, 2021, Internet users in China reported blockings of their Shadowsocks and VMess servers [10]. On November 8, an Outline [42] developer reported a sudden drop in use from China [69]. The start of this blocking coincided with the sixth plenary session of the 19th Chinese communist party central committee [4, 1], which was held on November 8–11, 2021. Blocking these circumvention tools represents a new capability in China’s Great Firewall (GFW). To our knowledge, although China has been using passive traffic analysis and active probing together to identify Shadowsocks servers since May 2019 [5], it is the first time the censor has been able to block fully encrypted proxies en masse in real time, completely based on passive traffic analysis. The importance of fully encrypted protocols to the entire anti-censorship ecosystem and the mysterious behaviors of the GFW motivate us to explore and understand the underlying mechanisms of detection and blocking.

In this work, we measure and characterize the GFW’s new system for passively detecting and censoring fully encrypted traffic. We find that, instead of directly defining what fully encrypted traffic is, the censor applies at least five sets of crude but efficient heuristics to exempt traffic that is unlikely to be fully encrypted traffic; it then blocks the remaining non-exempted traffic. These exemption rules are based on common protocol fingerprints, a crude entropy test using the fraction of set bits, and the fraction, position, and maximum contiguous count of ASCII characters in the first TCP payload.

Due to the black-box nature of the GFW, our inferred rules may not be exhaustive; however, we evaluate our inferred rules on real-world traffic from a network tap at CU Boulder, and provide evidence that our rules have significant overlap with the GFW’s. We also find that the inferred detection algorithm would block roughly 0.6% of all connections on our network tap. Possibly to mitigate over-blocking caused by false positives, our Internet scans show that the GFW strategically only monitors 26% of connections and only to specific IP ranges of popular data centers.

We also analyze the relationship between this new form of passive censorship and the GFW’s well-known active probing system [5], which operate in parallel. We find that the active probing system also relies on this traffic analysis algorithm but has additional packet length-based rules applied. Consequently, the circumvention strategies that can evade this new blocking will also prevent the GFW from identifying and subsequently active-probing the proxy servers.

We derive various circumvention strategies from our understanding of this new censorship system. We responsibly and promptly shared our findings and circumvention suggestions with the developers of various popular anti-censorship tools, including Shadowsocks [22], V2Ray [59], Outline [42], Lantern [20], Psiphon [21], and Conjure [33]. These circumvention strategies have been widely adopted and deployed since January 2022, helping millions of users bypass this new censorship. As of February 2023, all circumvention strategies these tools adopted are reportedly still effective in China.

2 Background

2.1 Traffic Obfuscation Strategies

Tschantz et al. divide approaches to obfuscating censorship circumvention traffic into two types: steganograpic and polymorphic [57, § V]. The goal of steganographic proxies is to make circumvention traffic look like allowed traffic; the goal of polymorphism is to make circumvention traffic not look like forbidden traffic.

The two most common approaches to achieving steganography are mimicking and tunneling. Houmansadr et al. [39] conclude that mimicking a protocol is fundamentally flawed and suggest that tunneling through allowed protocols be a more censorship-resistant approach. Frolov and Wustrow [35] demonstrate that even when a tunneling approach is used, it still requires effort to perfectly align protocol fingerprints with popular implementations, in order to avoid blocking by protocol fingerprints. For instance, in 2012, China and Ethiopia deployed deep packet inspection to detect Tor traffic by its uncommon ciphersuits [44, 67, 55]. Censorship middlebox vendors have previously identified and blocked meek [29] traffic based on on its TLS fingerprint and SNI value [28].

To avoid this complexity, many popular proxies opt for polymorphic designs. A common way to achieve polymorphism is to fully encrypt the traffic payload, starting from the first packet in a connection. Without any plaintext or fixed header structure to fingerprint, the censor cannot easily identify proxy traffic with regular expressions or by looking for specific patterns in traffic. This design was first introduced in Obfuscated OpenSSH in 2009 [16]. Since then, it has been employed by Obfsproxy [24], Shadowsocks [22], Outline [42], VMess [23], ScrambleSuit [68], Obfs4 [7], and partially used in Geph4 [58], Lantern [20], Psiphon3 [21], and Conjure [33].

Fully encrypted traffic is often referred to as “looks like nothing” traffic, or misunderstood as “having no characteristics”; however, a more accurate description would be “looks like random”. In fact, such traffic does have an important characteristic that sets it apart from other traffic: Fully encrypted traffic is indistinguishable from random. Since there are no identifiable headers, traffic will have high entropy homogeneously throughout the entire connection, even in the first data packet. By contrast, even encrypted protocols like TLS have relatively low-entropy handshake headers that convey supported versions and extensions.

In 2015, Wang et al. [61, §5.1] used the length and high Shannon entropy of the first packet payload in a connection to identify randomized traffic, like Obfs4. Similarly, in 2017, Zhixin Wang released a proof-of-concept tool that used the high Shannon entropy of the first three packets’ payloads in a connection to identify Shadowsocks traffic [40]. Madeye extended the tool to additionally use the payload length distribution to detect ShadowsocksR traffic [47]. He et al. [70, §IV.A] and Liang et al. [46, §II.A] used a single-bit frequency detection algorithm, rather than the Shannon entropy, to measure the randomness of Obfs4 traffic. In 2019, Alice et al. found that the GFW was using the length and entropy of the first data packet in each connection to suspect Shadowsocks traffic [5].

2.2 Active Probing Attacks and Defenses

In active probing attacks, the censor sends well-crafted payloads to a suspected server and measures how it responds. If the server responds to these probes in an identifiable way (e.g. lets the censor use it as a proxy), the censor can block it. As early as August 2011, the GFW was observed to send seemingly random payloads to foreign SSH servers that accepted SSH logins from China [49]. In 2012, the GFW first looked for a unique TLS ciphersuit to identify Tor traffic; it then sent active probes to the suspected servers to confirm its guess [67, 66, 64]. In 2015, Ensafi et al. conducted a detailed analysis of the GFW’s active probing attacks against various protocols [27]. Since May 2019, China has deployed a censorship system to detect and block Shadowsocks servers in two steps: It first uses the length and entropy of the first packet payload in each connection to passively identify possible Shadowsocks traffic, and then sends various probes, in different stages, to the suspected servers to confirm its guess [5]. In response, researchers proposed various defenses against active probing attacks, including consistent server reactions [34, 9] and application fronting [45, 36]. Shadowsocks, Outline, and V2Ray have incorporated probe-resistant designs [34, 5, 19, 43, 32, 71], making them unblocked in China since September 2020 [5], until the recent blocking in November 2021 [10].

3 Methodology

We crafted and sent various test probes between hosts inside and outside of China, letting them be observed the GFW. We observed the GFW’s reactions by capturing and comparing traffic on both endpoints. This logging allows us to identify any dropped or manipulated packets, as well as active probes.

Experiments	Time Span	China Vantage Points	US Vantage Points	Sections

Characterization	Nov. 6, 2021 – May 18, 2022 (6 months)	3 (TC, BJ),1 (Ali, BJ)	3 (DO, SFO)	§4
Re-running	Feb. 16, 2023 (1 day)	1 (TC, BJ)	1 (DO, SFO)	§4.1,§4.2,§4.3
Active Probing	May 19 – Jun. 8, 2022 (3 weeks)	1 (TC, BJ)	2 (DO, SFO)	§5
Internet Scan	May 12–13, 2022 (2 days)	9 (TC, BJ)	1 (Scan, Univ)	§6
Live Traffic	Jul. – Sept., 2022 (3 months)	1 (TC, BJ)	1 (DO, SFO), 1 (Tap, Univ)	§7

Table 1: Experiment timeline and vantage points — In total, we used one VPS in AlibabaCloud (Ali) Beijing (AS37963), ten VPSes in TencentCloud (TC) Beijing (AS45090), four VPSes in DigitalOcean (DO) San Francisco (AS14061), and two machines at the University of Colorado Boulder (Univ) (AS104).

Experiment timeline and Vantage points. We summarized the timeline and vantage point usage of all major experiments in Table 1. In total, we used ten VPSes in TencentCloud Beijing (AS45090) and one VPS in AlibabaCloud Beijing (AS37963). We did not observe any differences in the censoring behavior between our vantage points within China or any affected external vantage points. We used four VPSes in DigitalOcean San Francisco (AS14061): three of them were affected by the new censorship, the other one was not. We turned these four VPSes into sink servers; that is, the servers listen on all ports from 1 to 65535 to accept TCP connections, but do not send any data back to the client. We also employed two machines in the CU Boulder (AS104) for Internet scanning and live traffic analysis. We checked the IP addresses of our VPSes against IP2Location database [3], confirming their geo-locations are as reported by their providers.

Triggering censorship. Because fully encrypted traffic is indistinguishable from random data , beyond using actual circumvention tools, we developed measurement tools that send random data to trigger blocking in our study. The tools initiate a TCP handshake, send a random payload of a given length, and then close the connection.

Using residual censorship to confirm blockings. Similar to how the GFW blocks many other protocols [13, 17, 63, 14], after a connection triggers the censorship, the GFW blocks all subsequent connections having the same 3-tuple (client IP, server IP, server port) for 180 seconds. This residual censorship allows us to confirm blocking by sending follow-up connections from the same client to the same port of the server. We make five TCP connections one by one with a one-second interval in between. If all five connections failed, we conclude that the 3-tuple is blocked. Once a 3-tuple is blocked, we do not use it for further tests in the next 180 seconds.

Accouting for probabilistic blocking with repeated tests. We often had to make multiple connections with the same payload before we observed blocking. In Section 6.3, we explain that this is because the GFW employs a probabilistic blocking strategy, where censorship is only triggered approximately a quarter of the time. To account for this probabilistic behavior, we send the same payload in up to 25 connections before drawing any blocking (or not blocking) conclusion. If we can successfully make 25 connections with the same payload in a row, then we conclude that the payload (or server) is not affected by this censorship. If after sending the payload at least once, a sequence of 5 subsequent connection attempts timeout (due to residual censorship), we label the payload (and server) as affected by censorship. We use this method of repeated connections to measure blocked payloads in all the tests throughout our study.

4 Characterizing the New Censorship System

We conduct experiments to understand how the GFW detects and blocks fully encrypted connections. Detailed in Table 1, between Nov 6, 2021 and May 18, 2022, we used three VPSes in China and three sink servers in the US to conduct our experiments. During the same period, we also used one VPS in AlibabaCloud Beijing (AS37963) to repeat all our experiments. We did not observe any differences in the censoring behavior among our vantage points within China or any affected external vantage point. On February 16, 2023, we reran our experiments and confirmed all detection rules still held. This time, we used one VPS in TencentCloud BJ and one sink server in DigitalOcean SFO.

Algorithm 1 presents a high-level overview of the GFW’s detection rules we inferred, and Figure 1 illustrates examples of these inferred rules in action. While we cannot infer the order in which these rules get applied or if they are exhaustive, our experiments confirm specific components of the GFW’s censorship strategy. We find that, instead of directly defining what fully encrypted traffic is, the censor applies at least five sets crude but efficient heuristic rules to exempt traffic that is unlikely to be fully encrypted traffic; it then blocks the remaining non-exempted traffic. These exemption rules are based on common protocol fingerprints, a crude entropy test using the fraction of bits set, and the fraction, position, and maximum contiguous count of ASCII characters.

Algorithm 1: The GFW uses at least five heuristic rules to detect and block fully encrypted traffic. The censor applies this algorithm to TCP connections sent from China to certain IP subnets and employs probabilistic blocking (Section 6).

Allow a connection to continue if the first TCP payload ($\mathtt {pkt}$) sent by the client satisfies any of the following exemptions:

Ex1: $\frac {\mathit {popcount}(\mathtt {pkt})}{\mathit {len}(\mathtt {pkt})} \le 3.4$ or $\frac {\mathit {popcount}(\mathtt {pkt})}{\mathit {len}(\mathtt {pkt})} \ge 4.6$.
Ex2: The first six (or more) bytes of $\mathtt {pkt}$ are $[\mathtt {0x20},\mathtt {0x7e}]$.
Ex3: More than 50% of $\mathtt {pkt}$’s bytes are $[\mathtt {0x20},\mathtt {0x7e}]$.
Ex4: More than 20 contiguous bytes of $\mathtt {pkt}$ are $[\mathtt {0x20},\mathtt {0x7e}]$.
Ex5: It matches the protocol fingerprint for TLS or HTTP.

Block if none of the above hold.

4.1 Entropy Exemption (`Ex1`)

We observed that the fraction of bits set influences whether a connection is blocked. To determine this, we sent repeated connections to our server and observed which were blocked. In each connection, we sent one of 256 different byte patterns, consisting of 1 byte repeated 100 times (e.g., \x00\x00\x00..., \x01\x01\x01..., ..., \xff\xff\xff...). We sent each pattern in 25 connections to our server, and observed if any patterns resulted in blocking subsequent connections, indicating the payload triggers blocking. We found 40 byte patterns triggered blocking , while the remaining 216 patterns did not. Example patterns that were blocked include \x0f\x0f\x0f..., \x17\x17\x17..., and \x1b\x1b\x1b...(and 37 others).

All of the blocked patterns consist of bytes with exactly 4 (out of 8) bits that were $1$ (for instance, \x1b in binary is 00011011). We hypothesized that the number of set bits ($1$ bits) per byte may play a role, as uniformly random data will have close to the same number of total $1$s and $0$s in binary. In effect, this is essentially measuring the entropy of the bits within the client’s packet.

We confirmed this by sending combinations of bytes that were individually allowed, but together resulted in being blocked. For example, both \xfe\xfe\xfe... and \x01\x01\x01... were not blocked individually, but these bytes sent together as \xfe\x01\xfe\x01... resulted in blocking. We note \xfe\x01 has 8 (out of 16) bits set to $1$ (an average of 4 bits per byte set), while \xfe has 7 out of 8, and \x01 has 1 of 8 set, explaining why individually they are allowed, but together they are blocked.

Of course, random or encrypted data will not always have exactly half of the bits set to $1$. We tested how close to half the GFW needed in order to block, by sending a sequence of 50 random bytes (400 bits) with an increasing number of bits set. We produced 401 bitstrings with 0–400 bits set to $1$, and shuffled each string, yielding a set of random strings with 0–8 bits set per byte (in increments of 0.02 bits/byte). For each string, we made 25 connections and sent the string to observe if it triggered subsequent connections to be blocked. We found that all strings with $\le 3.4$ or $\ge 4.6$ bits/byte set were not blocked, while strings with between 3.4 and 4.6 bits/byte set were blocked.

There was a single exception to this for a string with 4.26 bits/byte set, which we determined was not blocked due to having over 50% of its bytes be printable ASCII characters; we show next this is an exemption rule (Ex2). We repeated our experiment and confirmed that other strings with the same number of bits set with less printable ASCII are indeed blocked.

In summary, we find that the GFW exempts a connection if the fraction of bits set in the client’s first data packet deviates from half. This corresponds to a crude measure of entropy: random (encrypted) data will have close to half of the bits set to $1$, while other protocols usually have fewer $1$ bits per byte due to plaintext or zero-padded protocol headers. For instance, Google Chrome version 105 sends a TLS client hello with an average of only 1.56 bits set per byte, falling outside the censorship range, owing to padding with zeros.

Figure 1: Examples of GFW’s traffic exemption rules — The GFW exempts a TCP connection if the payload of its first data packet matches any of the rules above. Traffic not exempted by any of the rules will be blocked. Printable characters refer to any character in range $[\mathtt {0x20},\mathtt {0x7e}]$. Figures 1(a) , 1(b) , and 1(c) are introduced in Section 4.2. Figure 1(e) is introduced in Section 4.3. Figure 1(d) is introduced in Section 4.1.

(a) First six printable exemption (Ex2): the GFW exempts a connection if the first six bytes (or more) are all printable.

(b) Half printable exemption (Ex3): the GFW exempts a connection if its first payload has more than 50% printable ASCII.

(c) Contiguous printable exemption (Ex4): the GFW counts the max number of contiguous printable bytes, and exempts a connection if the value is more than 20 bytes.

(d) Popcount exemption (Ex1: the GFW calculates the average number of bits set (popcount) per byte as a crude measure of entropy, and exempts a connection if the value is less than 3.4 or greater than 4.6.

(e) Protocol exemption (Ex5): the GFW exempts a connection if its first few bytes match HTTP or TLS protocol.

4.2 ASCII Characters Exemption (`Ex2-4`)

We observed several exceptions to the bit counting rule we discovered in Section 4.1. For instance, the pattern \x4b\x4b\x4b... was not blocked, despite having exactly 4 bits set per byte. Indeed, there are actually 70 characters (8 choose 4) that have exactly 4 bits set, but our analysis found that only 40 of those triggered censorship. What about the other 30?

These other 30 byte values all fall within the byte range that comprises the printable ASCII characters , 0x20–0x7e. We conjecture that the GFW exempts characters presumably to allow “plaintext” (human-readable) protocols.

We found three ways in which the GFW exempts connections based on printable ASCII characters in the first packet payload from the client: if the first six bytes are printable (Ex2); if more than half of the bytes are printable (Ex3); or if it contains more than 20 contiguous printable bytes (Ex4).

First six bytes are printable (Ex2). We observe that the GFW exempts blocking if the first 6 bytes of a connection fall within the printable byte range 0x20–0x7e. If there are characters outside this range in the first 6 bytes, then a connection may be blocked, assuming it does not have other exempting properties (for example, fewer than 3.4 bits per byte set). We tested this by generating messages where the first $n$ bytes were sourced from different character sets (such as ASCII printable characters) and the rest of the message would be random unprintable characters. We find that for $n < 6$, we observe censorship, but for $n \ge 6$ where the first $n$ bytes are ASCII printable characters, no blocking occurs.

Half of the first packet are printable (Ex3). If more than half of all bytes in the first packet fall into the printable ASCII range 0x20–0x7e, the GFW exempts the connection. We tested this by sending packets consisting of 10 bytes of characters outside this range (e.g. 0xe8), followed by a repeating sequence of 6 bytes: 5 within the range (e.g., 0x4b), and one outside. We repeat this 6 byte sequence 5 times, and then pad the end of the string with $n$ bytes outside the range (in Python notation: "\xe8"*10 + ("\x4b"*5 + "\xe8")*5 + "\xe8"*n). This experiment gives us a variable-length pattern that decreases the fraction of bytes in the printable ASCII range as we increase $n$. We find that for $n < 10$, connections are not blocked, while for $n \ge 10$ they are. This corresponds to blocking when the fraction of printable characters is less than or equal to half, and not blocking when greater than half.

We design our probes to avoid triggering other GFW exemptions, such as bit counts (Ex1), printable prefixes (Ex2), or runs of printable characters (Ex4). For example, we use 0x4b and 0xe8 as our printable and non-printable characters respectively, since they both have exactly 4 bits set. This prevents the GFW from exempting our connection from blocking due to the bit count rule (Ex1) discussed previously. In addition, we avoid having contiguous runs of printable 0x4b characters, as we observed that such runs can also exempt a connection from blocking, which we discuss next. We repeated our experiments with other patterns that also met these constraints (e.g. 0x8d and 0x2e), and observed the same results.

More than 20 contiguous bytes are printable (Ex4). A contiguous run of printable characters can also exempt blocking, even if the total fraction of printable characters is less than half. To test this, we sent a pattern of 100 bytes of a character outside the printable range (0xe8) with a varying number of contiguous bytes from the printable range (we used 0x4b). Our payload started with 10 bytes of 0xe8, followed by $n$ bytes of 0x4b, and then $90-n$ bytes of 0xe8, for a total length of 100 bytes. We varied $n$ from 0–90, and sent each of the 91 payloads in 25 connections to our server. We found that with $n \le 20$, the connection was blocked. For $n > 20$, the connection was not blocked, indicating the presence of a run of printable characters exempts blocking. Of course, past $n > 50$, the connection will also be exempt, because of Ex3.

Other encodings. We tested whether Chinese characters in the first packet were exempted from blocking in the same way as printable ASCII characters did. We used strings of 6–36 Chinese characters encoded in UTF-8, as well as GBK (identical to GB2312 for the character we used). All of these tests were blocked, suggesting that there is no exemption for Chinese characters. It is possible that the presence of Chinese characters in these encodings is rare, or that parsing these encodings adds unjustified complexity since it is hard to know where an encoded string starts or ends.

4.3 Common Protocols Exemption (`Ex5`)

To avoid blocking popular protocols by mistake, we observe that the GFW explicitly exempts two popular protocols. The GFW appears to infer protocols from the first 3–6 bytes of the client’s packet : If they match the bytes of a known protocol, the connection is exempted from blocking, even if the rest of the packets do not conform to the protocol. We tested six common protocols and found that the TLS and HTTP protocols are explicitly exempted. This list may not be exhaustive, as there may be other exempted protocols we did not test.

TLS. TLS connections start with a TLS Client Hello message, and the first three bytes of this message cause the GFW to exempt the connection from blocking. We observe that the GFW exempts any connection whose first three bytes match the following regular expression:

[\x16-\x17]\x03[\x00-\x09]

This corresponds to the one-byte record type, followed by a two-byte version. We enumerated all 256 patterns of XX\x03\x03 followed by 97 bytes of random data, and found all patterns were blocked except those that start with either 0x16 (corresponding to the Handshake TLS record type, used in the Client Hello) or 0x17 (corresponding to the Application Data record type). While normal TLS connections do not begin with Application Data [53, 52], when TLS is used over Multipath-TCP (MPTCP) [31], it is common for one of the TCP subflows to be used for the Client Hello and for other subflows to send Application Data immediately after the TCP connection is established [15]. As of today, only TLS versions 0x03[0x00-0x03] have been defined [53, 52], but the GFW allows even later (not yet defined) versions.

HTTP. The byte pattern used by the censor to identify HTTP traffic is simply the method followed by a space. If a message starts with GET␣, PUT␣, POST␣, or HEAD␣, the connection will be exempt from blocking. The space character (0x20) after each verb is necessary to exempt connections from blocking. Not including this space character, or replacing it with any other byte will not exempt the connection. The other HTTP methods (OPTIONS␣, DELETE␣, CONNECT␣, TRACE␣, PATCH␣) fall into the ASCII printable exemption (Ex2), as the first 6 bytes are printable characters. We find that the method is case-insensitive: GeT␣, get␣, and similar variations are exempt. Typos in the verb (e.g., TEG␣) are not exempt.

Non-exempted protocols. We tested other common protocols: SSH, SMTP, and FTP would be exempt as they all start with at least 6 bytes of printable ASCII (rule Ex2). DNS-over-TCP is exempt due to containing a large fraction of zeros, making it exempt by the Ex1 rule. However, if a large enough amount of random data was appended after a DNS-over-TCP message, it would be blocked.

This observation raises the question of why the censor has explicit rules to exempt TLS and HTTP, but not other protocols. After all, the censor does not need to exempt these two protcols explicitly: HTTP will commonly be exempt by printable ASCII for the first 6 bytes (rule Ex2), and TLS Client Hello messages have relatively low bit-wise entropy (rule Ex1), owing to many zero fields. Nonetheless, the censor may employ these simple but efficient rules to quickly exempt the bulk of traffic (TLS and HTTP) from the more in-depth analysis of calculating the popcount, fraction of ASCII, etc.

4.4 How the GFW Disrupts Connections

Once the GFW detects fully encrypted traffic using Algorithm 1, it blocks the subsequent traffic as introduced below.

Packets are dropped from client to server. We triggered the GFW’s blocking and compared the captured packets from both the sending client and receiving server. We observe that after triggering blocking, the client’s packets are dropped by the GFW, and do not reach the server. However, packets sent by the server are not blocked and are still received at the client.

UDP traffic is not affected. The new censorship system is limited to TCP. Sending a UDP datagram with a random payload cannot trigger the blocking. Additionally, once a 3-tuple (client IP, server IP, server Port) is blocked due to a triggering TCP connection, UDP datagrams to or from the same (server IP, server Port) are not affected. Because of the absence of UDP blocking, users may experience odd behavior while using Shadowsocks: they can still access websites or use apps that rely on UDP (e.g. QUIC or FaceTime), but cannot access websites that use TCP. This is because Shadowsocks proxies TCP traffic with TCP and proxies UDP traffic with UDP. Not detecting or blocking UDP traffic may reflect the censor’s worse is better engineering mindset. From a practical view, the current TCP blocking can already effectively paralyze these popular circumvention tools, while employing UDP censorship requires additional resources and invites extra complexity to the censorship system.

Traffic on all ports can get blocked. We set up a sink server listening on all ports from 1 to 65535 in US. We then let our client in China continuously make connections with 50-byte random payloads to each port of the US server and stop when a port got blocked. We find that blocking can happen on all ports from 1 to 65535. Therefore, running circumvention servers on an unusual port cannot mitigate the blocking. We also do not observe any difference in censor’s behaviors among ports.

Figure 2: Residual censorship duration — When we repetitively send 50-byte random data to 500 ports of a single server simultaneously, the residual censorship time decreases dramatically. About 40% of the blockings lasted only 10 s, shorter than the 180 s duration when only one port was blocked. This suggests that the GFW may limit the number of connections it residually blocks at any given time.

The duration of residual censorship is affected by the number of on-going residual blocking. We find that once this new censorship system blocks a connection, it continues to drop all subsequent TCP packets having the same 3-tuple (client IP, server IP, server port) for 120 or 180 seconds. This behavior is often referred to as “residual censorship” [13, 17, 63, 14]. Unlike some other residual censorship systems [13], the GFW’s residual censorship timer does not reset when additional packets are sent.

We also find that the GFW seems to limit the number of connections it residually blocks at any given time. We let our clients in China repetitively make connections to 500 ports of a single server simultaneously. In each connection, the client sent 50 bytes of random data and then closed the connection. We recorded the duration of each occurrence of residual censorship. As shown in Figure 2, in comparison to the 180 s duration when only one port is blocked, the residual censorship duration in this experiment decreased dramatically.

4.5 How the GFW Reassembles Flows

In this section, we examine how the GFW’s new censorship system reassembles flows and considers flow directions.

A complete TCP handshake is necessary. We observe that sending a SYN packet followed by a PSH+ACK packet containing random data (without the server completing its end of the handshake) is not sufficient to trigger blocking. The blocking is thus harder to exploit for residual censorship attacks [13].

Only client-to-server packets can trigger the blocking. We find that the GFW not only checks if the random data is sent to a destination IP address that falls in an affected IP range, it also examines and will only block if the random data is sent from client to server. The server here is defined as the host that sends a SYN+ACK during the TCP handshake.

We learned this by setting up four experiments between the same two hosts. In the first experiment, we let the Chinese client connect and send random data to the foreign server; in the second experiment, we still let the Chinese client connect to the foreign server, but let the foreign server send random data to client; in the third experiment, we let the US client connect and send random data to Chinese server; in the forth experiment, we let the US client connect to the Chinese server, but then let the Chinese server send random data to the US client. Only connections in the first experiments were blocked.

The GFW only examines the first data packets. The GFW appears to only analyze the first data packet in a TCP connection, without reassembling the flows with multiple data packets. We tested this with the following experiment. After a TCP handshake, we send the first data packet with only one byte of payload \x21. After waiting for one second, we then send the second data packet with a 200-byte random payload. We repeated the experiment 25 times, but the connections never got blocked. This is because after seeing the first data packet, the GFW had already exempted the connections by rule Ex1 as it contained 100% printable ASCII in the payload. In other words, if the GFW reassembled multiple packets into a flow during its traffic analysis, it would have been able to block these connections.

We found that the GFW does not wait until seeing an ACK response from the server to block a connection. We configured our server to drop any outgoing ACK packets with an iptables rule. We then made connections with 200-byte random payloads to the server. The GFW still blocked these connections though the server never sent any ACK packets.

The GFW waits more than 5 minutes for the first data packets. We examine how long the GFW monitors a TCP connection after the TCP handshake, but before it sees the first data packet. From the observation that it requires a complete TCP handshake to trigger the blocking, we infer the GFW may be stateful. It is thus reasonable to suspect the GFW only monitors a connection for a limited amount of time, as it can be expensive to maintain a state forever without expiring it.

Our client completed TCP handshakes and then waited for 100, 180, or 300 seconds, before sending 200 bytes of random data. We then repeated the experiment but used iptables rules to drop any RST or TCP keepalive packets in case they helped the GFW keep the connection state active. We found that these connections still triggered blocking, suggesting the GFW maintained connection states for at least five minutes.

5 Relation with the Active Probing System

Crafted Payload	Affected Server	Unaffected Server
	# connections	# probes	# connections	# probes
2-byte random (\xfe\x01)	33k	0	169k	0
50-byte random	29k	0	169k	0
200-byte random	33k	141	169k	679
"GET " + 50-byte random	170k	0	169k	0
\x16\x03\x03 + 50-byte random	170k	0	169k	0
\x17\x03\x03 + 50-byte random	170k	0	169k	0
"GET " + 50-byte random	170k	0	169k	0
\x16\x03\x03 + 200-byte random	170k	0	169k	0
\x17\x03\x03 + 200-byte random	170k	0	169k	0
Low bit counting (2.5)	170k	0	169k	0
High bit counting (5.2)	170k	0	169k	0
More than half printable	170k	0	169k	0
First six bytes printable + 200-byte random	170k	0	169k	0
More than 20 contiguous bytes	170k	0	169k	0

Table 2: Number of connections received from our controlled client and number of active probes received from the GFW. Between May 19, 2022 and June 8, 2022, our client repetitively sent the same 14 payloads from a VPS in Tencent Cloud Beijing datacenter in China, to 14 ports of two different hosts in the DigitalOcean San Francisco datacenter in US. One US host is known to be affected by the current blocking system, while the other US host is unaffected. In total, our client in China repetitively sent around 170k connections to each port of the two US servers. The only exception is, when the residual censorship was triggered and the client could not make connections to the affected server, the total number of successful legitimate connections was around 33k.

As introduced in Section 2.2, the GFW has been sending active probes to Shadowsocks servers since 2019 [5]. In this section, we study the relationship between this newly discovered real-time blocking system and the existing active probing system. By conducting designed measurement experiments and analyzing historical datasets, we show that while these two censorship systems work in parallel, the current traffic analysis module of the active probing system applies all five sets of exemption rules summarized in Algorithm 1 and Figure 1, with one additional rule that examines the payload length of the first data packet. We also show evidence that the traffic analysis algorithm used by the active probing system [5] may have evolved since 2019.

Active probing experiment. Prior to the deployment of this new real-time blocking system, inferring the traffic analysis algorithm of the active probing system was extremely challenging, if possible at all. This is because the GFW employs an arbitrary delay between seeing a triggering connection and sending active probes [5, §3.5], making it difficult to account for which probes by the GFW are triggered by which connections we send. Now that we have inferred a list of traffic detection rules of this new blocking system in Section 4, we can test if a payload exempted by Algorithm 1 will also not get suspected by the active probing system.

We conducted the experiments between May 19, 2022 and June 8, 2022. As shown in Table 2, we crafted 14 different types of payloads: three of them are random data with lengths of 2, 50, and 200 bytes; the remaining 11 were data with various lengths that will only be exempted by exactly one of the exemption rules in Algorithm 1. We then sent the same 14 payloads from a VPS in Tencent Cloud Beijing China, to 14 ports of two different hosts in DigitalOcean San Francisco US. One US host is known to be affected by the current blocking system, while the other US host is unaffected. This way, if we received any probes from the GFW, we know certain exemption rules used by the current blocking system are not used by the active probing system.

In total, our client in China sent around 170k connections to each port of the two US servers. We then took steps to isolate the GFW’s probes from other Internet scanners’. We check the source IP address of each probe against IP2Location database [3] and AbuseIPDB [2]. We do not consider it as a probe from the GFW if it was a non-Chinese IP or from a known spammer IP address. We further check if the probe belongs to any known types of probes sent by the GFW.

The two systems work independently. The new censorship machine makes its blocking decisions purely based on passive traffic analysis, without relying on China’s well-known active probing infrastructure [67, 5, 66, 64, 27]. We know this because, while the GFW still sends active probes to the servers, in more than 99% of the tests, the GFW did not send any active probes to the server before blocking a connection. For example, as summarized in Table 2, we made 33,119 connections but only received 179 active probes. Indeed, similar to the findings by prior work [5, §4.2], active probes are rarely triggered.

We want to emphasize that this finding does not mean that defenses against active probing are not necessary or not important anymore [34, 5, 9]. On the contrary, we believe that the GFW’s reliance on purely passive traffic analysis is partially because Shadowsocks, Outline, VMess, and many other censorship circumvention implementations have adopted effective defenses against active probing [34, 5, 9, 19, 43, 32, 71]. The fact that the GFW still sends active probes to servers implies that the censor still attempts to use active probing to accurately identify circumvention servers whenever possible.

The active probing system applies the five exemption rules, with one additional length rule, to suspect traffic. This experiment suggests two points. First, similar to the findings by Alice et al. [5, §4.2], the active probing system applies an additional rule to examine the length of the connection. In our case, only connections with 200-byte payloads ever triggered the active probing, not ones with 2 bytes or 50 bytes. Second, the traffic exempted by any of the five rules discovered in Algorithm 1 will also not trigger the active probing system.

The active probing system has evolved since 2019. We want to know if the same detection rules in Algorithm 1 were historically used to trigger active probing. To analyze it, we obtained 282 payloads that got replayed (and thus once triggered the GFW) in the low-entropy experiment from Alice et al. [5, §4.1]. We then wrote a program to determine if a payload would be exempted by the current blocking system, and fed the program with the obtained 282 payloads. As a result, 45 probes that previously triggered active probing were exempted (by rule Ex3). On May 19, 2022, we repeatedly sent these 45 payloads through the GFW, confirming that they were indeed exempted from the current blocking. For each payload, we made 25 connections with it from a VPS in TencentCloud Beijing to a sink server in DigitalOcean SFO. This result suggests that the GFW has likely updated the traffic analysis module of its active probing system since 2020. In addition, the probes sent by the current GFW are also different from those observed in 2020 [5, §3.2]. The new probes are essentially random payloads that are distributed in trios of 16, 64, and 256 bytes. For each of these lengths, the GFW sent about the same number of probes: 48, 46, and 47 to one server, and 238, 228, and 233 to the other.

6 Understanding the Blocking Strategies

In this section, we conduct measurement experiments to characterize the censor’s blocking strategies. We find that, possibly to mitigate false positives and reduce operation costs, the censor strategically limits the scope of blocking to specific IP ranges of popular data centers, and it applies a probabilistic blocking strategy to 26% of all connections to these IP ranges.

6.1 Internet Scanning Experiment

On May 12, 2022, we performed a 10% IPv4 Internet scan on TCP port 80, from a server located at CU Boulder. Following prior work that identifies unreliable hosts in Internet scans [41], we remove IPs that respond with a TCP window of 0 (as we cannot send them data), or do not accept a subsequent connection. This leaves us with 7 million scannable IPs. We then randomly and equally split these 7 million IP addresses into nine subsets, and assigned each to our nine vantage points in TencenCloud Beijing datacenter. We then used a measurement program we wrote and installed in all nine vantage points for the experiment. For each IP, the program connects to its port 80 sequentially up to 25 times, with a one-second interval in between. In each connection, we send the same 50 bytes of random data that can trigger the blocking. If we see 5 consecutive connections time out (fail to connect) after we have sent data, we label the IP as affected. Otherwise, if all 25 connections succeed, we label the IP as unaffected. We label IPs that we cannot connect to at all as unknown (e.g., the server is down, or a network failure unrelated to the GFW prevents us from connecting in the first place).

We also repeated this process but sent 50 bytes of \x00, which does not trigger blocking by the GFW. If a server is marked as affected in this test, it is likely due to the server blocking us, and not the GFW, and we remove these IPs from our results. This leaves just over 6 million IPs.

Finally, we remove “ambiguous” results that may be due to intermittent network failures or unreliable vantage points. Specifically, we remove IPs that either of our random or zero scans labelled unknown (we were never able to connect), or had intermittent connection timeouts (e.g., several connections timed out, but not 5 consecutively). This leaves 5.5 million IPs that we can easily label as unaffected (all 25 connections succeeded) or affected (at some point it appeared blocked after we sent random data).

6.2 Not All Subnets/ASes are Affected Equally

Figure 3: Affected fraction of ASes and prefixes — For each AS (and /20 prefix), we calculate the fraction of GFW-affected IPs over all tested IPs in it, and plot the CDF. We can see that only a small fraction of ASes are affected, and most subnets are “all-or-nothing” (either the entire subnet’s IPs are affected, or few to none are).

Figure 4: Top affected ASNs — We observe that not all ASes are affected, and even within each AS, different prefixes are affected differently. For each AS, we looked at each /20 in their network, and calculated the fraction of IPs blocked in each /20 subnet. The results were very close to all-or-nothing: either all IPs in a /20 were affected, or none were.

Of the 5.5 million processed IPs, 98% of them are unaffected by the GFW’s blocking, suggesting that China is fairly conservative in employing this new censorship. We group these 5.5 million IP addresses into their allocated IP prefixes and ASes, using pyasn with an AS database from April 2022 [51]. For IP prefixes larger than /20, we break the allocation into a set of /20 prefixes to keep allocations roughly the same size. Our 5.5 million IPs comprise 538 unique ASes that have at least 5 results, and the vast majority of these are largely unaffected by the GFW’s blocking.

Figure 3 shows the distributions of the fraction of affected ASes and /20 prefixes. We found that more than 90% ASes are affected in an all-or-nothing way: either all IP addresses we tested in the AS are affected by the GFW’s blocking, or no IP addresses we tested in the AS are unaffected. We also observe that only a few ASes are affected: over 95% of ASes see less than 10% of their IPs affected, and only 7 ASes see more than 30% of their IPs affected.

Figure 4 shows the top affected ASes. While this is skewed toward larger ASes (which have more IPs in our scan), it shows both ASes that are heavily affected (e.g., Alibaba US, Constant) and ones that are not (Akamai, Cloudflare). In addition, some ASes have a mix of affected and not affected prefixes (Amazon, Digital Ocean, Linode). All of the affected or partly-affected ASes we see are popular VPS providers that could be used to host proxy servers, while large unaffected ASes do not typically sell VPS hosting to individual customers (e.g. CDNs).

6.3 Characterizing Probabilistic Blocking

As introduced in Section 3, we send up to 25 connections with the same payload before drawing any conclusions about blocking. This is necessary because the censor implements blocking probabilistically. In other words, just sending a random payload to an affected server once would only sometimes trigger blocking; however, if one keeps making connections with the same payload to the affected server, blocking will occur eventually. This raises the question on what the probability is for a connection to get blocked, and why the censor implements blocking only probabilistically.

Estimating the blocking rate. From our 10% Internet scan (Section 6.2), there were 109,489 IP addresses that we label as blocked. As shown in Section 5, the distribution of the number of successful random data connections we can make to each IP address before getting blocked fits a geometric distribution. This result suggests that the blocking of each connection is independent, with a probability of $26.3\%$.

Why probabilistic blocking is used. We conjecture that the censor employs probabilistic blocking possibly for two reasons: First, it allows the censor to only examine one-fourth of connections, reducing computation resources. Second, it helps the censor reduce the collateral damage to non-circumvention connections. While this reduction also comes at the expense of lower true positives, the residual censorship may make up for it: once a connection is determined to be blocked, subsequent connections are also blocked for several minutes after, making it difficult for proxy users to successfully connect once detected. This may also further support prior claims that censors put more emphasis on reducing their false positive rate than in achieving a high true positive rate [57].

Figure 5: CDF of the number of successful connections from our client in China to each of 109,489 affected IP addresses before getting blocked. We made up to 25 connections to port 80 of each IP address. The distribution fits a geometric distribution, suggesting the blocking of each connection is independent, with a probability of $p=26.3\%$.

7 Evaluating the GFW’s Detection Rules

In this section, we evaluate the false positive rate and comprehensiveness of the GFW’s detection rules we inferred in Section 4. To determine the impact this blocking may have on regular traffic, we simulate the inferred detection rules to traffic on our university network without actually blocking any traffic. Different from the GFW, we simulate the detection rules against all TCP connections observed without limiting the detection to 26% of connections to specific IP ranges of popular data centers. We expect to see little to no circumvention traffic in this network, and any traffic that would be blocked under detection rules likely represents false positive blocking. We find that the inferred detection algorithm would block roughly 0.6% of all connections on our network. Due to the black-box nature of the GFW, our inferred rules may only be a subset of what the GFW uses; however, we show that all connections that Algorithm 1 would block were indeed blocked when we sent their prefixes along with random data through the GFW, suggesting our inferred rules have good coverage of what the GFW uses.

7.1 Traffic Analysis Experiment

We have access to a 40 Gbps network tap at CU Boulder that allows us to process copies of all incoming and outgoing packets on our campus. Using this, we collected a dataset comprising only destination port numbers and the first 6 bytes of payload data for connections that do not already satisfy the other exemption rules in Algorithm 1. More precisely, we implemented a custom packet analysis tool using PF_RING [50]. For each connection, we inspected the first data packet sent by the client. We ensured that the packet has a correct TCP checksum, and that its sequence number is the first expected data packet after the TCP handshake in the connection (making sure we have not missed the first data packet). For connections that are not exempted by Algorithm 1—i.e., those we expect to be blocked—we logged the destination port and the first six bytes of the connection to help identify its protocol.

We performed this collection between July 2022 and September 2022. In total, we analyzed 1.7 billion connections and logged 442,928 unique 6-byte prefixes of would-be-blocked connections. For each of these 442,928 6-byte prefixes, we append the same 194-byte random data to it to make a 200-byte payload. We then repetitively sent each payload past the real GFW in September 2022, to test whether they were indeed blocked, or if instead there were exemptions we had not previously identified. For each payload, we made up to 25 connections with it from a VPS in TencentCloud Beijing to a sink server in DigitalOcean SFO.

7.2 Experiment Results and Analysis

Estimating the false positive rate. In total, we analyzed 1.7 billion connections on our network between July 2022 and September 2022. For each connection, we determine which rules in Algorithm 1 would exempt it from being blocked. As shown in Figure 6, we observe on average that 0.6% of TCP connections from our tap would be blocked under the GFW’s detection rules we inferred.

Figure 6: Common exemptions — For each connection on CU Boulder tap, we determine which rules in Algorithm 1 would exempt it from being blocked. We divide the exemption rule Ex5 in Section 4.3 into 3-, 4-, and 5-byte patterns and present them in three rows for fine-grained classification. We analyze 1.7 billion connections collected from July 2022 until September 2022. For brevity, this graph only shows intersections with a count greater than 1,000,000. We observe 37 different intersections of exemptions in the full set.

There are at least two strategies the censor employs to reduce the false positive rate. First, as introduced in Section 6, the GFW only applies this censorship to a fraction of IP subnets. This decision may be an attempt to mitigate the base-rate problem faced by the censor [11]. Since relatively few connections in total are proxy connections, even a small false positive rate (such as 0.6%) would result in blocking mostly benign traffic, if applied broadly. By narrowing the scope of IPs it is applied to, China can reduce the collateral damage of its censorship. Second, as explored in Section 6.3, even for traffic towards this subset of IP subnets, the GFW is observed to block only about one-quarter of all traffic, reducing the false positive rate to one-fourth.

It is possible that the 0.6% of connections we identified may be fully encrypted proxies. To investigate this possibility, we keep a count of the number of unique 6-byte prefixes we see in each connection that would be blocked under the GFW’s rules. If these connections are all truly fully encrypted proxies, we would expect to see a uniform distribution over the $256^6$ possible 6-byte values. Otherwise, if there are 6-byte values that occur frequently, it could be headers of popular protocols, indicating false positives in the GFW’s blocking.

Figure 7: The first 6-bytes of blocked connections — For the 9.7 million (0.6%) connections from our tap that would be blocked under the GFW rules we inferred, we count the occurences of their unique first 6-bytes. The most popular 6-byte prefix appears in over 479 thousand connections (5.0%), meaning a rule that explicitly allowed this 6-byte value could reduce the GFW’s false-positive rate by this amount.

Figure 7 shows the distribution of the first 6 bytes of all 9.7 million connections from our tap that would be blocked under the GFW rules we inferred. In addition, Table 3 shows the top 6-byte values from would-be blocked connections. While we are not able to identify many of these protocols, their frequency along with the low entropy indicates that they are not likely to be fully encrypted proxies.

Bytes in hex	Port	Occurences
45 44 00 01 00 00	5222	479K	5.0%
ee 2f 8c ec 40 d1	8000	427K	4.4%
00 00 00 00 00 00	50386	104K	1.1%
00 c4 71 58 64 51	443	34K	0.4%
00 c4 71 42 30 6e	443	33K	0.3%
0e 53 77 61 72 6d	7680	32K	0.3%
1b 00 04 c6 27 53	8886	32K	0.3%
c6 e6 cd ed 00 00	33445	29K	0.3%
00 01 00 00 0f 00	443	27K	0.3%
16 f1 04 00 a1 00	80	12K	0.1%

Table 3: Ten most common first six bytes of blocked connections — We record the first six bytes of all connections that we simulate as blocked on the CU Blouder network. In this data, we find repeated six bytes and display the top ten, the most common port it appeared on, and the respective percentage of the total simulated blocked connections.

Estimating the comprehensiveness of the inferred rules. Among the 442,928 payloads we crafted and sent past the real GFW, we found only one prefix got exempted by the GFW, which alerted us to the TLS Application Data prefix exemption (\x17\x03[\x00-\x09]). We added this exemption to our inferred rules (Ex5). This result suggests our inferred rules have good coverage of what the GFW uses.

8 Circumvention Strategies

Our understanding of this new censorship system allows us to derive multiple circumvention strategies. In Section 8.1 and Section 8.2, we introduce two widely adopted countermeasures that have been helping users in China bypass censorship since January 2022 and October 2022, respectively. We discuss other circumvention strategies in Section A. We responsibly and promptly shared our findings and suggestions with the developers of various popular anti-censorship tools that have millions of users, which we detail in Section 8.3.

8.1 Customizable Payload Prefixes

The exemption rules Ex2 and Ex5 from Algorithm 1 only look at the first several bytes in a connection, allowing the GFW to efficiently exempt non-fully encrypted traffic; however, this lends itself to a potential countermeasure. Specifically, we propose prepending a customizable prefix to the payload of the first packet in a (circumvention) connection.

Customizable IV header. Shadowsocks connections begin with an Initialization Vector (IV), which is of length 16 or 32 bytes depending on the encryption ciphers [22]. As introduced in Section 4.2, turning the first six (or more) bytes of the IVs into printable ASCII will exempt connections by the rule Ex2. Similarly, turning the first three, four, or five bytes of the IVs into common protocol headers will exempt connections by the rule Ex5 (e.g., turning the first three bytes of an IV into 0x16 0x03 0x03). These countermeasures require minimal changes to the client and no changes to the server, and therefore has been adopted by many popular circumvention tools [72, 62, 48, 56]. Restricting the first few bytes of a 32-byte IV to be printable ASCII will not reduce the randomness to the point that affects the security of encryption. For example, even fixing the first six bytes to printable ASCII still leaves the IVs with 26 random bytes, which is still more than a typical 16-byte IV.

Limitations. This is a stopgap solution and could potentially be blocked by the censor fairly easily. The censor may skip the first several bytes and apply the detection rules to the rest data in a connection. Protocol mimicry is also difficult in practice [39]. The censor can enforce stricter detection rules, or actively probe a server to check if it is genuinely running TLS or HTTP. Nevertheless, the fact that this strategy still works as of February 2023, more than one year since its adoption by many popular circumvention tools in January 2022, underscores that even simple solutions can be effective against finite-resourced censors [8, 57, 30].

8.2 Altering Popcount

As introduced in Section 4.1, the GFW exempts a connection if its first data packet has an average popcount-per-byte $\le 3.4$ or $\ge 4.6$ (Ex1). Based on this observation, one can increase (decrease) the popcount by inserting additional ones (zeroes) into the packet to bypass censorship. We introduce and analyze a flexible scheme that alters the popcount-per-byte to any given value or range. We implemented this scheme on Shadowsocks-rust [54] and Shadowsocks-android [6], helping users in China bypass censorship since October 2022 [8]. In January 2023, a large-scale circumvention service in China (that asked not to be named), also implemented a version of this scheme and found similar success.

At a high level, we take original fully-encrypted packets as input: By operating only on the ciphertexts, we do not risk violating confidentiality. When sending a packet, we first compute its average popcount-per-byte; if the value is greater than 4, then we determine how many one-bits we would have to add to the packet in order to obtain a popcount over 4.6. Conversely, if the popcount is less than 4, then we determine how many zero-bits we would have to add to decrease the popcount to less than 3.4. In either case, we append the necessary number of one- or zero-bits to the original ciphertext and then append 4 bytes denoting the number of bits added, ultimately giving us a bit-string $B$ that has a popcount-per-byte that would not subject it to censorship.

Of course, simply appending ones or zeroes would be easy to fingerprint. To address this, we do bit-level random shuffling. In particular, we leverage the existing shared secrets, such as password, as a seed to deterministically construct a permutation vector. In each connection, we update this permutation vector and use it to shuffle all the bits in the bit-string $B$ before sending it. To decode, the receiver first updates the permutation vector and then uses it to un-shuffle the bit-string; then it reads the last 4 bytes to determine the number of bits added, removes that number of bits, and is thus able to recover the original (fully encrypted) packet.

In practice, we take two additional steps to further obfuscate the traffic. Since it is an obvious fingerprint if all connections share the same popcount-per-byte value, we set the goal value to a parameterizable range. Second, since the 4-byte length tag in plaintext may be a fingerprint, we encrypt it (the same way these circumvention tools encrypt proxy traffic).

This scheme has several advantages. First , the scheme supports parameterizable popcount-per-byte in case the GFW updates its popcount rule to block an even larger range. Second , because of its careful design, there are no obvious fingerprints that would signal to the censor that this is a popcount-adjusted packet. Finally , it incurs low overhead; it adds only as many ones (or zeroes) strictly necessary (padded to the nearest byte). In the worst case—increasing the popcount from 4 to 4.6—this incurs only about 17.6% overhead. As a result, it could feasibly be applied not just to the first packet, but to every packet in the connection, thereby insulating it against future updates to the censor that might look past the first packet.

8.3 Responsible Disclosure

On November 16, 2021, ten days after the GFW employed this new blocking [10], we revealed details of this new blocking to the public [37, 38]. With the development of our understanding of this new blocking, we derived and evaluated different circumvention strategies. We responsibly and promptly shared our findings and suggestions with the developers of various popular anti-censorship tools that have millions of users , including Shadowsocks [22], V2Ray [59], Outline [42], Lantern [20], Psiphon [21], and Conjure [33]. Below we introduce our disclosure and the responses from the anti-censorship community in detail.

On January 13, 2022, we shared our first circumvention strategy with a group of developers. This solution, detailed in Section 8.1, requires minimal code changes to the clients and no changes to the servers. By January 14, 2022, Shadowsocks-rust developer zonyitoo, V2Ray developer Xiaokang Wang and Sagernet developer nekohasekai had already added this circumvention solution as an option to their clients [72, 62, 48]. On October 4, 2022, database64128 implemented a user-customizable version of this strategy on Shadowsocks-go [18]. On October 25, 2022, Outline developers adopted a highly customizable solution for their client [56]. On October 14, 2022, we released a modified Shadowsocks [8] that employed the popcount-altering strategy we detailed in Section 8.2.

As of February 14, 2023, all circumvention strategies adopted by these tools are reportedly still effective in China. In January 2023, Outline developers reported that the number of Outline servers (that opted-in for anonymous metrics) had doubled since they adopted the mitigation above. In January 2023, a large circumvention service provider in China (that asked not to be named at this time) also implemented our proposed scheme and has also found success.

While we did not study countries other than China, our proposed circumvention strategies are reported to be also working in Iran, another country that reportedly blocks and throttles fully encrypted proxies [65]. On February 13, 2023, Lantern developers reported that the adopted protocol “accounted for the majority of our Iran traffic” since January 2023. On February 13, 2023, a different circumvention service provider reported that, after enabling Outline’s mitigation feature in November 2022, their services turned from being completely blocked to serving 850k daily users from Iran.

9 Ethics

Censorship measurement research carries an element of risk and responsibility which we take seriously. Our research involves handling sensitive network traffic, scanning large numbers of hosts, and performing network measurements in a sensitive country. Due to the sensitive nature of this work, we approached our institution’s IRB with our detailed research plan for review. While the IRB determined that the work does not involve human subjects (and thus does not require IRB review), we have designed and implemented extensive precautionary efforts to minimize potential risks and harms. In this section, we discuss these risks and detail the precautionary measures we adopted to manage and mitigate them.

Traffic analysis. We worked closely with our university’s network operators, who have extensive experience in managing such projects, to deploy our network measurement tool to ensure it is within the network use policy and respects user privacy. We design our experiments to avoid collecting potentially sensitive information, such as IP addresses, which could reveal human identifiable information. We collect minimal information and focus on tracking aggregate statistics to avoid potentially identifying individuals. Specifically, we only analyzed the very first TCP data packet in each connection and ignored any subsequent packets. In addition, we only logged the first six bytes of data and keep an aggregate count of their occurrences; no raw traffic was ever inspected by a human nor logged. We practiced the least privilege principle, giving only a subset of our team access to this data.

Internet scanning. To minimize the risk of overwhelming servers when performing Internet-wide scans, we followed the best practices outlined in prior work in Internet scanning and widescale censorship measurement [26, 60]. We set up a dedicated webpage, along with a reverse DNS to it, on port 80 of our scanning host at CU Boulder. The webpage explains what data our scanning collects, and offers ways to opt out of future scans. During our entire experiment period, we received and honored seven removal requests, which is typical based on past experiences scanning the Internet [25, §5.3] [26, §5.1]. Our follow-up scans to these servers were low-bandwidth: we sent less than 100 bytes for each request, and each server only performed one connection at a time to avoid overwhelming their network or connection pool resources.

The use of vantage points. Active censorship measurement from within censored countries requires additional considerations and prudent evaluation. We first explored the possibility of performing the measurement remotely but confirmed that this censorship could not be triggered from outside of China. While it may be low risk to have sensitive queries observed by the censor, we follow similar standards discussed in prior work to limit the number of these sensitive queries we send [5]. In particular, we only send queries on port 80 to servers that are listening on that port, and made no concurrent connections to the same server to avoid overwhelming server operations.

Our research team consulted experts with a deep understanding of the nature and legal concerns of Chinese censorship, who helped us make informed decisions on which VPS providers to use and how to use them. We selected two large-scale VPS providers run by well-known commercial companies in order to avoid any potential legal risks to individuals. We registered our VPSes with the accurate identity and contact information of one of our researchers who is neither a citizen of nor resides in China. We received no complaints from the providers throughout our research. As done in prior work [5], we do not inform these large VPS providers of the experiments ahead of time, to avoid potential experiment bias (e.g. interference in results) or placing potential legal obligations or burdens on the VPS providers.

We manage the risk of potentially getting any server blocked by the GFW temporarily or in the long term. For all hosts we controlled in this study, we assigned dedicated IP addresses to them to avoid blocking shared IP addresses. In addition, we rented our non-censoring network hosts from a VPS provider that permits censorship circumvention usage and even offers automatic installation of circumvention tools. Similar to the findings in prior work on residual censorship in China [13, 17, 63, 14], we tested using our own servers and confirmed that the GFW never blocked any of our machines’ IP addresses for more than 180 seconds, and the blocking only affected traffic from our clients to the servers, without interfering with traffic from others’. Knowing that our servers were used for five months but never experienced any long-term blocking, we proceeded to perform our large-scale scans.

10 Conclusion

In this work, we exposed and studied China’s latest censorship system that dynamically blocks fully encrypted traffic in real time. This powerful new form of censorship has affected many mainstream circumvention tools partially or in full, including Shadowsocks, Outline, VMess, Obfs4, Lantern, Phiphon, and Conjure. We conducted extensive measurements to infer various properties about the GFW’s traffic analysis algorithm and evaluated its comprehensiveness and false positives against real-world traffic. We use our knowledge of this new censorship system to derive effective circumvention strategies. We responsibly disclosed our findings and suggestions to the developers of different anti-censorship tools, helping millions of users successfully evade this new form of blocking.

Acknowledgments

We thank our shepherd and other anonymous reviewers for their valuable comments and feedback. We also thank the brave users in China for immediately reporting the blocking incidents to us. We are grateful to Benjamin M. Schwartz, zonyitoo, nekohasekai, database64128, AkinoKaede, Max Lv, Mygod, DuckSoft, and many other developers from the anti-censorship community for their prompt patches, assistance, and discussions. We express our sincere appreciation to Outline developer, Vinicius Fortuna, at Jigsaw for offering insightful suggestions and assisting us in reaching out to the community. We thank Lantern developers Adam Fisk and Ox Cart for sharing the deployment experience of their tool in Iran. We also thank Milad Nasr for his informative input. We appreciate klzgrad sharing thoughtful comments on an earlier draft of the paper. We are also deeply grateful to David Fifield for providing a proof-of-concept patch against obfs4, contributing to the discussions, providing constructive feedback and suggestions on an earlier draft of the paper, and offering guidance and support throughout the entire study.

This work was supported in part by NSF grants CNS-1943240, CNS-1953786, CNS-1954063 and CNS-2145783, by the Young Faculty Award program of the Defense Advanced Research Projects Agency (DARPA) under the grant DARPA-RA-21-03-09-YFA9-FP-003, and by DARPA under Agreement No. HR00112190125. The views, opinions, and/or findings expressed are those of the authors and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government. Approved for public release; distribution is unlimited.

Availablity

To maintain reproducibility and encourage future research, we released our source code and data: https://gfw.report/publications/usenixsecurity23/en.

References

19th Central Committee of the Chinese Communist Party. https://en.wikipedia.org/wiki/19th_Central_Committee_of_the_Chinese_Communist_Party .
Abuseipdb. https://www.abuseipdb.com/ .
Ip2location lite data. http://www.ip2location.com/ .
Sixth Plenary Session of the 19th CPC Central Committee. https://zh.wikipedia.org/zh-cn/中国共产党第十九届中央委员会第六次全体会议 .
Alice, Bob, Carol, Jan Beznazwy, and Amir Houmansadr. How China detects and blocks Shadowsocks. In Internet Measurement Conference . ACM, 2020. https://censorbib.nymity.ch/pdf/Alice2020a.pdf .
Shadowsocks android developers. Shadowsocks-android. https://github.com/shadowsocks/shadowsocks-android .
Yawning Angel et al. Obfs4 specification. https://gitlab.com/yawning/obfs4/blob/master/doc/obfs4-spec.txt .
Anonymous and Amonymous. Sharing a modified Shadowsocks as well as our thoughts on the cat-and-mouse game, October 2022. https://github.com/net4people/bbs/issues/136 .
Anonymous, Anonymous, Anonymous, David Fifield, and Amir Houmansadr. A practical guide to defend against the GFW’s latest active probing, January 2021. https://github.com/net4people/bbs/issues/58 .
Anonymous, Vinicius Fortuna, David Fifield, Xiaokang Wang, Mygod, moranno, et al. Properly configured shadowsocks servers reportedly blocked in china, November 2021. https://github.com/net4people/bbs/issues/69#issuecomment-962666385 .
Stefan Axelsson. The base-rate fallacy and its implications for the difficulty of intrusion detection. In Proceedings of the 6th ACM Conference on Computer and Communications Security , pages 1–7, 1999. https://www.cse.psu.edu/~trj1/cse543-f16/docs/Axelsson.pdf .
Kevin Bock. Iran: A new model for censorship, March 2020. https://geneva.cs.umd.edu/posts/iran-whitelister/ .
Kevin Bock, Pranav Bharadwaj, Jasraj Singh, and Dave Levin. Your censor is my censor: Weaponizing censorship infrastructure for availability attacks. In Workshop on Offensive Technologies . IEEE, 2021. http://www.cs.umd.edu/~dml/papers/weaponizing_woot21.pdf .
Kevin Bock, iyouport, Anonymous, Louis-Henri Merino, David Fifield, Amir Houmansadr, and Dave Levin. Exposing and circumventing China’s censorship of ESNI, August 2020. https://github.com/net4people/bbs/issues/43#issuecomment-673322409 .
Olivier Bonaventure. MPTLS : Making TLS and Multipath TCP stronger together. Internet-Draft draft-bonaventure-mptcp-tls-00, Internet Engineering Task Force, October 2014. https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-tls/00/ .
brl. Obfuscated OpenSSH. https://github.com/brl/obfuscated-openssh .
Zimo Chai, Amirhossein Ghafari, and Amir Houmansadr. On the importance of encrypted-SNI (ESNI) to censorship circumvention. In Free and Open Communications on the Internet . USENIX, 2019. https://www.usenix.org/system/files/foci19-paper_chai_update.pdf .
database64128. taint: add unsafe stream prefix, October 2022. https://github.com/shadowsocks/shadowsocks-org/issues/204#issuecomment-1266710067 .
database64128, zonyitoo, Xiaokang Wang, and nekohasekai. Shadowsocks 2022 Edition: Secure L4 Tunnel with Symmetric Encryption, October 2022. https://github.com/net4people/bbs/issues/58 .
Lantern developers. Lantern. https://github.com/getlantern .
Psiphon3 developers. Psiphon3. https://psiphon.ca/ .
Shadowsocks developers. Shadowsocks aead cihpher specification. https://shadowsocks.org/guide/aead.html .
VMess developers. Vmess. https://www.v2fly.org/en_US/developer/protocols/vmess.html .
Roger Dingledine. Obfsproxy: the next step in the censorship arms race. https://blog.torproject.org/obfsproxy-next-step-censorship-arms-race , February 2012.
Zakir Durumeric, Michael Bailey, and J. Alex Halderman. An Internet-Wide view of Internet-Wide scanning. In 23rd USENIX Security Symposium (USENIX Security 14) , pages 65–78, San Diego, CA, August 2014. USENIX Association. https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/durumeric .
Zakir Durumeric, Eric Wustrow, and J. Alex Halderman. ZMap: Fast internet-wide scanning and its security applications. In 22nd USENIX Security Symposium (USENIX Security 13) , pages 605–620, Washington, D.C., August 2013. USENIX Association. https://www.usenix.org/conference/usenixsecurity13/technical-sessions/paper/durumeric .
Roya Ensafi, David Fifield, Philipp Winter, Nick Feamster, Nicholas Weaver, and Vern Paxson. Examining how the Great Firewall discovers hidden circumvention servers. In Internet Measurement Conference . ACM, 2015. http://conferences2.sigcomm.org/imc/2015/papers/p445.pdf .
David Fifield. Cyberoam firewall blocks meek by TLS signature. https://groups.google.com/forum/#!topic/traffic-obf/BpFSCVgi5rs/ , 2016.
David Fifield, Chang Lan, Rod Hynes, Percy Wegmann, and Vern Paxson. Blocking-resistant communication through domain fronting. Privacy Enhancing Technologies , 2015(2), 2015. https://www.icir.org/vern/papers/meek-PETS-2015.pdf .
David Fifield and Lynn Tsai. Censors’ delay in blocking circumvention proxies. In Free and Open Communications on the Internet . USENIX, 2016. https://www.usenix.org/system/files/conference/foci16/foci16-paper-fifield.pdf .
A. Ford, C. Raiciu, M. Handley, O. Bonaventure, and C. Paasch. TCP Extensions for Multipath Operation with Multiple Addresses. RFC 8684, RFC Editor, March 2020. https://tools.ietf.org/html/rfc8684 .
Vinicius Fortuna. Outline changes since the prelinimary report, August 2020. https://github.com/net4people/bbs/issues/22#issuecomment-670781627 .
Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, and Eric Wustrow. Conjure: Summoning proxies from unused address space. In Computer and Communications Security . ACM, 2019. https://jhalderm.com/pub/papers/conjure-ccs19.pdf .
Sergey Frolov, Jack Wampler, and Eric Wustrow. Detecting probe-resistant proxies. In Network and Distributed System Security . The Internet Society, 2020. https://www.ndss-symposium.org/wp-content/uploads/2020/02/23087.pdf .
Sergey Frolov and Eric Wustrow. The use of TLS in censorship circumvention. In Network and Distributed System Security . The Internet Society, 2019. https://tlsfingerprint.io/static/frolov2019.pdf .
Sergey Frolov and Eric Wustrow. HTTPT: A probe-resistant proxy. In Free and Open Communications on the Internet . USENIX, 2020. https://www.usenix.org/system/files/foci20-paper-frolov.pdf .
GFW Report. The GFW has now been able to dynamically block any seemingly random traffic in real time, November 2021. https://twitter.com/gfw_report/status/1460796633571069955 .
GFW Report. 有证据表明中国的防火长城已经对任何看似随机的流量进行动态的封锁, November 2021. https://twitter.com/gfw_report/status/1460800856086003717 .
Amir Houmansadr, Chad Brubaker, and Vitaly Shmatikov. The parrot is dead: Observing unobservable network communications. In Symposium on Security & Privacy . IEEE, 2013. https://people.cs.umass.edu/~amir/papers/parrot.pdf .
isofew. sssniff, 2017. https://github.com/isofew/sssniff .
Liz Izhikevich, Renata Teixeira, and Zakir Durumeric. $\{$LZR$\}$: Identifying unexpected internet services. In 30th USENIX Security Symposium (USENIX Security 21) , pages 3111–3128, 2021. https://www.usenix.org/conference/usenixsecurity21/presentation/izhikevich .
Jigsaw. Outline. https://getoutline.org/ .
Jigsaw. Outline v1.1.0. https://github.com/Jigsaw-Code/outline-ss-server/releases/tag/v1.1.0 .
George Kadianakis. GFW probes based on tor’s ssl cipher list, 2011. https://gitlab.torproject.org/legacy/trac/-/issues/4744 .
klzgrad. NaïveProxy. https://github.com/klzgrad/naiveproxy .
Di Liang and Yongzhong He. Obfs4 traffic identification based on multiple-feature fusion. In 2020 IEEE International Conference on Power, Intelligent Computing and Systems (ICPICS) , pages 323–327, 2020. https://ieeexplore.ieee.org/document/9202018 .
madeye. sssniff, 2017. https://github.com/madeye/sssniff .
nekohasekai. Add shadowsocks reducedIvHeadEntropy option, January 2022. https://github.com/SagerNet/v2ray-core/commit/27fad5daaa1c33ed1c928d6c447df983a88d14a3 .
Leif Nixon. Some observations on the Great Firewall of China, November 2011. https://www.nsc.liu.se/~nixon/sshprobes.html .
ntop. PF_RING: High-speed packet capture, filtering and analysis. https://www.ntop.org/products/packet-capture/pf_ring/ .
pyasn developers. pyasn. https://github.com/hadiasghari/pyasn .
Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, August 2018. https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2 .
Eric Rescorla and Tim Dierks. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246, August 2008. https://datatracker.ietf.org/doc/html/rfc5246#appendix-E .
Shadowsocks rust developers. Shadowsocks-rust. https://github.com/shadowsocks/shadowsocks-rust .
Runa Sandvik. Ethiopia introduces deep packet inspection. https://blog.torproject.org/ethiopia-introduces-deep-packet-inspection , 2012.
Benjamin M. Schwartz and Vinicius Fortuna. feat: salt prefix support, November 2022. https://github.com/Jigsaw-Code/outline-client/pull/1454 .
Michael Carl Tschantz, Sadia Afroz, Anonymous, and Vern Paxson. SoK: Towards grounding censorship circumvention in empiricism. In Symposium on Security & Privacy . IEEE, 2016. https://www.eecs.berkeley.edu/~sa499/papers/oakland2016.pdf .
Eric Tung. Geph4 sosistab - an obfuscated datagram transport for horrible networks. https://github.com/geph-official/sosistab .
V2Ray developers. V2Ray. https://github.com/v2fly/v2ray-core .
Benjamin VanderSloot, Allison McDonald, Will Scott, J. Alex Halderman, and Roya Ensafi. Quack: Scalable remote measurement of application-layer censorship. In USENIX Security Symposium . USENIX, 2018. https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-vandersloot.pdf .
Liang Wang, Kevin P. Dyer, Aditya Akella, Thomas Ristenpart, and Thomas Shrimpton. Seeing through network-protocol obfuscation. In Computer and Communications Security . ACM, 2015. http://pages.cs.wisc.edu/~liangw/pub/ccsfp653-wangA.pdf .
Xiaokang Wang. Shadowsockets reduecd IV head entropy experiment, January 2022. https://github.com/v2fly/v2ray-core/pull/1552 .
Zhongjie Wang, Yue Cao, Zhiyun Qian, Chengyu Song, and Srikanth V. Krishnamurthy. Your state is not mine: A closer look at evading stateful Internet censorship. In Internet Measurement Conference . ACM, 2017. http://www.cs.ucr.edu/~krish/imc17.pdf .
Tim Wilde. Knock knock knockin’ on bridges’ doors, 2012. https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors .
WinkVPN, GibMeMyPacket, wkrp, et al. Shadowsocks blocked in Iran?, October 2022. https://github.com/net4people/bbs/issues/142#issuecomment-1289393093 .
Philipp Winter. GFW actively probes obfs2bridges, March 2013. https://bugs.torproject.org/8591 .
Philipp Winter and Stefan Lindskog. How the Great Firewall of China is blocking Tor. In Free and Open Communications on the Internet . USENIX, 2012. https://www.usenix.org/system/files/conference/foci12/foci12-final2.pdf .
Philipp Winter, Tobias Pulls, and Juergen Fuss. ScrambleSuit: A polymorphic network protocol to circumvent censorship. In Workshop on Privacy in the Electronic Society . ACM, 2013. https://censorbib.nymity.ch/pdf/Winter2013b.pdf .
xspeed, Vinicius Fortuna, et al. I think SS is detected by GFW, November 2021. https://github.com/shadowsocks/shadowsocks-libev/issues/2860#issuecomment-974250511 .
He Yongzhong, Hu Liping, and Gao Rui. Detection of Tor traffic hiding under obfs4 protocol based on two-level filtering. In 2019 2nd International Conference on Data Intelligence and Security (ICDIS) , pages 195–200, 2019. https://ieeexplore.ieee.org/document/8855280 .
zonyitoo. Shadowsocks-rust v1.8.5. https://github.com/shadowsocks/shadowsocks-rust/releases/tag/v1.8.5 .
zonyitoo. Security: First 6 bytes of payload should be printable characters, January 2022. https://github.com/shadowsocks/shadowsocks-rust/commit/53aab484f8daba6f5cee6896b034af943cc3d406 .

A Other Stopgap Circumvention Strategies

Use a non-TCP transport protocol. As introduced in Section 4.4, UDP traffic does not trigger blocking. Currently, one can circumvent censorship by simply switching to (or tunneling over) UDP or QUIC. This is merely a stopgap measure, as the censor can enable their censorship for UDP.

Base64-encode the first packet. Recall that the GFW does not censor connections if more than 50% of the first packet’s bytes are printable ASCII. One straightforward way to satisfy this property would be to simply base64-encode all of the encrypted traffic. This, too, is only a stopgap solution; base64-encoded data is easy to detect, and the censor could simply base64-decode and then apply its rules. Although it is effective against the GFW today, we do not consider it as a long-term solution.

More than 20 contiguous bytes of printable ASCII. The GFW exempts connections if the first packet has more than 20 contiguous bytes of printable ASCII. One way to satisfy this is to base64-encode only a small portion of the fully-encrypted packet—or even just insert at least 21 printable ASCII characters into the ciphertext. While we believe this would be more difficult to detect than base64-encoded the entire packet, it also strikes us as a short-term stopgap.

All of the above countermeasures can be implemented on the client-side only, without requiring support from the proxy server. This is possible by applying an idea from prior work [12]: sending a packet such as the ones described above that gets processed by the censor but not by the proxy. For instance, prior to sending the actual first packet of the connection, the client could send a packet that satisfies one of the above rules but that has a broken checksum (which the censor will not check, but the proxy will) or a limited TTL (large enough to reach the censor but not the destination). While these techniques were first verified against Iran’s Protocol Filter, we have verified that these same approaches work against the GFW’s blocking of fully encrypted traffic. Although this provides an encouragingly easy path for deployment, it alone does not elevate these stopgap solutions to longer-term ones.

Great Firewall Report - GFW Report on Great Firewall Report

Geedge & MESA Leak: Analyzing the Great Firewall’s Largest Document Leak

1. Introduction

2. Download Link

3. Safety Considerations

4. Background

5. Analysis of Non–Source Code Files

6. Analysis of Source Code Files

6.1 Analysis of MESA Git contributors

7. Acknowledgement

8. Contact or Join Us

积至公司与MESA实验室：防火长城史上最大规模文件外泄分析

1. 引言

2. 下载链接

3. 安全注意事项

4. 背景

5. 非源码文件分析

5.1 对报道的摘抄

环球邮报： 泄露文件显示一家中国公司正在向海外出口防火长城的审查技术

标准报： 中国如何将全面网络监控出口海外

Follow the Money： 中国向威权政权出口审查技术——欧盟企业亦有协助

5.2 对报告的分析

Geedge 产品

TSG Galaxy

TSG 的能力

镜像模式与在线模式

深度包检测

流量限速

注入与修改

将网络流量归因到真实身份

识别与封锁翻墙工具

对客户网络的远程访问

向中国境外国家的部署

哈萨克斯坦（代号 K18、K24）

埃塞俄比亚（代号 E21）

巴基斯坦（代号 P19）

缅甸（代号 M22）

代号 A24

中国的区域性防火墙

新疆（代号 J24）

福建、江苏与其他省份

6. 源码文件分析

6.1 MESA Git 贡献者分析

7. 致谢

8. 联系或加入我们

2025年8月20日中国防火长城GFW对443端口实施无条件封禁的分析

1. 引言

2. 封禁的触发

2.1 境内发起（inside-out）

2.2 境外发起（outside-in）

2.3 受影响的端口

3. 归因与设备指纹

3.1 GFW 无条件 RST+ACK 报文的指纹

3.2 GFW 基于 HTTP Host 的审查设备之 RST 指纹

3.3 GFW 基于 TLS SNI 的审查设备之 RST 指纹

4. 结束时间

5. 感谢

6. 联系我们

Analysis of the GFW's Unconditional Port 443 Block on August 20, 2025

1. Introduction

2. Triggering the blocking

2.1 Inside-out triggering

2.2 Outside-in triggering

2.3 Affected ports

3. Attribution and Device Fingerprinting

3.1 Fingerprints of GFW’s Unconditional RST+ACK packets

3.2 Fingerprints of the RST packets by GFW’s HTTP Host-based censorship devices

3.3 Fingerprints of the RST packets by GFW’s TLS SNI-based censorship devices

4. Ending time

5. Acknowledgments

6. Contact Us

Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China

Exposing and Circumventing SNI-based QUIC Censorship of the Great Firewall of China

揭示并绕过中国防火长城基于SNI的QUIC封锁机制

揭示并绕过中国防火长城基于SNI的QUIC封锁机制

A Wall Behind A Wall: Emerging Regional Censorship in China

A Wall Behind A Wall: Emerging Regional Censorship in China

环球邮报：泄露文件显示一家中国公司正在向海外出口防火长城的审查技术

标准报：中国如何将全面网络监控出口海外

Follow the Money：中国向威权政权出口审查技术——欧盟企业亦有协助

3.1 GFW 无条件 `RST+ACK` 报文的指纹