TECHNIQUES
tls-fingerprint TLS ClientHello fingerprinting
JA3/JA4-style cipher-suite ordering, extensions, GREASE patterns.
22 papers on file
- 2026-rks-russian-apps-vpn-detection Russian Apps Search for VPNs: A Survey of Mandated VPN-Detection in 30 Popular Russian Android Apps
- 2026-wkrp-snowflake-targeted-dtls-filtering Snowflake-targeted DTLS filtering in Russia, starting 2026-03-30
- 2025-alaraj-iran-refraction Measuring Censorship in Iran Using Refraction-based Proxies
- 2025-midtlien-fingerprint-resistant Fingerprint-resistant DTLS for usage in Snowflake
- 2025-mixon-baca-hidden Hidden Links: Analyzing Secret Families of VPN Apps
- 2025-niere-transport Transport Layer Obscurity: Circumventing SNI Censorship on the TLS-Layer
- 2025-rodriguez-revisiting Revisiting BAT Browsers: Protecting At-Risk Populations from Surveillance, Censorship, and Targeted Attacks
- 2025-tusing-minecraft-tunnels Minecraft tunnels for covert communications
- 2025-xue-discriminative The Discriminative Power of Cross-layer RTTs in Fingerprinting Proxy Traffic
- 2024-almutairi-fingerprinting Fingerprinting VPNs with Custom Router Firmware: A New Censorship Threat Model
- 2024-chen-extended Extended Abstract: Oscur0: One-shot Circumvention without Registration
- 2024-niere-tls-attacker TLS-Attacker: A Dynamic Framework for Analyzing TLS Implementations
- 2024-xue-fingerprinting Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes
- 2023-niere-poster Poster: Circumventing the GFW with TLS Record Fragmentation
- 2023-wang-chasing Chasing Shadows: A security analysis of the ShadowTLS proxy
- 2022-xue-openvpn OpenVPN is Open to VPN Fingerprinting
- 2021-satija-blindtls BlindTLS: Circumventing TLS-Based HTTPS Censorship
- 2020-raman-investigating Investigating Large Scale HTTPS Interception in Kazakhstan
- 2015-frolov-the-use-of-tls The use of TLS in censorship circumvention
- 2016-fifield-fingerprintability Fingerprintability of WebRTC
- 2014-jones-automated Automated Detection and Fingerprinting of Censorship Block Pages
- 2013-houmansadr-parrot The Parrot is Dead: Observing Unobservable Network Communications
79 findings tagged here
-
AnyTLS implements a persistent idle-session pool with configurable parameters: idle_session_check_interval (default 30s), idle_session_timeout (default 30s), and min_idle_session (default 5). The client maintains at least 5 pre-established TLS sessions at all times to enable fast connection reuse without a new TLS handshake per request.
-
Compared to peer protocols, AnyTLS rates 'medium' performance (vs. VLESS 'high', Hysteria2 'very high', TUIC 'high'), uses TCP/TLS transport (vs. UDP/QUIC for Hysteria2 and TUIC), and relies on padding-based obfuscation vs. REALITY/WebSocket (VLESS) or HTTP/3 framing (Hysteria2). Client ecosystem support is currently limited primarily to sing-box, vs. broad cross-client support for VLESS, Trojan, and Hysteria2.
-
AnyTLS is a TLS-based proxy protocol maintained by the sing-box team, designed in 2024 and first released in the sing-box dev-next branch. Its core mechanism wraps arbitrary proxy traffic in standard TLS and applies a configurable padding scheme (Padding Scheme) to enhance traffic concealment while maintaining compatibility with standard TLS infrastructure.
-
LetsVPN's exit is described as part of a broader pattern: a wave of 'airport' (proxy subscription service) outages across multiple providers in April 2026, documented in a companion article titled '2026年四月份各大机场断线详解,' indicating coordinated or systematic GFW blocking affecting the circumvention ecosystem broadly during this period.
-
The blog author, drawing on evaluation experience, concludes that LetsVPN's failure was not caused by IP exhaustion or ordinary node instability but by precise protocol-signature identification: once the GFW extracts a client handshake feature, it can simultaneously block all connections sharing that signature across hundreds of thousands of users.
-
LetsVPN permanently exited the Chinese mainland market in late April 2026 after its technical team spent 20 days making hourly adjustments and confirmed it could not restore connectivity. The official announcement designated April 8, 2026 as the effective service-termination date and initiated a full refund program.
-
The article documents that large-scale 'one-click' commercial VPN providers with static protocol stacks have become effectively non-viable in China, while subscription-based proxy node services using open-source clients (Clash, Shadowrocket) with server-side rapid IP and datacenter switching demonstrate substantially greater resilience to GFW blocking waves.
-
Russia's Ministry of Digital Development issued guidelines effective April 15, 2026 requiring popular apps to detect and restrict access from VPN-using devices. RKS Global's analysis of 30 popular Russian Android apps found that 22 of 30 implement VPN detection, and 19 of those transmit the detected VPN status to their servers. This represents a shift from network-layer blocking (TSPU) to app-layer enforcement as an additional censorship vector.
-
The RKS Global report documents a two-tier Russian censorship architecture: TSPU network-layer blocking (documented by Xue et al. 2024) at the ISP level, now supplemented by mandated app-layer VPN detection in the 30 most popular Russian Android apps. This layered approach means a circumvention tool that successfully bypasses TSPU at the network layer can still be detected and reported by the app layer, closing the gap that network-only circumvention leaves open.
-
Obscura's browser-to-browser (B-B) WebRTC connections produce DTLS ClientHello and ServerHello messages indistinguishable from genuine browser traffic: across 100 captured handshakes compared against Facebook Messenger, Google Meet, Discord, and a reference WebRTC app using the dfind tool, no unique identifiers were found in C-C connections, and the sole Firefox-specific fingerprint (ServerHello length 86 bytes, cipher TLS_AES_128_GCM_SHA256, extension field length 46 bytes) matches the default Firefox WebRTC profile — meaning blocking it would also block all legitimate Firefox WebRTC users.
-
Authoritarian regimes blocked Snowflake primarily through DPI targeting fingerprints in Pion's DTLS handshake and TLS fingerprints in complementary WebRTC protocols, not through ML-based traffic analysis — confirming that cost-effective censors consistently favor simple, deterministic methods over computationally expensive classifiers.
-
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.
-
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.
-
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.
-
Simulating a shift from a 0% to 100% male dataset sample changes Shannon entropy estimates by more than 10% for User-Agent (downward) and more than 68% for WebGL Renderer (upward), revealing that prior large fingerprinting studies — Panopticlick (83.6–94.2% unique, predominantly reached via tech-oriented channels) and AmIUnique (90% desktop unique) — likely misrepresent real-world risk due to uncontrolled male bias, as confirmed by a directly comparable study showing 76.5% male participants.
-
Approximately 60% of users in the 8,400-participant US dataset had a unique overall browser fingerprint when combining 13 standard attributes, matching FingerprintJS's advertised 60% accuracy. Fingerprinting risk followed strict monotonic trends: uniqueness increased with age (65+ group most at risk) and decreased with income (household income under $25,000 group at greatest risk), while males showed more unique overall fingerprints but females showed higher uniqueness on passive-fingerprintable attributes (User-Agent, Languages).
-
A simple three-hidden-layer MLP trained on only 13 standard browser attributes achieves AUROC above 0.5 for every tested demographic group: gender 0.663–0.679, age 55+ 0.644, Hispanic ethnicity 0.60, Asian race 0.698, Black race 0.677, and high-income bracket 0.617. Because the model used only attributes already collected by mainstream fingerprinting scripts (e.g., FingerprintJS), richer real-world attribute sets would yield substantially higher demographic inference accuracy.
-
User-Agent and Accept-Language browser attributes are transmitted in HTTP request headers, enabling passive server-side fingerprinting without JavaScript execution or any browser-detectable signal. In the 8,400-user dataset, the Languages attribute placed Hispanic users (who represent only 11% of the sample) among more than 45% of users with 'es-US' as their Languages value, substantially reducing their anonymity set size versus the general population.
-
Screen resolution (572 distinct values, 4.5% unique, entropy 5.51), WebGL Unmasked Renderer (654 distinct values, 3.2% unique, entropy 6.833), and User-Agent (434 distinct values, 2.8% unique, entropy 4.613) are simultaneously the most uniquely identifying individual attributes and the strongest demographic predictors by normalized mutual information across all five demographic categories tested (gender, age, income, Hispanic ethnicity, race).
-
Russia's mobile operators (MTS, Beeline, MegaFon, Yota) deployed a TCP connection-freezing technique in mid-2025 that silently halts packet delivery after approximately 15–20 KB of server-to-client data within a single TCP connection, without sending RST packets, causing clients to stall until timeout. The trigger requires: (1) TLS 1.3 or TLS 1.2 over TCP, (2) destination IP located in a foreign datacenter ASN (e.g., Hetzner, DigitalOcean), and (3) cumulative in-connection payload exceeding the threshold.
-
Only SSH/SFTP and sometimes RDP are observed to pass through the Russian mobile network freeze without data-size limitations; raw TCP transfers without TLS and all common TLS-based proxy protocols (VLESS, Reality, Trojan, Shadowsocks) are subject to the 15–20 KB per-connection cap. This suggests the censor's DPI whitelist is protocol-specific and SSH's wire format is recognized as exempt.
-
In 24-hour live proxy deployments, covertDTLS mimicry had a 18.2% DTLS handshake failure rate (vs 12.5% baseline, 27.0% randomization, 25.8% Chrome webextension). Randomization generates ≈994 billion unique fingerprint permutations (cipher shuffling: 109,600; extension shuffling: 994,218,624,000), making blocklist-based fingerprinting infeasible, but at the cost of higher connection failures due to cipher mismatches. Mimicry of DTLS 1.2 was stable and effective; DTLS 1.3 mimicry is not yet achievable with the current Pion library.
-
The DTLS ClientHello extensions field is the most prominent feature for fingerprinting Snowflake's Pion WebRTC stack. A passive DPI tool (dfind) validated against the MacMillan et al. dataset of 6,500 DTLS handshakes reliably identifies Pion-based implementations via unique extension byte patterns. Chrome randomized its extension list order starting with version 129.0.6668.58 (September 2024), yielding 6! = 720 unique permutations and hardening it against deterministic matching. Firefox adopted DTLS 1.3 by default from version 127 (May 2024), which changes the extension structure entirely and renders DTLS 1.2 mimicry obsolete for Firefox traffic.
-
Firefox adopted DTLS 1.3 by default for WebRTC in May 2024 (version 127); Chrome has implemented DTLS 1.3 in BoringSSL but not yet enabled it by default. DTLS 1.3's Encrypted Client Hello (ECH) extension would encrypt extension lists and make passive field-based fingerprinting of those extensions obsolete — but censors may choose to block DTLS 1.3 ECH unless browsers adopt it widely enough that blocking causes unacceptable collateral damage. The Pion library (used by Snowflake standalone proxies) has no concrete roadmap for DTLS 1.3 support, creating a growing gap.
-
Beyond business-filing cross-references, the paper introduces a method of linking VPN provider families by showing they share VPN server cryptographic credentials (Shadowsocks passwords, server TLS fingerprints) across distinct app identities. This extends prior ownership-attribution methods that relied solely on corporate registry data and code similarity, adding shared live infrastructure as a linkage signal that is harder for operators to obscure.
-
MinecruftPT encodes circumvention traffic steganographically inside the Minecraft Java Edition network protocol, making a censored connection appear to a network observer as an ordinary online Minecraft game session. The cover channel is a high-volume, varied-packet-size TCP protocol with a large and active user population, making statistical fingerprinting harder than for lower-volume cover protocols.
-
Testing from a VPS in Iran showed that standard DTLS handshakes are blocked at that vantage point, but Oscur0 avoids this blocking by transmitting only Application Data packets (with Connection ID extension per RFC 9146) after the initial one-shot setup packet, never completing a visible DTLS handshake. A proof-of-concept was implemented in approximately 600 lines of Go using the pion/dtls library.
-
TLS-Attacker implements more than 330 cipher suites, including uncommon GOST and SM cipher suites specified by the Russian and Chinese authorities, covering SSL 3.0 through TLS 1.3 as well as DTLS 1.0 and DTLS 1.2. This breadth lets researchers test whether authority-mandated or jurisdiction-specific cipher suite selections alter TLS fingerprint classification by censors in those countries.
-
The TLS-Attacker suite is being extended to cover QUIC and DTLS 1.3 under a universal analysis framework that reuses existing Workflow Trace and Modifiable Variable machinery with only protocol-specific components added. As of 2024 the QUIC dialect is functional, making TLS-Attacker the only open-source tool that can fuzz TLS, DTLS, and QUIC handshakes under a single scriptable API.
-
TLS-Attacker's Workflow Traces and Modifiable Variables mechanisms allow testers to specify arbitrary protocol flows and apply field-level modifications — including adding, removing, or overwriting individual TLS message fields — without breaking the internal TLS state machine. This makes it the standard instrument for probing how DPI systems and active-probing detectors respond to non-standard or mutated TLS handshakes.
-
TLS-Scanner, a subproject of the TLS-Attacker suite, automates handshake probes across deployed TLS hosts and has been used in published IPv4-wide scanning studies. It surfaces supported protocol versions, enabled extensions, and known vulnerabilities, providing a ready-made audit tool for circumvention infrastructure operators.
-
Obfuscated proxy traffic (including Shadowsocks, VMess, VLESS, Trojan, obfs4, and REALITY) can be reliably fingerprinted by detecting encapsulated TLS handshakes — the inner TLS ClientHello that appears inside an outer encrypted tunnel. This fingerprint is protocol-agnostic: any proxy that wraps TLS-bearing application traffic will produce it. The authors deployed a similarity-based classifier within a mid-size ISP serving over one million users and demonstrated detection with minimal collateral damage.
-
While stream multiplexing reduces the visibility of encapsulated TLS handshakes by merging inner connections, the paper cautions that multiplexing plus random padding alone is "inherently limited" as a long-term countermeasure. Censors can adapt by monitoring burst sizes and round-trip counts at the outer-connection level, which remain correlated with the number of inner TLS sessions regardless of padding.
-
ShadowTLS relays are detectable via three active probing techniques exploiting behavioral discrepancies from the mask sites they mimic: (1) responding to plaintext HTTP on port 443 with FIN-ACK rather than an error (only 17% of TLS servers share this behavior), (2) silently ignoring non-TLS record data post-handshake rather than sending a fatal alert (only 0.14% of 30M hosts behaved this way), and (3) silently ignoring corrupted TLS Application Data records rather than sending a bad_record_mac alert (only 0.12% of hosts silent).
-
ShadowTLS is structurally limited to TLS 1.2 because in TLS 1.3 the Finished message is sent as encrypted Application Data (record type 0x17), preventing the relay from detecting handshake completion without decrypting the session. This forces ShadowTLS to advertise TLS 1.2, which is an increasingly anomalous fingerprint as TLS 1.3 adoption grows.
-
ShadowTLS's TLS ClientHello fingerprint (JA3 hash ebaa863800590426) was not observed in the TLSFingerprint.io dataset collected from a university network tap, making the client fingerprint unique to the tool and trivially blockable by censors maintaining a TLS fingerprint blocklist.
-
Starting October 3, 2022, more than 100 users reported simultaneous blocking of TLS-based circumvention servers running Trojan, Xray, V2Ray TLS+WebSocket, VLESS, and gRPC. Blocking was port-specific initially (mainly port 443, but also non-443 ports), then escalated to full IP blocking when users switched ports. Domain names were not added to DNS or SNI blocklists. naiveproxy was notably not affected. The blocking was dynamic in at least some cases (browsers could still reach the port, but circumvention tools could not), strongly indicating protocol-level identification rather than blind port blocking.
-
Dominant failure modes differ systematically by country: China (AS45090) shows connect timeouts in 75% of DoT failures (IP-level blocking); Kazakhstan (AS48716) shows post-TLS-handshake timeouts in 72% of DoT failures (likely ACK or segment discard after handshake); Iran (AS197207) shows TLS handshake timeouts in 80% of DoT failures. Packet capture analysis confirmed that timeouts during and after the TLS handshake correspond to unacknowledged TCP segments, not connection resets.
-
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.
-
Balboa's covert signaling protocol derives per-connection keys as KDF(TLS_master_secret ∥ pre_shared_secret) and signals by XOR-ing the MAC of a TLS Application Data record with this derived key. Because the master secret is ephemeral, the scheme inherits TLS forward secrecy—unlike Telex-based signaling (Client Random modification), future server compromise cannot retroactively identify which historical connections used Balboa, and a censor mimicking a client has negligible probability of guessing the modified MAC without the pre-shared secret.
-
Balboa runs unmodified application binaries on standard inputs, intercepting TLS via dynamic library injection (LD_PRELOAD / DYLD_INSERT_LIBRARIES) to replace plaintext with covert data while preserving all TLS record lengths and non-timing characteristics. This yields goodput of 145 kbps for audio streaming and up to 8 Mbps for web browsing, versus 2.56 kbps for DeltaShaper and 19 kbps for Freewave, both of which run real applications on non-standard inputs.
-
By extracting TLS session keys through library debugging hooks (SSLKEYLOGFILE for GnuTLS/NSS/Rustls; an injected SSL_new() callback for OpenSSL) rather than reimplementing the TLS handshake, Balboa leaves the ClientHello entirely untouched. This prevents the class of fingerprinting attacks documented by Frolov and Wustrow that identified meek and similar tools via observable differences in cipher-suite ordering and TLS extension patterns, while remaining compatible with OpenSSL, GnuTLS, NSS, and Rustls without requiring application source-code modifications.
-
Vodafone (AS12357, AS12430, AS6739) deployed Allot-based TLS interception to block womenonweb.org: the system resolver returned a legitimate IP (67.213.76.19), but connecting to it triggered a forged certificate signed by Allot; disabling TLS certificate validation fetched the Vodafone blockpage, confirming a man-in-the-middle box rather than a redirect. OONI's standard Web Connectivity test recorded only a generic ssl_error:certificate verify failed and missed this entirely.
-
The protocol filter's HTTPS fingerprint requires only that the first 5 bytes match a TLS header (type 0x16, version 0x03 0x01–0x03, correct length field); all subsequent bytes of the Client Hello are unchecked. Any TLS-based circumvention tool naturally satisfies this fingerprint and will bypass the filter by default. Furthermore, any one of the three permitted fingerprints (DNS, HTTP, HTTPS) can be used on any of the three monitored ports to whitelist an entire flow.
-
The GFW blocks ESNI by dropping client-to-server packets whenever a TLS ClientHello containing the `0xffce` encrypted_server_name extension is sent over a completed TCP handshake. Unlike GFW censorship of SNI and HTTP (which uses RST injection to both endpoints), ESNI censorship uses unidirectional packet dropping with no injected packets. The blocking applies on all ports from 1 to 65535.
-
Following publication of the researchers' findings, Mozilla Firefox and Google Chrome shipped changes on August 21, 2019 that completely blocked the Qaznet Trust Network root certificate even if manually installed by users, preventing future re-activation of the interception system without deployment of a new root CA. The paper advocates that browsers display non-intrusive visual indicators whenever a custom root CA is in use, and calls for content providers to detect and share data on large-scale interception via TLS fingerprint monitoring.
-
The Kazakhstan interception system connected back to the origin TLS server before issuing a fake certificate, and in doing so exposed a unique TLS fingerprint (hash f09427b5aaf9304b): it used TLS record-layer version 1.0, ClientHello version 1.2, and offered only 13 cipher suites — a fingerprint virtually unseen in normal HTTPS traffic — allowing content providers to detect when a connection was being intercepted.
-
V2Ray clients emitted TLS ClientHello messages with a hardcoded, rarely-seen ciphersuite (fingerprint ID 8c48b95f67260663 on tlsfingerprint.io) that allowed a machine-learning classifier to identify V2Ray TLS traffic with 0.9999 accuracy; the same classifier could not accurately identify the traffic after the fingerprint was changed. The blocking rule based on the unique ciphersuite could be expressed in a single iptables line.
-
Frolov and Wustrow show that every major TLS-based circumvention tool (Tor Browser, Lantern, OpenVPN, Psiphon, etc.) produces a TLS ClientHello fingerprint that is statistically distinguishable from real Chrome or Firefox: differences include cipher-suite ordering, extension set, extension ordering, ALPN values, and curve preferences. A passive observer with a classifier over ClientHello fields can identify the tool with high precision without decrypting any traffic.
-
Beyond the ClientHello, circumvention tools diverge from real browsers in TLS record-layer behavior: Go's crypto/tls splits the first application-data write differently than NSS or BoringSSL, and Go does not send a TLS ChangeCipherSpec in the same byte sequence as Chrome. These post-handshake divergences are detectable even when the ClientHello has been patched with uTLS, requiring record-layer mimicry in addition to hello-field mimicry for full fingerprint resistance.
-
The paper introduces the uTLS library, which allows a Go TLS client to impersonate a specific browser's TLS fingerprint by replaying a recorded ClientHello template (including exact cipher suites, extensions, and GREASE bytes) rather than constructing one from Go's crypto/tls. Using a Chrome 70 uTLS template reduces fingerprint-distinctiveness to near zero against a passive classifier trained on real Chrome traffic.
-
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.
-
Filtering candidate decoy sites by a minimum 15 KB TCP window eliminated 24% of the initial ~5,500 HTTPS hosts; a 30-second HTTP-timeout floor eliminated a further 11%; and AES-128-GCM cipher-suite support requirements eliminated an average of 32%—together reducing the viable decoy-site pool by approximately 55% before any live reachability tests.
-
77% of public bridges offer only vanilla Tor, which is trivially detectable via TLS certificate pattern matching. An additional 15% offer Pluggable Transports with conflicting security properties (e.g., obfs4 + obfs3 + obfs2 co-deployed on the same bridge), allowing a censor to confirm and block the bridge via the weakest PT and thereby disable all stronger PTs on the same IP — including active-probing-resistant transports like obfs4 and ScrambleSuit.
-
Tor's vanilla TLS certificate presents a distinctive pattern (SubjectCN=www.[random].com; IssuerCN=www.[random].net using base32 random strings), which never changes across certificate rotations every 2 hours. Using this pattern against Censys and Shodan scan data without running any active scans, the authors discovered 694 private bridges and 645 private proxies, and deanonymized the IP address of 35% of public bridges with clients (23% of all active public bridges) in April 2016.
-
The authors extend Houmansadr et al.'s 'parrot is dead' argument to WebRTC: because WebRTC is a large multi-protocol framework, superficial mimicry that fails to replicate exact DTLS version, cipher suite ordering, certificate common name ('WebRTC'), 30-day validity period, STUN server selection, and ICE packet sequence leaves detectable residual distinguishers, making deep fingerprint conformance especially hard for standalone non-browser implementations such as Snowflake's client.
-
Among the five WebRTC applications analyzed (Google Hangouts, Facebook Messenger, OpenTokRTC, Sharefest, Snowflake), Snowflake is uniquely identifiable by its use of DTLSv1.2 (all others use DTLSv1.0), its 17 offered cipher suites, and its exclusive selection of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256—a cipher suite not chosen by any other application in the study.
-
A DTLS fingerprinting script run on one full day of network traffic at Lawrence Berkeley National Laboratory found only 7 DTLS handshakes with 3 unique client fingerprints and 3 unique server fingerprints, suggesting there may not be enough naturally occurring WebRTC traffic to provide meaningful cover for a WebRTC-based circumvention system.
-
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.
-
Table 1 of the survey documents that by 2013–2014 censors were deploying simultaneous blocking across BGP, DNS, IP/port filtering, TCP disruption, TLS, and application-layer keyword filtering. No single detection tool in the survey covers all six layers; the most comprehensive, OONI (2012), covers DNS, IP/port, TCP, TLS, keyword, and HTTP but notes only partial BGP coverage.
-
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.
-
CloudTransport achieves 'entanglement' by using the exact same cloud-client libraries, protocols, and network servers as legitimate cloud storage applications, making it immune to protocol-discrepancy detection that defeated imitation systems like SkypeMorph. Iranian censors blocked Tor by exploiting differences in Diffie-Hellman moduli between genuine SSL and Tor's SSL and the expiration dates of Tor's SSL certificates; CloudTransport has no such discrepancies because it is not an imitation. Simple line-speed tests based on tell-tale differences in protocol headers or public keys cannot be used to recognize CloudTransport.
-
Facade routes all encoded HTTP requests through a Selenium-controlled Chrome browser instance, so every message the censor observes is generated by a real browser implementation. This defeats 'parrot attack' fingerprinting, which exploits discrepancies between a protocol emulator's responses to error conditions and those of the genuine client or server.
-
Comprehensive Internet-wide scanning enables cross-IP tracking of users and devices by correlating stable cryptographic identifiers — TLS certificates or SSH host keys presented by home routers and cable modems — with public geolocation data across DHCP lease changes, defeating the anonymity assumption behind dynamic IP addresses.
-
By scanning ports 443 and 9001 and fingerprinting responses with Tor's TLS v1 cipher-suite handshake pattern, ZMap identified 79–86% of all allocated Tor bridge fingerprints in a single scan, demonstrating that bridges whose protocol is distinguishable are largely discoverable through comprehensive Internet-wide scanning even though their addresses are not publicly listed.
-
Iran deployed a new Tor-blocking strategy in February 2013 that caused direct Tor user counts to collapse from over 50,000 to near zero within weeks, as recorded by Tor Project metrics.
-
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.
-
Flash proxy tunnels carry inherent network-level fingerprints that survive application-layer obfuscation: WebSocket connections begin with a plaintext HTTP upgrade handshake followed by structured binary framing, and Flash socket connections open with a crossdomain XML policy request — both are distinguishable from ordinary TCP by a DPI middlebox.
-
OONI's threat model assumes an adversary capable of country-wide traffic manipulation who may actively fingerprint and identify measurement probes. Prior measurement tools (e.g., ONI's rTurtle) used easily fingerprinted centralized DNS and HTTPS traffic, which the authors flag as a pattern to avoid. The authors acknowledge that anti-fingerprinting measures will likely reduce measurement accuracy — a trade-off unresolved at publication.
-
The Chinese Great Firewall was observed conducting two follow-up probes for each outbound TCP/443 connection: the first with garbage binary data (target unknown) and the second specifically performing an SSL negotiation, an SSL renegotiation, and successfully building a one-hop Tor circuit to confirm the bridge. This reactive probing renders unpublished Tor entry points discoverable even when not listed in any directory.
-
The GFC identifies Tor connections via a unique TLS ClientHello cipher list sent by the Tor client. Once DPI boxes detect this fingerprint on outbound traffic, active scanning is initiated within minutes: scanners connect to the suspected bridge, attempt to build a Tor circuit, and if successful the IP:port tuple is blocked. This two-stage pipeline (fingerprint → confirm → block) allows dynamic bridge blocking without pre-enumeration.
-
Tor DPI fingerprinting by the GFC is applied exclusively to egress traffic (from inside China to the outside world). Simulated Tor connections between domestic Chinese nodes and between external nodes connecting inward to a Chinese VPS attracted zero active scans across multiple experimental runs, indicating the detection infrastructure is positioned on the border for outbound flows only.
-
Clients embed HMAC-derived, time-varying sentinels into the 28-byte random field of the TLS ClientHello message, which decoy routers can scan at line rate. Sentinels are keyed to the current hour and a per-hour sequence number, providing freshness. This covert channel requires no out-of-band signaling and is invisible to passive observers who see only a normal TLS handshake toward the decoy destination.
-
A passive observer of BridgeSPA traffic sees only a TCP connection timeout on failed authorization or a successful TLS connection on success—exactly what they would observe with an unmodified Tor bridge. The ConnectionTag is indistinguishable from the normally-random ISN and timestamp fields in Linux 2.6, so no new observable artifact is introduced. However, BridgeSPA does not address the separate problem that Tor traffic itself remains fingerprint-distinguishable from HTTPS; this is an orthogonal concern.
-
An active man-in-the-middle adversary can hijack a live BridgeSPA TCP SYN by intercepting the ConnectionTag-bearing packet and racing to complete the bridge connection before the client's timestamp rounds to a new minute. Mitigating this requires the client to re-send the full (non-truncated) ConnectionTag after TLS is established, causing the bridge to act as a cover service (e.g., IMAP over TLS) until validated—but this mitigation is undermined by the fact that Tor bridge TLS certificates are currently distinguishable from other service certificates.
-
Encrypted protocols such as SSL/TLS remain fully fingerprint-able through their unencrypted handshakes: DPI can apply static string matching, packet-length comparison, and timing profiling to the cleartext cipher-negotiation and key-exchange phase to identify and block the protocol even though the payload is encrypted.
-
The paper identifies two unresolved fingerprinting surfaces: (1) traffic-shape analysis of packet sizes and inter-arrival times could distinguish Telex flows from normal TLS, and (2) the prototype exhibits detectable deviations from real servers at the IP layer (stale IP ID fields), TCP layer (incorrect congestion windows detectable by early acknowledgements), and TLS layer (different compression methods and cipher-suite extensions). Convincingly mimicking a diverse population of TCP/TLS server implementations is flagged as requiring substantial engineering effort.
-
Tor's 2006 TLS handshake contained multiple identifying fingerprints exploitable by censors: the X.509 organizationName field was set to 'Tor', the relay nickname appeared in the commonName field, clients always presented certificates (unlike browsers), and Tor used two-certificate chains (identity cert + per-session TLS cert) while most consumer HTTPS services use a single certificate. The paper flags these as sufficient for a censor to identify Tor traffic without deep payload inspection.