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.

An experimental 'random-and-mimic' option in snowflake-proxy produced a DTLS ClientHello fingerprint distinct from any observed standard fingerprint and was not blocked by the Russian filter. The covert-dtls library under development by the Tor Anti-Censorship team systematically randomizes the DTLS ClientHello handshake to defeat JA3/JA4-based classification.

kad09 report + abstract team notes defense

PCAP analysis from inside Russia confirmed the filter is fingerprint-based, not IP-based: every failed DTLS connection shared the same JA3/JA4 fingerprint, while a single connection with a different JA3/JA4 fingerprint succeeded and sustained full-speed data transfer, eliminating the hypothesis that censors had enumerated the large proxy IP space.

kad09 original report, Issue #422 comment (Apr 5 2026) detection

Russia (TSPU/Roskomnadzor) began blocking Snowflake on 2026-03-30 by detecting DTLS ClientHello messages with specific JA3/JA4 fingerprints after a small delay. The block caused Snowflake to drop from ~100% connection success (measured from November 2025 through March 29) to near-total failure for standard proxies overnight.

Issue #603 opening comment (wkrp, Apr 6 2026) 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 ip-blockingsni-blockingtls-fingerprint

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 sni-blockingtls-fingerprint

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 dpisni-blockingtls-fingerprintip-blocking

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 tls-fingerprintsni-blocking

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 tls-fingerprintdpisni-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 traffic-shapedpisni-blocking