An internal security-research presentation surveys published CDN-abuse techniques relevant to censorship evasion -- 'Domain Borrowing' (Black Hat Asia '21) and 'Domain Shadowing' (USENIX Security '21, explicitly labeled by the presenter as a 'new-type censorship-evasion technique,' 新型审查绕过技术) -- both exploiting CDNs' failure to verify accelerated-domain or origin ownership so that traffic with SNI==Host==a high-reputation domain reaches an attacker- or circumvention-controlled origin, and closes with concrete CDN-hardening recommendations (verify domain/origin ownership, set a distinct Host header on origin fetch, reject default-site requests with 403).
由于 CDN 不验证源站的归属权，攻击者可以在 CDN 上部署加速域名并将源站配置为被审查的网站地址，从而可以绕过审查系统的审查...受害者侧的防火墙观测到的通信对端 IP、SNI、Host 皆为高信誉度域名。
Defense implications
- MESA's own threat model already treats CDN-based domain-fronting-style evasion (SNI/Host both showing a trusted domain) as a named, tracked technique with proposed countermeasures (origin-ownership verification, distinct back-end Host headers) -- domain-fronting-reliant transports should assume the specific CDN misconfigurations these techniques depend on are being actively catalogued and closed by CDN providers under this kind of pressure, and should not treat any single CDN's current behavior as a long-term-stable bypass.
Related findings
TSG automatically generates recurring weekly "SNI Report of Overseas APP" and companion "Server IP and Location of Overseas APP" reports at what is almost certainly a China-national (not export-customer) scale — single weekly runs process from ~5.7 trillion to over 135 billion rows and up to ~775TB/week — breaking down QUIC.SNI/SSL.SNI/HTTP.Host traffic per named blocked-in-China platform (YouTube, Facebook, Google, Twitter, Instagram, Telegram, WhatsApp, Netflix, BBC, Viber, Line, Snapchat, Gmail, HBO, and more), down to individual CDN edge hostnames (e.g. specific scontent-*.fbcdn.net and rr*---sn-*.googlevideo.com nodes ranked by bytes). The report series recurs weekly from at least Feb 2023 through Mar 2024.
A dedicated internal "运营商前端分析团队" (Carrier Front-end Analysis Team) produces weekly, carrier-specific traffic-analysis reports explicitly titled "新疆移动流量分析报告" (Xinjiang Mobile Traffic Analysis Report) and "新疆联通流量分析报告" (Xinjiang Unicom Traffic Analysis Report), with instances dated from at least July 2022 through March 2024. One instance (Xinjiang Mobile, 2023-05-15) reports total carrier bandwidth of 4.4Tbps (1Tbps access bandwidth), 27.34PB of weekly throughput, 123 distinct identified application-layer protocols, and a section (4.1, pages 17+) explicitly tracking server IP/location for 28 named overseas apps (BBC, Discord, ESPN, Facebook, Gmail, Google, Hulu, Instagram, Netflix, Reddit, Skype, Telegram, Twitter, Uber, WhatsApp, Wikipedia, YouTube, Zoom, etc.).
An internal module spec describes a proxy for authenticated/authorized users to reach overseas ('境外') services: it extracts the true destination domain from the TLS ClientHello SNI, resolves it via a normal public DNS resolver, forwards traffic (L4) to the real IP over a 'dedicated network,' rate-limits by client IP, and dynamically picks the lower-latency of two dedicated-network paths -- a 'VPN leased line' and a 'covert network' (隐蔽网络). Non-SNI TLS connections to the proxy are immediately closed (FIN), and the deployment does not yet support HTTP/3/QUIC.
A MESA Lab monthly-report task list includes the next-step item 'design a scheme to identify forged/spoofed SNI in traffic' ([SNI判别]), alongside a separate active/passive traffic-fingerprinting project ('CAM-TEST') that extracts service banners passively and issues active host/port CGI GET probes.
An internal measurement-study report documents researchers live-testing the public DPYProxy TLS/SNI record-fragmentation tool against the GFW from inside China, against a control run from a German VPS. On a GFW IP-blocklisted Wikipedia IP, SNI fragmentation of any tested size (1/5/10/20 bytes) still ended in a server-side RST (though 1-5 byte fragments reached ServerHello before RST vs. 10-20 byte fragments RSTing right after ClientHello); on a non-blocklisted IP for the same domain, SNI fragmentation fully bypassed SNI-based blocking and returned a normal HTTP 200 response, matching the Germany baseline. The same report notes that testing Psiphon triggered roughly 5-10 minutes of residual censorship that also blocked other, unrelated circumvention tools from the same vantage point.
A hands-on MESA lab experiment testing TLS-record/TCP fragmentation (via the DPYProxy tool, replicating the public "Circumventing the GFW with TLS Record Fragmentation" technique) against live GFW found SNI fragmentation reliably bypasses GFW's SNI-based blocking of a non-blocklisted wikipedia.org IP, but has zero effect on GFW's separate IP blocklist: for an already-blocklisted IP, every fragment size tested still failed, with GFW tearing down the connection via <RST,ACK> immediately after ClientHello for larger fragments, or after the server's Hello for very small (1-5 byte) fragments.