sni-blocking   SNI-based blocking

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

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

Both Firefox and Chromium leak cleartext DNS before establishing encrypted DNS connections: they first send an unencrypted UDP DNS query to resolve the DoH server's domain (e.g., doh.opendns.com). An in-path censor can intercept and poison this initial query, making encrypted DNS in browsers completely ineffective without additional circumvention of the resolver-lookup step. Additionally, Chromium always includes the SNI extension in the encrypted DNS TLS handshake (e.g., "doh.opendns.com"), leaking the resolver identity even after the initial lookup. No resolver requires SNI to be present for certificate validation when the resolver's IP certificate is configured.

2026-lange-towards §2.4, §7, §10 detection

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.

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

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.

2026-niere-dpyproxy-dns §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-niere-dpyproxy-dns §6.3 evaluation

Iran's DNS censorship is largely ineffective against encrypted DNS: DoQ is not censored at all (with or without SNI present), DoH3 works for all tested Cloudflare and NextDNS resolvers, and most DoT/DoH resolvers work when the SNI extension is omitted. Iran's censorship of unencrypted DNS is in-path (queries never reach the real resolver), which means the GFW-style 'last response' technique fails entirely in Iran because the client's original query is dropped before reaching its destination.

2026-niere-dpyproxy-dns §6.2.2 evaluation

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

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

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

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

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