sni-blocking   SNI-based blocking

Encrypted DNS (DoH, DoT) and Encrypted ClientHello (ECH) fully hide plaintext domain names from on-path observers but leave destination IP addresses visible, enabling IP-based fingerprinting with no protocol-level metadata required. An adversary collecting only NetFlow/IPFIX destination-IP records—without TLS fingerprints, packet timing, or port metadata—correctly identifies 72% of all 520K dual-stack websites over IPv4 and 68% over IPv6.

2026-ahmad-more-space-less §1, §3, §6.1 evaluation

The paper identifies a fundamental architectural vulnerability in single-IP circumvention designs: a relay must generate new observable flows (via DNS or TLS SNI) to reach end services after receiving client connections, creating a detectable server-and-client behavioral contrast. A relay accessing user-facing domains (news, social media) scores high on a Relay Suspicion Score (w=0.9) versus infrastructure domains (w=0.1). The paper argues this host-level signal is censorship-invariant and cannot be concealed by link obfuscation.

2026-almutairi-server §2.4, §4 detection

Article 19 documents that Iran's National Information Network (NIN / SHOMA) was designed with explicit reference to China's Great Firewall as a model, with institutional mirroring: Iran's Supreme Council of Cyberspace parallels China's Cyberspace Administration of China, and both governments share a "cyber sovereignty" doctrine used to justify domestic content controls and cross-border technology transfer. The report frames Iran's filtering infrastructure as deliberately architected to replicate GFW capabilities, not as an independently developed system.

2026-article19-tightening-the-net §2, §3 policy

The report maps specific Belt and Road Initiative Digital Silk Road projects through which Chinese technology vendors have transferred censorship and surveillance infrastructure to Iran, including fiber backbone investments, data-center co-location agreements, and equipment supply chains. Specific vendors named include Huawei and ZTE as network infrastructure providers, with the report noting that equipment exports include filtering-capable hardware that Iran's ISPs have deployed at network choke points.

2026-article19-tightening-the-net §4, §5 deployment

Russia's TSPU devices switched from broad QUIC blocking to SNI-dependent QUIC censorship between May 2022 and July 2023—at least nine months before the GFW introduced SNI-based QUIC censorship, which was previously considered the first of its kind. This transition was discussed only on Russian-language forums (ntc.party) and went unnoticed by the international research community for approximately three years.

2026-heitmann-russia-s-early-introduction §2.3, §4 evaluation

Testing the Tranco Top 100k domain list from Russian vantage points shows that all 2,644 domains blocked over TLS SNI are also blocked over QUIC SNI, and domains accessible via TLS are accessible via QUIC—indicating the TSPU maintains a unified SNI blocklist across protocols. Additionally, 31 domain patterns including discord.com exhibit 'residual clearance': QUIC connections to those domains are not censored when immediately preceded by non-censored data on the same 4-tuple; 22 domains are only blocked on port 443.

2026-heitmann-russia-s-early-introduction §3, Table 3 evaluation

Reproducing Zohaib et al.'s 10-payload QUIC parser test suite against Russian TSPU devices reveals that the Russian QUIC parser differs meaningfully from the GFW: payload 8 (PING and PADDING frames inserted before the Crypto frame), which circumvents the GFW, does not bypass Russian censorship. Payload 10 (QUICv2) bypasses both censors. Payload 9 (ECH with outer SNI cloudflare-ech.com) is blocked by Russia; payload 3 (version bytes 0x00000002 with invalid MAC) is blocked by both.

2026-heitmann-russia-s-early-introduction Appendix B, Table 2 evaluation

As measured from three Russian vantage points in March–April 2026, TSPU devices decrypt QUIC Initial packets, locate the SNI extension in the embedded TLS handshake, and drop packets with forbidden domains plus all subsequent packets on the 4-tuple for 420 seconds (timer resets on each packet). Censorship is unidirectional (outgoing only), covers all destination ports up to 65535 at Saint Petersburg and Novosibirsk (Moscow exempts 22% of system ports 1–1023), and targets only QUICv1—QUICv2 passes uncensored at all vantage points.

2026-heitmann-russia-s-early-introduction §3 detection

Despite AWS, Google, and Microsoft having publicly withdrawn CDN-level domain-fronting support to preserve commercial relationships with censoring states, domain fronting remains functional on AWS Lambda as of early 2026. Microsoft Azure Functions explicitly rejects mismatched SNI/Host headers, whereas AWS Lambda permits a client to present a legitimate *.lambda-url.*.on.aws SNI while routing internally to a different serverless function via the HTTP Host header.

2026-kang-censorless-serverless §4.7 defense

CensorLess vanilla mode costs $0.27/month for a single proxy processing 6.76 GB of traffic monthly, a 97.1% reduction (34.4×) over SpotProxy's optimal single-NIC configuration ($9.28/month). The private mode, which adds a t4g.micro EC2 VPS for end-to-end encryption via SOCKS, costs $3.41/month — still 63.3% cheaper than SpotProxy's cheapest option. Costs remain below $3.50/day even when scaling to 300 proxies.

2026-kang-censorless-serverless §6.3, Figure 6 evaluation

All major browsers (Firefox, Chromium) issue an unencrypted DNS-over-UDP query to resolve their configured DoH resolver's domain before initiating any encrypted DNS session. In Iran, nearly all tested DoH resolver domains are directly censored at the DNS layer (returning block-page IPs), which renders browser-native encrypted DNS ineffective regardless of whether the underlying encrypted protocol would otherwise succeed. Additionally, browsers always include the SNI extension in TLS handshakes with DNS resolvers even though no tested resolver requires it. The bootstrap query resolves the DoH server's own domain (for example doh.opendns.com) in cleartext, so an in-path censor can poison it before any encrypted session exists.

2026-lange-towards §7 detection

DPYProxy-DNS's automated probe-and-select mode identified a working DNS circumvention in an average of 13.78 seconds (median 12.90s) in China and 12.32 seconds (median 8.28s) in Iran across 100 runs each; best-case startup was 0.32s (China) and 0.47s (Iran) when the first-tried combination succeeded, while worst-case exceeded 30.72s in China and 58.16s in Iran due to the slow Last Response mode (3s fixed wait per attempt) being selected early in the randomized probe order.

2026-lange-towards §6.3 evaluation

DNS censorship of encrypted protocols is inconsistent in both China and Iran. In China, Yandex resolvers are censored only when the SNI extension is present; omitting SNI bypasses censorship for these resolvers. In Iran, DoH requires SNI omission for Quad9, Google, Adguard, CleanBrowsing, and NextDNS resolvers, but works with SNI for Yandex and Cisco resolvers. These inconsistencies suggest resolvers have been accidentally missed by censors, highlighting the value of automated tools that trial all resolver-mode combinations rather than hard-coding a single strategy. The support evaluation found 47 resolvers supporting DoH, 16 supporting DoH3, and only 8 supporting DoQ out of ~65 tested.

2026-lange-towards §6.2, Table 2 evaluation

DPYProxy-DNS tested 8 circumvention modes against DNS censorship from vantage points in Iran (AS201295, Mashhad) and China (AS4837, China Unicom). In Iran, DoQ was entirely uncensored even with the SNI extension present; DoH3 worked for all Cloudflare and NextDNS resolvers. Iran's censor operates in-path (not on-path like the GFW), making the "Last Response" mode (wait 3s for the last UDP reply) ineffective in Iran but highly effective in China. Auto-mode averaged 12.32s (median 8.28s) in Iran and 13.78s (median 12.90s) in China to discover a working combination. Most DoT and DoH resolvers also work once the SNI extension is omitted. Because Iran's censor is in-path rather than on-path, the GFW-style last-response technique fails entirely there: the original query never reaches the real resolver.

2026-lange-towards §6.2, §6.3 evaluation

QUICstep successfully circumvents the GFW's QUIC SNI censorship (active since April 2024) in live testing. Using an Alibaba VM in mainland China as client and an AWS instance in North Virginia as server, a native QUIC client was blocked after several fetches of youtube.com SNI, while QUICstep consistently succeeded across 50 consecutive fetches. 7 tiktokcdn.com subdomains that were QUIC-SNI blocked were also reliably accessible via QUICstep. The approach routes only QUIC long-header (handshake) packets through a WireGuard tunnel; all subsequent short-header (data) packets travel the native path.

2026-lee-quicstep §4.3.2, §3.2.3 evaluation

Before the May 26 restoration, Iran's inbound allowlist granted near-full access (100%) to university ASes (e.g., Shahid Beheshti University AS56765, Iran University of Medical Sciences AS47981) while major residential ISPs had <2% pass rates, demonstrating that the Iranian allowlist enforces differentiated access by institution type rather than a uniform policy. Additionally, roughly half of allowlisted IPs experienced no SNI filtering at all, while the other half faced domain-specific RSTs, suggesting non-uniform application-layer policies even among privileged addresses.

2026-lunarcanvas-swift-look-into §4.1.2 and §4.2 deployment

Unlike the Great Firewall of China, Iran's SNI-triggered blocking produces no residual interference: after a TCP RST caused by a sensitive SNI, subsequent connections from the same source IP using benign or randomly generated SNIs proceed normally without additional disruption. This behavior was observed consistently before and after the May 26, 2026 partial restoration.

2026-lunarcanvas-swift-look-into §4.2 detection

Iran layers SNI-based domain blocking on top of its IP allowlist: even source IPs permitted by the allowlist trigger TCP RSTs when a TLS ClientHello contains a sensitive SNI value. Randomly generated, non-existent domain names pass through without triggering resets, confirming the blocking operates as a domain-name blocklist rather than a generic TLS fingerprinting rule. Blocking behavior was highly consistent, with 97.4% of (source IP, SNI) pairs producing identical outcomes across three test repetitions.

2026-lunarcanvas-swift-look-into §4.2 detection

Iran's SNI filtering is applied inconsistently across allowlisted users: among 737 tested allowlisted IP addresses, approximately half experienced no SNI filtering at all and could reach destinations even using previously-reported blocked domains. For IPs subject to filtering, 49.9% of requests containing hrw.org and 50.2% containing tiktok.com triggered RSTs, while only 0.5% of requests with youtube.com were blocked — suggesting differential access policies tied to specific domains and user classes even within the allowlisted population.

2026-lunarcanvas-swift-look-into §4.2 detection

In April 2024 the GFW began decrypting QUIC Initial packets at scale and blocking connections by domain rather than by IP address, targeting the exact transport layer that modern moving-target circumvention systems rely on for session continuity. Because blocking a registrable domain costs the censor essentially zero collateral (unlike blocking a hyperscaler IP range), the censor's optimal Stackelberg budget split allocates f* = 0.97 of its discovery budget to the domain channel once the defender runs n ≥ 2 endpoints (§8.10, Figure 7). GFWatch measurements show hundreds of thousands of domains persistently blocked.

2026-maiti-block-a-mole-sustainability-frontier §1, §3, §6, §8.10, Figure 7 detection

As of May 2026, at least four major CDN providers — Google (fronted via www.google.com), Fastly (fronted via www.python.org), Vercel (fronted via nextjs.org), and Netlify/CloudFront (fronted via kubernetes.io) — route requests based on the HTTP Host header regardless of the outer TLS SNI, enabling domain fronting across more than 20 distinct high-value destinations. The correct fronting SNI for each CDN is selected by inspecting the SAN list of the CDN edge certificate and choosing a co-hosted domain the censor permits.

2026-patterniha-mitm-domainfronting README / Supported destinations evaluation

MITM-DomainFronting achieves fully client-side domain fronting without any server-side infrastructure by intercepting browser TLS via a user-generated personal CA, reading the plaintext HTTP Host header, then re-encrypting outbound connections to the CDN edge with a mismatched SNI. The private CA key never leaves the device, eliminating the traditional requirement for a proxy co-located inside a CDN's network and reducing operational cost to zero.

2026-patterniha-mitm-domainfronting README / Mechanism description defense

MITM-DomainFronting reached 1.8k GitHub stars and 170 forks by May 2026 and was merged into Xray-core mainline (PR XTLS/Xray-core#4348), making it deployable via a standard v2rayN/v2rayNG JSON config with no separate install step. The author additionally notes that Gemini explicitly IP-blocks Iranian addresses, demonstrating that certain Google services enforce IP-geolocation blocking at the application layer — a layer that SNI-based CDN fronting cannot bypass regardless of the fronted SNI.

2026-patterniha-mitm-domainfronting README / intro and limitations deployment

As of June 2026, Iranian DPI blocking timescales are: CDN-fronted VLESS+WebSocket domains blocked within 24 hours; SSH dynamic port forwarding server IPs blocked within 8 hours; Reality and WireGuard connections blocked immediately (seconds) after handshake completion. This graduated timeline suggests separate fast-path (handshake-pattern) and slow-path (domain reputation / traffic accumulation) detection pipelines operating in parallel.

2026-pooribitwise-iran-advanced-dpi Issue body — combined observations evaluation

Iran's DPI blocks VLESS/WS traffic routed through Cloudflare CDN in full-strict TLS mode with regularly rotated clean Cloudflare IPs, demonstrating that CDN-fronted traffic is not opaque to the censor and that IP-layer evasion (using clean CDN IPs) is insufficient when the SNI is fingerprinted.

2026-pooribitwise-iran-advanced-dpi Description detection

Iran's DPI infrastructure performs full TCP reassembly and stateful inspection on the fly, nullifying TCP fragmentation (10–30 byte fragments with 10–20ms delays) applied to VLESS+WebSocket behind Cloudflare CDN in full-strict mode. Domains are blocked within 24 hours despite the CDN layer and rotation of clean Cloudflare IPs. Fragmentation was applied to the first 5 packets and verified correct on the client side with tcpdump; the setup used port 443 with a randomized WebSocket path.

2026-pooribitwise-iran-advanced-dpi Issue body — Description / The Issue detection

Iran's censor deploys a two-stage blocking response within 24 hours of domain exposure: DNS hijacking that resolves blocked domains to 10.10.34.34, combined with RST floods when clients connect directly to Cloudflare IPs using the blocked SNI. Both mechanisms activate independently, so DNS-resistant clients are still terminated at the TCP layer.

2026-pooribitwise-iran-advanced-dpi Issue body — The Issue detection

Domains on VLESS+WebSocket behind Cloudflare are blocked in Iran even when they have no configured DNS A record and the root domain was never used — indicating Iran blocklists domain names extracted from SNI in reassembled TCP streams rather than requiring prior DNS query evidence.

2026-pooribitwise-iran-advanced-dpi Issue body — The Issue detection

The largest single source of censored domains in the GNL is MESA lab's SNI monitoring dataset (E21-SNI-Top200w.txt) containing 57,362 censored domains, and E21-SNI-Top120W-20221020.txt with 36,467 domains—totaling over 93K domains from network tap data alone for a single country (E21 = Ethiopia per InterSecLab attribution). A separate Xinjiang dataset (XJ-CUCC-SNI-Top200w.txt) contains 13,604 domains. These datasets "do not seem to come from popular domain lists, and instead appear to be gathered from network taps," confirming that Geedge builds censorship target lists directly from passive traffic observation.

2026-sheffey-geedge §4.2, Table 3 detection

Of 6,915,266 domains extracted from the 572 GiB Geedge Networks Leak (GNL), 298,955 censored domains (93.7% of all GNL-censored domains) appear in neither Tranco top-1M nor CitizenLab test lists. Measurements across China (Guangzhou/Nanjing), Myanmar, Pakistan, and Algeria confirmed censorship via DNS injection and SNI-based TLS connection termination. The GNL covers 25–62% of Tranco-censored domains across countries, showing substantial but incomplete overlap. This vendor-side ground truth reveals a censorship surface roughly two orders of magnitude larger than curated academic test lists.

2026-sheffey-geedge §4.1, Table 2 detection

The GNL reveals that Geedge actively maintains dedicated VPN-infrastructure tracking datasets. The China-specific component includes 7,016 domains in a "vpn-finder-plugins" repository (mesalab_git/intelligence-learning-engine), 4,810 NordVPN server domains, and a Pakistan-specific file listing 68 Psiphon CDN domains (geedge_docs/TSGEN/.../Psiphon-CDN_20240430.json) dated April 2024. A Myanmar deployment file (M22-VPN List.html, 27 domains) further confirms country-specific VPN blocklists are operationally maintained. The "Appsketch" program reverse-engineers VPN apps to extract domains and IP addresses for blocking.

2026-sheffey-geedge §4.2, Table 3 detection

For non-whitelisted SNIs connecting to allowed Cloudflare IPs, Iran's DPI enforced a strict 6-packet limit per connection, sufficient only to load a webpage but not to sustain any tunnel; connections bearing a whitelisted SNI were unrestricted. Outside DNS providers were blocked within one to two weeks and replaced with a local DNS infrastructure that operated at a maximum of ~100 KB/s with connections dropping at approximately the one-minute mark.

2026-tuleo1-internet-analysis-shutdown Issue body deployment

Iran implemented a per-connection packet quota tied to SNI whitelisting: connections whose SNI was not on the approved list were classified as 'grey' and hard-limited to exactly 6 packets before DPI terminated the session. Connections presenting a whitelisted SNI were passed without a packet cap.

2026-tuleo1-internet-analysis-shutdown Issue body (SNI whitelisting paragraph) detection

After approximately four days, Iran placed Cloudflare IP ranges behind a NAT that performed full TCP reassembly with strict checksum and sequence-number validation; any packet with an incorrect checksum or out-of-window sequence number caused immediate connection teardown, eliminating both TTL-spoofing and sequence-desynchronization bypasses.

2026-tuleo1-internet-analysis-shutdown Issue body deployment

Two TCP-layer SNI-spoofing techniques briefly circumvented Iran's DPI for approximately four days: (1) sending a fake ClientHello with a TTL too low to reach the server but high enough to pass the censor, and (2) sending a fake ClientHello at a future TCP sequence number that the server would ignore but the stateless DPI would accept. Both were defeated once Iran placed Cloudflare IPs behind a stateful NAT that validated checksums and sequence numbers. Iran's SNI whitelist permitted only specific domains, hcaptcha.com among them.

2026-tuleo1-internet-analysis-shutdown Issue body (SNI spoofing methods paragraph) defense

The source notes that CDN-based techniques are discussed as viable methods for bypassing TSPU filtering controls, consistent with domain-fronting and meek-style approaches that route traffic through high-value CDN infrastructure that censors are reluctant to block wholesale.

2026-viktor45-russia-architecture-operating Abstract defense

A Russian user ran a self-built snowflake-proxy from inside the censored country using the 'random-and-mimic' fingerprint option, successfully serving Iranian, Turkmen, Russian, and German Tor users, demonstrating that the blocking is unidirectional (targeting client DTLS hellos) and that snowflake-broker and rendezvous domains (snowflake-broker.torproject.net, snowflake-01/02.torproject.net) remained accessible behind the .net SNI — only the DTLS data channel was filtered.

2026-wkrp-snowflake-targeted-dtls-filtering kad09 original report, Issue #422 comment evaluation

Pakistan's PECA (Prevention of Electronic Crimes Act) and PTA (Pakistan Telecommunication Authority) regulations grant authority to block content without court orders, enabling the deployment of a persistent national filtering infrastructure. The report documents 11,000+ URLs blocked by PTA and confirms that VPN use and circumvention tools are among the targeted categories, with blocking orders issued under national security grounds.

2025-amnesty-pakistan-shadows §2, §4 policy

Amnesty International's 102-page investigation identifies a multi-vendor surveillance stack deployed in Pakistan: Chinese DPI (Geedge/MESA-derived), Canadian social-media monitoring (Netsweeper), and Emirati commercial spyware (Pegasus and FinFisher). The system enables deep packet inspection, SNI-based filtering, and traffic-shape classification at national scale, including targeted interception of encrypted messaging apps and VPN traffic.

2025-amnesty-pakistan-shadows §3, §5 deployment

TLS connections to blocked services (instagram.com, telegram.org) were terminated by TCP RST immediately after the client's ClientHello, before any certificate exchange, confirming SNI-based DPI that reads the plaintext SNI extension and aborts the handshake. HTTP filtering additionally matched Host headers and URL keywords case-sensitively, with injected HTTP 403 pages or TCP RST responses, and case-change evasions were sometimes effective.

2025-aryapour-stealth-blackout §4.2, §4.3 detection

Apple iOS devices showed zero ECH successes across all tested versions from iOS 9.1 through iOS 18.5 (totaling 383 accesses), and Mac OS systems showed sparse ECH support limited to Firefox on older macOS and Chrome on macOS 10.15.7. A single GREASEd access from iPadOS/18.0 (Mobile Safari) was the only signal of any Apple ECH awareness.

2025-farrell-ech-trial-report §6.3, Table 5; §6.5 evaluation

Even ECH-capable browsers frequently GREASE rather than attempt real ECH, with Firefox/138 succeeding only 50% of the time (164/325), Chrome/136 only 25% (42/167), and Chrome Mobile/136 only 24% (29/121). Firefox/139 performed better at 83% real ECH success (351/423), suggesting browser DNS handling of HTTPS RRs remains a significant barrier to ECH efficacy. GREASE sends a fake ECH extension that does not hide the inner SNI, so it provides no censorship resistance despite making the client appear ECH-aware.

2025-farrell-ech-trial-report §6.4, Table 8 evaluation

In a 41-day real-world ECH trial (2025-05-01 to 2025-06-11) across 14 server instances in 7 global data centers, 64% of accesses came from ECH-aware clients (success or GREASE) while 36% did not attempt ECH at all. Of 4,074 total log events, 1,660 were ECH successes, 825 were GREASE, and 1,589 were not-tried, indicating that today roughly 41% of traffic benefits from full ECH privacy protection. The trial found no measurable service disruption from enabling ECH.

2025-farrell-ech-trial-report §6.1, Table 3 evaluation

The DEfO project backported ECH support to nginx 1.22.1 (Debian bookworm's shipped version) and deployed it at 14 instances across 7 Wikimedia data centers with no service disruption over 41 days. The primary operational barrier was institutional review process for custom-built binaries and the novel HTTPS RR DNS record type, adding only a few days to the deployment timeline.

2025-farrell-ech-trial-report §3, §4, §7 deployment

Across all 7 global data centers (EU, USA, Singapore, Brazil), every data center recorded ECH successes with no observed evidence of regional ECH blocking or interference. ECH-aware client percentages varied by region — EU 75%, North America 63%, Asia 49%, South America 46% — but this was attributed to browser version distribution rather than censorship. The trial spanned 14 geographically distributed PoPs.

2025-farrell-ech-trial-report §6.2, §6.5, Table 4 evaluation

The September 2025 leak of ~600 GB from Geedge Networks and the MESA Lab (Institute of Information Engineering, Chinese Academy of Sciences) is the largest known document disclosure from the GFW vendor ecosystem. It establishes a direct lineage: MESA Lab (founded 2012 by Fang Binxing's team, annual contracted revenue >35M RMB by 2016) spun out Geedge Networks in 2018, with MESA alumni filling key engineering roles (e.g. Zheng Chao as CTO). The leak includes ~64 GB of MESA git repositories, ~35 GB of MESA internal documents, ~15 GB of Geedge internal documents, and a ~3 GB Jira export — providing direct access to source code, work logs, and internal communications behind GFW R&D.

2025-geedge-mesa-leak §4 deployment

Internal Geedge documents confirm active contracts to deploy GFW-derived censorship and surveillance infrastructure in Myanmar, Pakistan, Ethiopia, Kazakhstan, and at least one additional unidentified country under the Belt and Road framework, in addition to domestic deployments in Xinjiang, Jiangsu, and Fujian. The exported product (the Tiangou Secure Gateway / TSG line) is not a stripped-down export variant — leaked TSG documentation shows DPI, active-probing, ML classifiers, and granular per-region traffic control rules that mirror the domestic GFW capability set.

2025-geedge-mesa-leak §5, §6 deployment

The Russian DPI maintains two whitelists that exempt flows from the freeze: (1) a SNI-based whitelist covering select domains (visible in the TLS ClientHello), and (2) a CIDR-based whitelist of IP subnets for trusted destination servers. The SNI whitelist can be exploited by VLESS+Reality clients using an allowed SNI value as the apparent destination; the CIDR whitelist requires routing through an IP from a whitelisted prefix, making circumvention 'extremely difficult' without an intermediate node in a whitelisted subnet.

2025-hyperion-cs-censor-has-new upd3, upd4 detection

InterSecLab's 76-page analysis of the Geedge/MESA leak (based on nine months of indexing and translating >100,000 documents) characterizes the Tiangou Secure Gateway (TSG) product line as a commercially deployable detection stack that combines deep packet inspection, real-time mobile subscriber monitoring, active probing, ML-based traffic classifiers, and granular per-region rule sets. TSG is not a research prototype — leaked documentation includes deployment timelines and client government interactions for Kazakhstan, Ethiopia, Pakistan, Myanmar, and one unnamed country, with censorship rules explicitly tailored to each region.

2025-interseclab-internet-coup §3–§5 (InterSecLab report) detection

SNI spoofing — sending a whitelisted domain (e.g., yandex.ru) in the ClientHello while connecting to a non-whitelisted IP — did not bypass the block: any SNI value worked when connecting to a whitelisted IP, but no SNI value worked when connecting to a non-whitelisted VPS IP. This confirms the enforcement is IP-based rather than SNI-based, and SNI spoofing provides no circumvention value in this regime.

2025-its0ka-mobile-network-website Issue body (its0ka, Sep 7 2025) evaluation

Justice for Myanmar documents that Geedge Networks supplied Myanmar's military junta with GFW-derived surveillance and censorship infrastructure under Belt and Road frameworks following the February 2021 coup. The deployed system (Tiangou Secure Gateway / TSG) incorporates the same DPI, active-probing, and ML-classifier capabilities as the domestic Chinese GFW, giving Myanmar one of the most technically capable censorship systems in Southeast Asia.

2025-jfm-silk-road-surveillance §3, §5 deployment

Neither China nor Iran directly block ECH ClientHello messages; instead both effectively prevent ECH by censoring encrypted DNS resolvers. China blocks Cloudflare's DoH/DoT resolver (mozilla.cloudflare-dns.com) via SNI-based blocking in TLS and QUIC, causing residual censorship of up to 360 and 180 seconds respectively. Iran blocks both Cloudflare and NextDNS DoH hostnames via DNS block-page injection, TLS TCP RST, and HTTP block pages. Iran cannot analyze QUIC, so DoQ is uncensored and enables ECH in Iran. China's NextDNS IP blackholing affected only one of two resolved IPs, leaving an uncensored path.

2025-niere-encrypted §5, Table 1, Figure 5 detection

Of 640,694 TLS 1.3 servers in the Tranco Top 1M (Feb 2025), 51.28% parse ECH extensions but only 43% actually handshake ECH — and virtually all of those are Cloudflare servers (278,040). Only 6 non-Cloudflare servers successfully handshaked ECH. Cloudflare's own servers have a 44% non-advertisement rate: servers that can handshake ECH but do not publish their ECH configuration in DNS, typically because the operator manages their own DNS outside Cloudflare. The total number of advertised ECH configurations dropped from ~180,000 in November 2024 to ~150,000 by April 2025.

2025-niere-encrypted §4.1, §4.2, Figure 3, Figure 4 evaluation

Chrome and Firefox send GREASE ECH extensions in every ClientHello message, meaning a censor that blocks all ECH-containing ClientHellos would block all Chrome and Firefox TLS traffic. Cloudflare's static outer SNI "cloudflare-ech.com" in all its ECH configurations makes real ECH connections trivially distinguishable from GREASE ECH — censors can block real ECH connections to Cloudflare without triggering GREASE collateral damage. Cloudflare rejects ECH handshakes with omitted or invalidated outer SNI values; non-Cloudflare ECH deployments accept missing and invalid outer SNIs.

2025-niere-encrypted §2.1, §4.1, §6 detection

A machine-checked EasyCrypt proof demonstrates that a conjunctive SNI + traffic-profile adversary achieves a true positive rate of 1.0 against meek, with a false positive rate bounded by Pr[Game0(MeekEnc).main()=true] ≤ (1/10000) × (1/1000) ≈ 10⁻⁷, under the assumption that meek traffic follows a normal distribution centered at 512 bytes and background traffic a Poisson-like distribution centered at 1024 bytes. The proof is fully machine-checked in EasyCrypt.

2025-pereira-position §4.2 detection

Since August 2023, Henan Province has operated its own TLS SNI-based and HTTP Host-based censorship middleboxes that inspect and block traffic exiting the province—a second filtering layer on top of the national GFW. The Henan Firewall is fingerprinted by a unique TCP RST+ACK injection carrying a fixed 10-byte payload (0x01 02 03 04 05 06 07 08 09 00), IP ID 0x0001, and an observed TTL of 58. Unlike the GFW, it injects resets only toward the client, performs no residual censorship, and requires no TCP handshake to trigger. Longitudinal testing (Nov 2023–Mar 2025, Tranco top 1M daily + 227M CZDS domains weekly) found the Henan Firewall blocked a cumulative 4.2 million domains—more than five times the GFW's cumulative blocklist—and at peak blocked ten times more domains than the GFW.

2025-wu-regional-censorship §4.4 / §5 detection

The Henan Firewall only inspects traffic leaving Henan Province toward the rest of the world—it does not inspect domestic intra-China traffic nor inbound traffic entering the province. This contrasts with the GFW, which operates bidirectionally at China's national border. Measurement across seven CN cities (Beijing, Shanghai, Chongqing, Guangzhou, Nanjing, Chengdu, Zhengzhou) found no evidence of comparable provincial firewalls in the other six locations, making Henan the only documented province with an autonomous censorship layer as of March 2025. The Henan Firewall also uses the same blocklist for both HTTP Host-based and TLS SNI-based censorship, whereas the GFW maintains separate domain lists per protocol.

2025-wu-regional-censorship §3 / §4.2 / §5.1 detection

The Henan Firewall is stateless in two exploitable ways: (1) it requires the TCP header to be exactly 20 bytes—enabling any TCP option (e.g., TCP Timestamps, which Windows disables by default) to bypass it entirely; (2) it does not perform TCP reassembly, so splitting a TLS ClientHello across two TCP segments such that the SNI extension straddles the boundary bypasses the censor. Both bypasses require only client-side changes and have already been implemented in Xray, GoodbyeDPI, and Shadowrocket. TLS record fragmentation (splitting the ClientHello across multiple TLS records within one TCP segment) also defeats both the Henan Firewall and the GFW, since neither performs TLS reassembly.

2025-wu-regional-censorship §4.3 / §6 defense

Since April 7, 2024, the GFW decrypts every QUIC client Initial packet at China's national border and blocks connections whose TLS ClientHello SNI matches a QUIC-specific blocklist. Blocking takes the form of dropping all subsequent UDP packets sharing the same (src-IP, dst-IP, dst-port) 3-tuple for 180 seconds—with no RST injection. The GFW applies a source-port heuristic: packets with src-port ≤ dst-port are not inspected, capturing >92% of real QUIC client Initials while processing only ~30% of all UDP traffic. The QUIC blocklist contains 58,207 unique FQDNs (Tranco, Oct 2024– Jan 2025), approximately 60% of the DNS blocklist in size; 33% of blocked FQDNs do not actually support QUIC, suggesting the list was derived from an existing domain-name blocklist rather than live QUIC service discovery.

2025-zohaib-quic-sni §3 / §3.1 / §3.3 / §4 detection

GFWeb discovered that the GFW's bidirectional blocking is not symmetric: certain domains trigger blocking only when probed from inside China, not from outside. This overturns the prior assumption that the GFW blocks the same domains symmetrically in both directions. The paper also documents that the GFW has been upgraded to fix previously-reported evasion techniques, including overblocking mitigation and improved fragmented-packet reassembly, indicating active engineering iteration on the censor side.

2024-hoang-gfweb Abstract, §5.3, §6 detection

GFWeb tested 1.02 billion domains against the GFW over 20 months and discovered 943,000 pay-level domains blocked by HTTP filters and 55,000 by HTTPS filters — the largest GFW blocklist dataset ever published. The HTTP-to-HTTPS ratio (17:1) confirms that the GFW's HTTPS keyword-based and SNI-based blocking covers far fewer domains than its HTTP host-header blocking, likely because HTTPS blocks carry higher collateral-damage risk.

2024-hoang-gfweb Abstract, §5.1 detection

Google Cloud Pub/Sub is blocked entirely in China, limiting the system's applicability in the highest-censorship environment. Azure Pub/Sub is a structurally weaker candidate for rendezvous channels because each created resource receives a unique per-resource domain, enabling censors to block it with minimal collateral damage compared to blocking a shared Google or AWS endpoint.

2024-vilalonga-looking §4.1 deployment

The paper surveys the rendezvous channel design space and identifies at least six prior carrier approaches: domain fronting via CDNs, AMP cache proxying, Amazon SQS queues, push notification services, email tunneling (Mailet, SWEET), and cryptocurrency covert channels (MoneyMorph). Pub/Sub adds bidirectional real-time messaging with broad IoT/enterprise adoption as a new carrier class not previously evaluated for circumvention rendezvous.

2024-vilalonga-looking §2.2 defense

TSPU devices perform in-line packet manipulation — they can inject RST packets, drop traffic, and throttle connections — rather than routing traffic to an out-of-band sniffer that votes to block. The inline placement means TSPU can act on the first-packet payload and impose latency on all matching flows, not only on those selected by sampling. Blocking decisions are therefore applied with high recall at the ISP edge, and circumvention tools that rely on short observation windows (e.g. only obfuscating the first N bytes) are vulnerable to continued inline inspection of subsequent traffic.

2024-xue-tspu-russia §3–§4 detection

Russia's TSPU ("Средства противодействия угрозам") system is deployed inline at individual ISP edges rather than at centralized internet exchange points, producing substantial per-ISP heterogeneity: some providers apply layer-7 SNI/Host filtering while others rely primarily on IP-prefix blocklists, and QUIC/HTTP3 is blocked at several major providers. Rollout timing and enforcement depth vary measurably across autonomous systems, meaning a single "Russia passes/fails" test fixture systematically underestimates blocking coverage.

2024-xue-tspu-russia §4–§5 deployment

SNI-based blocking is deployed by 16 of 64 measured ASes in India, concentrated heavily among the two largest ISPs: Reliance Jio (189,331 confirmed SNI blocks across 504,400 measurements) and Bharti Airtel Telemedia (158,022 confirmed blocks across 540,425 measurements). Smaller ISPs exhibit only marginal SNI blocking, likely as collateral from traffic peering through larger ISP infrastructure.

2023-katira-censorwatch §5.1, Table 2 detection

TLS-based filtering (SNI blocking) was active in 41% of 70 surveyed countries during the June 2020–May 2021 measurement period and 44% historically, driven by the 82% global HTTPS adoption rate (Mozilla telemetry, Oct 2021). China took the unprecedented step of blocking ESNI traffic entirely, and the authors note that widespread ECH deployment could render this entire censorship category obsolete.

2023-master-worldwide §4.2, Table 2 evaluation

The GFW's SNI inspection is a stateless single-record parser: it cannot detect the SNI extension when the ClientHello is split across multiple TLS records, even when all records are contained within the same TCP segment. In contrast, the GFW does detect SNI when it appears fully within the first TCP segment despite TCP fragmentation, indicating the reassembly gap is specific to the TLS record layer.

2023-niere-poster §3 detection

TCP fragmentation before the SNI extension circumvents the GFW, but TCP fragmentation placing the SNI in the first TCP segment does not. The paper notes the GFW is showing 'the first signs of successfully handling TCP fragmentation,' indicating active hardening of TCP-layer circumvention that makes TLS-layer techniques increasingly necessary.

2023-niere-poster §3, Table 1 detection

TLS record fragmentation is implementable entirely in userspace at the application layer and requires no elevated privileges, unlike TCP segmentation which requires raw socket access. The authors' DPYProxy tool demonstrates a MITM approach that wraps TLS messages into smaller records before transmission without breaking the TLS handshake, since TLS records are unprotected during the handshake phase.

2023-niere-poster §2, §5 defense

96.21% of CitizenLab-tracked censored domains (1,092 of 1,135 scanned) and 92.36% of Tranco Top 1M domains (766,909 of 830,357 scanned) already support TLS record fragmentation, with support exceeding 90% across all Tranco rank ranges. This broad server-side compatibility makes TLS record fragmentation deployable without any server-side changes.

2023-niere-poster §4, Table 2 evaluation

TLS record fragmentation successfully circumvents the GFW in all tested configurations: splitting the ClientHello across multiple TLS records — whether the split falls before or after the SNI extension — bypasses GFW SNI-based blocking in every case (Table 1). TCP fragmentation after the SNI extension fails, but any TLS-layer fragmentation succeeds.

2023-niere-poster §3, Table 1 defense

Censored Planet measurements of psiphon.ca in AS6697 (Belarus) around the August 2020 Internet shutdown showed that Psiphon was initially blocked via connection timeouts during the shutdown itself, and then—several weeks after the shutdown ended—the censorship mechanism shifted to TCP RST injection. Outcome-typed measurement data made this two-phase mechanism change immediately visible without re-collecting any raw data.

2023-raman-advancing §4.3 detection

Censoring middleboxes predominantly use RST injection rather than in-path packet dropping because injecting forged RST/RST+ACK packets does not require the middlebox to sit in the data path — off-path copies of packets suffice. The GFW specifically injects both RST and RST+ACK packets simultaneously after an offending PSH, a known idiosyncratic signature, while Iran's censor uses post-handshake RST injection (⟨SYN;ACK→RST⟩) and packet drops at the same stage.

2023-raman-global §2.1, §4.1 detection

Browsers cannot independently set the HTTP Host header or TLS SNI field, blocking the standard censorship-trigger methods used in Geneva training. The paper proposes two workarounds: (1) keyword-based HTTP censorship triggers using forbidden strings in URL parameters, limited to censors that employ keyword filtering; and (2) registering domains whose strings contain a censored substring to exploit censor overblocking via overbroad regular expressions (e.g., registering a domain matching torproject.org's regex to also catch mentorproject.org).

2023-tran-crowdsourcing §3 Design — Triggering Censorship defense

After blocking all *.google.com subdomains on September 22, 2022, China's censor lifted the block specifically for FCM endpoints on October 1 while leaving other Google services (Docs, Groups, Sites) blocked through at least February 2023. This selective whitelist exception — made after only days of blocking — indicates the censor judged the collateral damage to apps relying on FCM to be unacceptable.

2023-xue-use §5.1, Figure 5 deployment

Over 7 months of Hyperquack measurements across 5,555,298 probes targeting 1,632 unique ASes, only a small number of ASes actively interfered with HTTPS connections to FCM endpoints. The majority of blocking incidents occurred in China during September 22–30, 2022, coinciding with the Party's National Congress, when nearly all measurements failed with TCP reset.

2023-xue-use §5.1, Figure 4 evaluation

Chinese-language Wikipedia views grew from 12.8 million per day in December 2019 to 13.9 million during the Wuhan lockdown (24 January–13 March) and peaked at 14.7 million per day from mid-February through April 2020; the crisis disproportionately increased views of pages selectively blocked by the Great Firewall prior to 2015, of historical Chinese leaders since Mao, and of current officials — categories expected only under a gateway effect — and these elevated levels persisted through May 2020.

2022-chang-covid-19 Crisis Provided a Gateway to Censored Political Information / Fig. 3 and Fig. 7 evaluation

Using DoH plus ESNI, DNEye successfully unblocked 130/230 (56%) of DNS-filtered domains in China and 53/56 (95%) in Russia, but 0/49 (0%) in Iran. The primary failure mode in China (84 domains) and Iran (47 domains) was SNI-based filtering at the TLS layer for domains that do not support ESNI, which remains visible in the ClientHello.

2022-hoang-measuring §4.3, Table 3 evaluation

DNEye detected DoTH (DoT and DoH) blocking across the largest number of ASes in China, with interference against Cloudflare, Quad9, AdGuard, and CleanBrowsing resolvers emerging in early March 2021. Blocking patterns varied per-AS rather than following a centralized GFW DNS-level policy, indicating individual ISP implementation. Saudi Arabia, by contrast, showed coordinated SNI-based blocking of the same DoH resolvers across different ASes, indicating centralized policy.

2022-hoang-measuring §4.2, Table 5 detection

Only 1.5–2.25% of domains from TLD zone files have a valid ESNI key, with 15.4K of the top 100K and 143.3K of the top 1M popular domains supporting ESNI. All ESNI-supported domains are hosted by Cloudflare, making ESNI-enabled connections trivially distinguishable from the vast majority of TLS traffic and a low-collateral-damage blocking target for censors.

2022-hoang-measuring §4.2 evaluation

In AS45090 (China), the Cloudflare CDN IP 104.16.248.249 succeeds 100% of the time with SNI 'cloudflare-dns.com' but triggers TLS handshake resets 93% of the time with SNI 'mozilla.cloudflare-dns.com'. Follow-up measurements using those same SNIs against unrelated HTTPS servers (example.org, hbl.fi) reproduced the same resets, confirming that the GFW performs SNI-keyed TLS blocking independent of the destination IP.

2021-basso-measuring §V-E, Table VI detection

MCI (AS197207, Iran) intercepts cleartext DNS and returns the bogon address 10.10.34.36 for dns.adguard.com A queries regardless of which upstream resolver is used (system, 8.8.8.8, or 9.9.9.9), and intercepted queries never reached a researcher-controlled DNS-over-UDP server. This bogon falls in the same /24 documented in prior Iranian censorship research. Additionally, SNI blocking for dns.adguard.com was confirmed independently on both port 853 (DoT) and port 443 (DoH).

2021-basso-measuring §V-D detection

In AS197207 (Iran, MCI), approximately 50% of DoT endpoints failed consistently — the only case across all tested ASN/protocol combinations where failure exceeded 20%. In Kazakhstan (AS48716) and China (AS45090), more than 80% of DoT and DoH endpoints were always reachable.

2021-basso-measuring §V-F, Table VII evaluation

In China (AS45090), HTTP/3 over QUIC has a lower overall failure rate (27.1%) than HTTPS over TCP (37.3%), but hosts that time out during the TCP handshake (TCP-hs-to, indicating IP blocking) always also fail over QUIC — while hosts blocked via TLS-hs-to or conn-reset (SNI-based methods) nearly always succeed over QUIC.

2021-elmenhorst-web §5.1, Table 1, Figure 3a evaluation

In Iran (AS62442), HTTPS connections fail at 34.4% (mostly TLS-hs-to, consistent with SNI filtering), while HTTP/3 over QUIC fails at only 16.2%. SNI spoofing reduces TCP failure from 60.1% to 10.2% but has zero effect on QUIC (20.1% both with real and spoofed SNI), indicating Iranian censors apply separate UDP endpoint blocking to QUIC rather than SNI-based identification.

2021-elmenhorst-web §5.2, Table 3 detection

The GFW enforces SNI-based blocking on every TCP port (not just 443), triggering TCP RST injection and a penalty box for known-censored hostnames (e.g., facebook.com, zh.wikipedia.org) in the TLS ClientHello. The SNI blocklist is separate from the HTTP keyword blocklist — keyword-derived subdomains in the SNI did not trigger censorship. No evidence was found for indiscriminate HTTPS decryption or certificate substitution.

2021-rambert-chinese §4.6 detection

The authors developed 'Aladdin,' a 10-step OONI-based measurement experiment that isolates SNI-based blocking (step 1), Host-header blocking (step 2), DNS injection (step 3), system-resolver vs. DoH discrepancy (steps 4–5), TLS interception (steps 6–8), and TLSv1.3-specific SNI dependency (step 10); this methodology exposed Vodafone's Allot TLS interception that OONI's Web Connectivity test had recorded only as a generic certificate error.

2021-ververis-understanding §3.8 evaluation

Analyzing over 3 million OONI network measurements (2016–2020) from 17 ASes covering 98.45% of broadband and 90.94% of mobile subscribers in Spain, the study detected 16 unique blockpages, 2 DPI vendors (Fortinet/Fortigate in Telefonica; Allot in Vodafone), and 78 blocked websites across copyright, political, civil-rights, and referendum categories.

2021-ververis-understanding §3, §4 evaluation

Active-probing censors who discover a shadow domain can be defeated by adding a CDN rule that only fetches from the blocked back-end when a secret custom request header is present; without it the CDN returns an innocuous response. Layering domain fronting over domain shadowing (DfDs) further hides the shadow domain by routing the initial request through an allowed front domain with the Host header set to the shadow domain, so the censor never sees the shadow domain in the SNI or DNS query even during active inspection.

2021-wei-domain §6.1.2, §3.4 defense

Google Cloud CDN and Amazon CloudFront disabled domain fronting by 2021 by enforcing SNI/Host header consistency, causing Tor Meek, Psiphon, Lantern, and Signal to halt or migrate their domain-fronting deployments. Domain shadowing avoids this failure mode entirely because it does not rely on the SNI/Host mismatch that CDNs were able to patch with a simple header equality check.

2021-wei-domain §2.3 evaluation

Domain shadowing makes all three traffic indicators — connecting URL, SNI, and Host header — appear to belong to an allowed shadow domain while fetching content from a blocked back-end domain via CDN. Unlike domain fronting, it exploits a legitimate CDN feature (arbitrary back-end binding) rather than a SNI/Host mismatch quirk, so CDNs cannot disable it by enforcing header consistency without breaking legitimate use cases such as third-party service outsourcing via CNAME. The technique was demonstrated successfully accessing www.facebook.com from a heavily censored country.

2021-wei-domain §3.3, §6.2 defense

Internet filtering in Saudi Arabia is implemented primarily as HTTP URL-keyword filtering augmented by TLS-level (SNI) filtering for HTTPS connections; DNS and IP-level failures were minimal and consistent with transient network issues rather than deliberate blocking. In 2019, 82.2% of Adult, 7.6% of Shopping, and 6.2% of Games websites returned HTTP 403; TLS filtering of Shopping sites decreased from 9.6% to 6.6% between 2018 and 2020.

2020-alharbi-opening §3.1 detection

Mann-Kendall trend analysis at 99% significance on 20 months of data found increasing censorship activity in more than 100 countries, driven primarily by DNS and HTTPS blocking methods, and identified 11 website categories facing rising censorship including human rights content, news media, and provocative attire. Countries such as Norway (ranked #1 in press freedom) showed aggressive DNS blocking across 25 ASes targeting more than 50 domains in at least 6 categories including hrw.org.

2020-raman-censored §7.2, §7.1.2 evaluation

Of the Alexa Top 10,000 domains tested, only 37 triggered interception; 20 were Google services, 7 were Facebook-affiliated, and others included Mail.Ru properties (vk.com, ok.ru) and Twitter — a social media and communication focus consistent with a surveillance rather than security motive. The interception system was intermittently active for 21 days (July 17 – August 7, 2019), including a four-day shutdown for tuning, with a median of 340 TLS hosts observing interception when active.

2020-raman-investigating §4.2.5, §4.2.6 evaluation

Kazakhstan's 2019 HTTPS interception affected 7.0% of 6,736 measured TLS hosts when probed from North America and 24% when probed from inside the country; all affected paths traversed AS9198 (Kazakhtelecom), with 95% of injections occurring at two specific IP addresses (92.47.151.210 or 92.47.150.198), indicating a highly centralized interception infrastructure.

2020-raman-investigating §4.2.1–§4.2.2 evaluation

Kazakhstan's interception system triggered solely on the TLS SNI header: a connection was intercepted only if the SNI contained one of 37 targeted domains AND the path passed through specific AS9198 hops; the server's actual certificate needed to be browser-trusted but did not need to match the SNI domain, and interception could be triggered bidirectionally — from outside the country connecting to TLS hosts inside Kazakhstan.

2020-raman-investigating §3.2, §4 detection

In HTTP tests, more than 50% of filter responses that indicated censorship contained an injected HTML blockpage; the remainder used TCP RST injection or connection timeout. In HTTPS measurements, canonical template matching had a failure rate of only 1.9%, and 95% of Hyperquack measurements completed within 3.5 hours across ~45,000 vantage points.

2020-raman-measuring §III-A, §IV evaluation

Indian ISPs use heterogeneous and overlapping censorship mechanisms with no single technique common across all providers: DNS tampering (ACT, Airtel, BSNL, MTNL), HTTP header filtering (all six ISPs), and SNI inspection (Jio only). Individual ISPs such as ACT simultaneously apply DNS-only blocking to 233 sites, HTTP-only to 1,873 sites, and both to 1,615 sites.

2020-singh-india §5.1, Table 2 evaluation

Jio, India's largest ISP serving 49.7% of internet users, employs SNI inspection to block 2,951 out of 3,340 websites it censors — the first documented use of SNI-based blocking in India. No other of the six tested ISPs uses this technique.

2020-singh-india §5.1.4 evaluation

As of July 2019, approximately 10.93% of the Alexa top 1 million websites support ESNI (all via Cloudflare CDN, which enabled ESNI across all its platforms in September 2018), with 92.56% of Cloudflare-hosted sites using encrypted SNI over TLS 1.3. However, fewer than 0.01% of observed TLS ClientHello messages in the wild contained an ESNI extension, revealing a severe gap between server-side readiness and client-side adoption.

2019-chai-importance §4.2, §5.1 evaluation

Of the Alexa top 1 million websites censored in China, 84.5% are blocked by IP address, meaning that even if both DNS hijacking and SNI filtering are fully circumvented, the vast majority of blocked sites remain inaccessible. Only 66 currently censored sites can be unblocked by ESNI alone (combined with an encrypted DNS channel), while 101,049 ESNI-supported sites remain blocked by IP.

2019-chai-importance §4.1, §4.3 evaluation

Monitoring ESNI-related censorship across 14 geographic regions — including Mainland China, Iran, UAE, South Korea, and 10 others — found no blocking of ESNI traffic or interference with ESNIKey retrieval via DNS TXT records as of mid-2019, contradicting a widely circulated report claiming South Korea had already blocked ESNI. Additionally, the GFW's residual censorship window after a triggered RST was measured at 60 seconds (down from the previously reported 90 seconds).

2019-chai-importance §4.4, §6 evaluation

In China's Great Firewall, SNI filtering is almost never the sole blocking mechanism: only 70 of the 21,446 SNI-filtered sites are exclusively censored via SNI. The GFW uses SNI filtering as a 'third gatekeeper' — applied after DNS hijacking and IP blocking — and maintains separate blacklists for SNI filtering and DNS hijacking, evidenced by 2,764 sites under DNS injection but not SNI filtering.

2019-chai-importance §4.1 detection

Oman and Qatar deploy layered blocking: after a TCP handshake to geti2p.net completes normally, a TCP RST is injected immediately after the TLS ClientHello (SNI-based blocking), while HTTP connections to the mirror site receive injected packets redirecting to explicit national block pages. Kuwait applied only the HTTP mirror block, and only at one of six tested ASes (AS47589, Kuwait Telecommunication Company), with all other Kuwaiti networks leaving I2P fully accessible—illustrating significant ISP-level variation within a single country.

2019-hoang-measuring §5.2–5.3 detection

Over one month, 54K measurements from 1.7K ASes in 164 countries detected I2P blocking in exactly five countries: China (DNS poisoning of homepage and 3 of 10 reseed servers), Iran (TCP RST injection with HTTP 403 on mirror site), Oman and Qatar (SNI-based blocking of HTTPS homepage plus TCP injection with block-page redirect on HTTP mirror), and Kuwait (TCP injection on mirror site at AS47589 only). All other tested countries left I2P fully reachable.

2019-hoang-measuring §5, Table 2 evaluation

Across all tested countries, circumvention and anonymization tools are the most consistently blocked category: www.hotspotshield.com is blocked in 5 of 13 detected censoring countries, and three Tor Project properties (bridges.torproject.org, www.torproject.org, ooni.torproject.org) each appear in the top-10 most broadly blocked domains. Collateral damage is also documented — Iran blocks psiphonhealthyliving.com as a substring match for the psiphon.ca circumvention domain.

2018-vandersloot-quack §6.2, Figure 12 evaluation

Iran's number of blocked domains increases from 25 (HTTP keyword blocking) to 374 (TLS SNI-based blocking) — a 15× increase — with the newly blocked domains shifting composition to predominantly News, Human Rights, and Anonymization tools. This demonstrates that Iran maintains a distinct, more aggressive SNI blocklist for HTTPS traffic that is largely invisible to HTTP-only measurement.

2018-vandersloot-quack §6.4 detection

A survey of the top 10,000 Alexa websites found that only 6% (Class 1) are fully hosted on shared CDNs with HTTPS deployments that allow removal of destination leakage — the only class browsable with plausible unobservability against a competent DPI-equipped censor — while 64% are partial-CDN sites (Class 4) whose CDN-hosted content (images, videos) can still be reached via content wrappers or dynamic mirrors at negligible operational overhead.

2016-zolfaghari-practical §5.1 evaluation

Real-world CDN HTTPS deployments leak the identity of visited websites through three distinct channels — TLS certificate contents (A2, B1, B2 deployments), the plaintext SNI field (B1), and dedicated IP address mappings (B2) — enabling censors to block CDNBrowsing connections via standard DPI or IP filtering without collateral damage to non-forbidden CDN content. Each leakage channel requires inspecting only a single packet from an HTTPS connection, making the attack low-cost and deployable on off-the-shelf censorship boxes.

2016-zolfaghari-practical §3.1 detection

Winter and Lindskog [157] (2012) documented that the GFW used TLS SNI inspection in combination with IP/port filtering and TCP disruption to block Tor, as recorded in the survey's Table 1. This is one of the earliest published accounts of the GFW applying SNI-based blocking specifically to a circumvention protocol, demonstrating that the GFW correlated multiple detection signals rather than relying on any single technique.

2015-aceto-internet Table 1 detection

As of 2015, TLS tampering detection was implemented by only a small minority of surveyed censorship measurement tools: explicitly by Holz et al.'s Crossbear (2012) and OONI (2012), and partially by Soghoian and Stamm (2011) and UBICA (2013). The majority of the 13+ surveyed platforms detected DNS tampering and HTTP manipulation but lacked TLS coverage, creating a systematic blind spot in published censorship measurement.

2015-aceto-internet Table 2 evaluation

Domain fronting exploits the fact that major CDN providers (Google, Amazon CloudFront, Akamai, Microsoft Azure) terminate TLS at the edge before inspecting the Host header, so the SNI visible to a censor names a permitted CDN domain (e.g., www.google.com) while the inner HTTP Host header routes the request to a blocked destination. Blocking the fronted service requires blocking the entire CDN, creating collateral damage that most censors are unwilling to accept for major providers.

2015-fifield-blocking-resistant §2 defense

The meek pluggable transport, implementing domain fronting over HTTPS, achieved median download throughput of roughly 1–2 Mbps in controlled tests from censored regions (China, Iran), confirming that CDN-fronted tunnels are viable for real users at consumer broadband speeds. Latency overhead compared to direct connections was measurable (tens of milliseconds per round-trip through the CDN edge) but acceptable for browsing workloads.

2015-fifield-blocking-resistant §5 evaluation

The paper formally characterizes the censor's visibility gap: the SNI field in the TLS ClientHello and the HTTP Host header inside the tunnel are the two places that reveal destination, and CDNs that terminate TLS before forwarding HTTP requests prevent censors from correlating them. Any censor capable of correlating SNI to inner-Host (e.g., through CDN cooperation or plaintext HTTP/2 framing) can defeat domain fronting without CDN blocking.

2015-fifield-blocking-resistant §3 detection

Tor's TLS handshake exhibited multiple distinguishing fingerprints — including the client cipher list, server certificates, and randomly generated SNIs — that were used for TLS-based filtering in Ethiopia, China, and Iran. Inferring the exact byte-level pattern matched by DPI boxes required manual analysis and remains a difficult open problem as of 2013.

2013-winter-towards §3.1.5, §5 detection