A MESA lab measurement of national censorship middleware (China, Russia, an unnamed "HZ" censor, and India) finds China's GFW performs both Host-header-based and keyword-based filtering across ALL ports, not just HTTP/HTTPS 80/443, and blocks matching connections with 3x injected RST packets or an additional RST,ACK -- a broader and more aggressive posture than the other three censors measured, none of which monitor all ports.
CN：存在基于Host的审查以及基于Keyword的审查机制，对所有端口都进行监控，而不只是HTTP默认端口（80，443）。针对审查内容返回3*RST数据包进行阻塞，或者额外返回<RST,ACK>数据包
Defense implications
- Lantern transports must not assume GFW censorship is confined to ports 80/443 -- this measurement confirms Host/keyword inspection runs on all ports, so port-hopping alone does not evade it.
- Expect GFW blocking to arrive as an injected RST or RST,ACK triple rather than a silent drop; a transport that validates RST authenticity (sequencing/timing/out-of-band checks) can directly defeat this specific GFW behavior.
Related findings
An internal MESA Lab research note directly measures and compares China's ('CN') HTTP censorship middlebox against Russia, India and an unlabeled 'HZ' system, plus open-source Snort2/Snort3/Suricata: China is characterized as inspecting Host- and keyword-based triggers (example trigger given: a request containing the parameter 'q=ultrasurf') across ALL ports rather than just 80/443, responding with a triple RST or an extra RST+ACK; an 8-technique HTTP-request-mangling evasion comparison table credits China's middlebox as vulnerable only to request-line whitespace insertion and HTTP-version tampering, fewer categories than the other three systems tested.
The AppSketch/MAAT signature system contains a systematically dated, patch-versioned catalog of FQDN-based detection signatures for dozens of individually named commercial VPN apps (e.g. V2VPN, V2Netvpn, Turbo VPN, LetsVPN, AdGuard VPN, Avira Phantom VPN, TouchVPN, FinchVPN, Opera VPN, Ultrasurf VPN, GoFly VPN), each modeled as an 'app' object in category 'networking' / subcategory 'tunnels' whose default deny_action drops the flow while sending both an ICMP-unreachable and a TCP RST to the client. At least 35 such distinct VPN-app signature objects appear in this batch alone, dated July-November 2024, with repeated 'Patch0N' revisions to the same app as its domains rotate.
MESA Lab's own incident analysis of a TCP reflection-amplification abuse wave against the GFW shows the underlying keyword-filtering and RST-injection trigger mechanism from a live production log: a spoofed SYN followed by a PSH+ACK packet whose HTTP GET Host header contains one of three forbidden domains (youporn.com, bittorrent.com, freedomhouse.org) causes the GFW to send three RST,ACK packets each to the spoofed source and real destination IPs. A companion internal reading-group presentation (advisor name redacted) separately reviews the USENIX 2021 "Weaponizing Middleboxes for TCP Reflected Amplification" paper, which documents this exact class of attack abusing censorship middleboxes as DDoS reflectors.
An internal TSG operations/troubleshooting manual lays out TSG's full traffic pipeline (NIC -> mrzcpd/marsio capture driver -> sapp DPI engine -> firewall/proxy(KNI->TFE)/active-defense/WAN-NAT policy branches) and shows engineers using maat_redis_tool to pull the live Redis-synced blocking policy tables (TSG_SECURITY_COMPILE, TSG_OBJ_IP_ADDR, TSG_OBJ_APP_ID) and filter them by numeric policy/object ID to debug why a block rule isn't firing.
The internal 'MAAT网络流处理配置统一描述框架' engineering manual (v3.1.20, author name redacted, 2021) documents MAAT's Redis-synced rule-compilation framework and its RuleScan/Hyperscan-based pattern-matching engine (libmaatframe.so / librulescan), and records that RuleScan's fast-scan feature caused a production outage on 2019-03-19 and has been disabled ever since.
An internal TSG functional-requirements spec ('加密协议JG') defines device support for identifying and blocking ECH, ESNI and QUIC traffic via per-connection SNI/region-matching tables (e.g. DF_QUIC_REGION), plus a companion 'FD报文全流程感知' feature that both passively monitors and actively injects synthetic verification traffic end-to-end through the network path to compute a live per-rule 'CT率' (breakthrough/penetration rate) — the system self-measures how often its own QUIC/ESNI/ECH blocks fail to take effect, and separately throttles logging/blocking detail for rule IDs receiving unusually high hit counts (DF_ATTACK_PROTECTION, 'targeted attack detection').