TECHNIQUES
tls-fingerprint TLS ClientHello fingerprinting
JA3/JA4-style cipher-suite ordering, extensions, GREASE patterns.
26 papers on file
- 2026-nguyen-huu-multi-view-fusion-encrypted Multi-View Fusion for Encrypted C2 Detection: A Leakage-Controlled Measurement Study of Evaluation Pitfalls
- 2026-rks-russian-apps-vpn-detection Russian Apps Search for VPNs: A Survey of Mandated VPN-Detection in 30 Popular Russian Android Apps
- 2026-schramm-analyzing-societal-awareness Analyzing Societal Awareness and Perception of Digital Fingerprinting and Fingerprinting Countermeasures
- 2026-soosahabi-helol-tunnel-covert Helol Tunnel: Covert Channel Exploitation of TLS Extensibility & Privacy Features
- 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-akbari-traffic-classification-increasingly Traffic classification in an increasingly encrypted web
- 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
107 findings tagged here
-
TSG's Context-Based Detector (CBD) evaluates circumvention tool signatures across JA3/JA4 TLS fingerprints, SSL certificate issuer fields, UDP payload length, first-packet byte patterns, server IP ranges, and FQDN matches, often combining multiple conditions with logical AND. Of 29 VPN and circumvention tool signatures logged in the VPN Signature File Update Log (March–November 2024), 21 carry risk level 5 (the maximum), indicating aggressive prioritization of blocking major tools including ExpressVPN, NordVPN, Tor Browser, and Psiphon.
-
TLS ClientHello length-field permutation tests show that GFW II's parsing behavior matches an older tagged version of TSG's SSL module, while Kazakhstan and Pakistan (DROP mode) exhibit parsing behaviors consistent with TSG QUIC plugin deployments. QUIC version fingerprinting further confirms Kazakhstan runs an older version of TSG's QUIC parsing code, and Myanmar's supported QUIC versions exactly match TSG's, spanning at least five countries confirmed or plausibly running TSG components.
-
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.
-
sing-box 1.14 enables Chrome QUIC fingerprint simulation for Hysteria2 by default, but the release notes explicitly warn that servers using Ed25519 certificates will experience handshake failure when this option is active, requiring operators to disable the fingerprint option or switch certificate algorithms.
-
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.
-
None of the six surveyed deployed protocols — TLS 1.3, QUIC v1, WireGuard, Shadowsocks 2022, obfs4, and Tor — provides the full set of BiFEP security properties (exact shaping, delivery, protocol-state integrity, private half-close, and cross-direction isolation) at the specification level.
-
Under simultaneous adversarial forgery of both the TLS handshake fingerprint surface and the flow-behavior surface, all multi-view fusion configurations collapse to approximately 0.07 F1 — well below the trivial always-positive baseline of 0.711 (Δ = 0.590, cluster-bootstrap p < 0.001 over 2,000 resamples of 62 captures). Clean-condition model ranking does not predict adversarial ranking.
-
Computing frequency encoding of JA3, JA3S, and SNI across the entire dataset rather than within each cross-validation fold inflates the TLS-view F1 score by 0.28 — approximately ten times larger than any real detection effect measured in the study. When leakage is controlled, the largest genuine multi-view fusion gain over the best single view is only 0.022 F1.
-
Forging the TLS handshake surface (JA3/JA3S fingerprint, certificate, ALPN, HTTP/2 negotiation) requires only minutes via malleable profile configuration, while forging flow-behavior features (inter-arrival timing, packet-size distribution, volume statistics) requires sleep/jitter tuning and cover traffic but remains feasible. The paper explicitly rejects the common assumption that flow behavior cannot be forged.
-
The Reality protocol triggers immediate RST flood responses from Iranian ISP infrastructure at the completion of the TLS handshake, suggesting Iranian DPI has developed a fingerprint or active-probe response specifically targeting Reality's TLS handshake forwarding mechanism as of June 2026.
-
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.
-
Fingerprinting acceptance averaged 3.90 for cybersecurity applications, 3.73 for law enforcement, and 3.00 for user experience on a 5-point scale (n=734); privacy-protective behaviors (Privacy Behavior Index, p<0.01) and prior use of Tor or Brave (p<0.01) were the strongest negative predictors of acceptance across all three domains. Privacy concern level (Westin Index) alone did not significantly predict fingerprinting awareness, whereas behavioral privacy practices did.
-
Across 734 participants, fingerprinting awareness (mean 2.4 on a 1–4 scale) was significantly lower than cookie awareness (mean 2.86), confirmed by Wilcoxon signed-rank test at p < 0.001. Only 22% of participants had used a privacy-focused browser (Tor or Brave), and the Spearman correlation between cookie and fingerprinting awareness was only ρ = 0.40, indicating that tracking-technology literacy does not transfer automatically between mechanisms.
-
Among 734 participants, 70.4% were categorized as Privacy Pragmatists willing to trade data for convenience, while only 25.9% were Privacy Fundamentalists; prior use of Tor or Brave (~22% of the sample) and a higher Privacy Behavior Index were the strongest positive predictors of fingerprinting awareness (p<0.01 each), while self-reported privacy concern alone had no significant relationship with awareness. The structural minority of Fundamentalists represents the population disposed to tolerate the usability costs of strong countermeasures.
-
Countermeasures against fingerprinting can paradoxically increase a user's identifiability when deployed by a small population: spoofing-introduced attribute inconsistencies and unusual configurations (e.g., Tor Browser's letterboxing applied to an uncommon monitor size) produce a rarer, higher-entropy fingerprint than baseline. This 'information paradox' means that countermeasure effectiveness is a property of the anonymity set size, not of individual tool configuration.
-
Brave's built-in strict fingerprinting protection was discontinued in January 2024 because of low adoption and frequent web breakages caused by restricting JavaScript APIs; browser vendors are broadly reluctant to implement robust built-in countermeasures for the same compatibility reason. Spoofing-based extensions (HTTP-header spoofers, Canvas Defender) offer only partial protection and can degrade site functionality through overlapping layouts, unreadable fonts, or bot misclassification.
-
CipherSight achieves 95.41% top-1 accuracy across 2,008 website classes in closed-world evaluation, outperforming the strongest Tor-oriented baseline (VarCNN at 92.16%) by 3.25 percentage points and all HTTPS-native baselines by a wider margin, using only ciphertext-observable TLS record metadata without decrypting payloads.
-
CipherSight achieves 91.09% accuracy in Singapore and 90.59% in France when trained exclusively on US traffic, with only 0.50 pp variation between regions; the strongest regional baselines lag by 11.56 pp (Singapore) and 8.52 pp (France), and some baselines vary by up to 24.38 pp across regions, confirming that TLS-record-level fingerprinting is geographically transferable while packet-level methods are not.
-
In open-world evaluation — where 213,099 traces from websites absent from training must be rejected — CipherSight achieves 97.64% AUROC, 88.54% AUPR, and 94.81% OSCR, exceeding the strongest baseline (RF at 93.04% AUROC, 72.03% AUPR, 87.61% OSCR) by 4.60, 16.51, and 7.20 percentage points respectively, demonstrating effective discrimination of monitored sites even amid a large pool of unseen traffic.
-
Under a 16-day temporal distribution shift (us0304→us0320), CipherSight retains 92.99% accuracy with only a −2.42 pp drop from its closed-world baseline, while the strongest prior baseline (H&W) falls to 79.96% (−6.49 pp) and Tor-oriented methods drop 18–25 pp, demonstrating that TLS-record-level representations generalize substantially better than packet-level ones over time.
-
RFC 8701 GREASE anti-ossification measures require compliant NGFWs and middleboxes to preserve TLS CHLO parameter orderings unmodified; simultaneously, popular browsers and applications randomize their JA3 fingerprints by shuffling cipher suites and extension order as a privacy measure. These two trends together make traffic with varied TLS CHLO orderings indistinguishable from legitimate application traffic at static inspection, eliminating a reliable detection signal for censors.
-
Static NGFW inspection cannot distinguish Helol tunnel TLS CHLO packets from legitimate privacy-motivated parameter randomization; only advanced statistical or ML monitoring of 'incumbent TLS CHLO trends' could potentially surface anomalies (§5). Local captures across 9 devices over 4 days yielded 96,825 TLS CHLO packets with only 137 distinct parameter-combination fingerprints, illustrating that real traffic is sparse enough for ML baselines to be practical but that the cover population is large.
-
Empirical testing of 3 enterprise NGFWs (2020–2024 software) found that 2 out of 3 complied with anti-ossification measures and preserved TLS CHLO parameter ordering, making them fully vulnerable to permutation-encoded covert channels; all 3 preserved parameter values within NIST-allowed sets, leaving all vulnerable to the lower-throughput bitmap (selection) encoding. None of the 3 products raised warnings about simulated malware sending repetitive TLS CHLO packets.
-
Helol tunnel supports a 'passive (IP-less)' variant in which an insider agent with tap access to layer-3 traffic encodes messages in the ordering of TLS CHLO parameters belonging to incumbent connections traversing the wire, without originating any new IP flows. This bypasses NGFW explicit-proxy and CGNAT defenses that prevent direct socket connections from internal hosts to the Internet.
-
The Helol tunnel encodes data in the permutation of TLS CHLO list-type parameters (cipher suites, extensions, elliptic curves, signature hashing algorithms), achieving a median throughput of roughly 8–12 bytes/packet from cipher-suite permutation alone, significantly outperforming SNICat across median and upper quartiles. The per-packet payload from full factorial encoding is ⌊log₂ N!⌋ bits for a list of N elements, yielding ~17–22 bytes/packet at median cipher-suite list lengths observed in local captures.
-
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).
-
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.
-
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.
-
Beeline mobile users in certain Russian regions observed complete IP-based whitelisting: non-whitelisted IPs were unreachable at the ICMP level (traceroutes returned empty), TCP SYN packets were delivered but TLS ClientHello was silently dropped, and any domain resolving to a non-whitelisted IP was inaccessible regardless of SNI value. Only a curated set of IPs (primarily .gov.ru domains plus selected commercial sites) remained reachable.
-
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.
-
Internal Geedge documentation lists nine commercial VPNs as 'resolved,' providing staff with documented methods for identifying and filtering each protocol's traffic. The leak shows employees reverse-engineering popular circumvention tools to develop blocking signatures, consistent with GFW practices that have rendered most commercial VPNs inaccessible inside China.
-
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.
-
The classification model generalizes across different encrypted web protocols including HTTP/2 and QUIC, achieving high accuracy for both service-level and application-level classification objectives from a single trained model.
-
The paper demonstrates that domain-specific considerations for encrypted web protocols are routinely ignored in DL-based classifiers, and that a feature engineering approach combining protocol-aware features with neural networks outperforms raw byte ingestion approaches substantially.
-
Existing deep learning traffic classifiers, despite having millions of parameters, implement relatively simple logic based on TLS handshake header fields, which limits their robustness when encrypted protocols evolve to new versions. The paper identifies this as a fundamental limitation of the current state of encrypted traffic classification.
-
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.