Weekly Xinjiang Mobile carrier-side traffic analysis reports (2022-2023) state in plain internal language that HTTP/3 (QUIC-over-UDP) traffic 'poses a major challenge' to the traditional parallel/mirror (并联) traffic-access blocking method, and that UDP traffic requires an inline/serial (串联) blocking deployment to 'effectively' block it -- a direct admission that passive mirror-tap deployments (the apparent default) cannot reliably block QUIC-based traffic, only inline in-path deployments can.
疆内流量已经出现基于UDP协议的QUIC协议(即HTTP3)的流量,给传统的并联流量接入GK方式带来了巨大的挑战。针对UDP流量,需要使用串联阻断的方式才能有效GK QUIC协议。
Defense implications
- Where a target deployment is known or suspected to be passive/mirror-tap (the common, cheaper topology per this same document series), QUIC/HTTP3-based or other UDP-based transports may survive blocking even when TCP-based equivalents on the same network do not -- worth empirically testing per-deployment rather than assuming uniform QUIC-blocking capability across all Geedge/TSG sites.
- Do not assume export customers running cheaper mirror/passive deployments have upgraded to the inline hardware this document says is required for effective UDP/QUIC blocking; probe each site's live QUIC handling rather than inferring it from TSG's advertised feature set.
Related findings
The Xinjiang Mobile carrier traffic report (2023-05-15) states in its own QUIC-domain-ranking section that Xinjiang's intra-provincial traffic has begun carrying QUIC/HTTP3 (UDP-based) traffic that poses "a huge challenge" to the traditional parallel/out-of-band ("并联") traffic-access blocking method, and that effectively gatekeeping ("GK") UDP/QUIC traffic requires switching to an inline/in-path ("串联") blocking architecture — a direct internal admission that (as of mid-2023, in this province) the standard mirror-tap deployment could not reliably block QUIC.
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.
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').
A 2023 MESA Lab monthly report describes the 'TF' project's active-defense work: test cases for serial ('串联') HTTP hijack/tamper and parallel ('并联') DNS race-injection ('DNS抢答'), performance tuning that scaled active-defense capacity from 3 to 5 units, converting two existing TSG boxes to active-defense mode, and rewriting the active-defense flow-control logic to no longer depend on sapp.
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.
An internal experiment using BurpSuite as a MITM proxy tests injecting a forged QUIC ServerHello carrying a connection-close frame ahead of the real server response, to make the client abandon its QUIC handshake; the author separately proposes recording every site known to support QUIC and simply blocking plain TCP connections to those sites, on the theory that this indirectly forces QUIC off since a censor cannot otherwise tell in advance which TCP flow would have upgraded to QUIC.