pluggable-transport   Pluggable transport (Tor PT framework)

During the June 2025 Iran shutdown, circumvention tool performance diverged sharply by transport design. Psiphon's multi-protocol architecture sustained 1.5 million concurrent users—roughly one-third of its normal Iranian base. Lantern's "proxyless" protocol (domain-fronting via CDN, ~40% of Lantern's Iranian traffic) showed moderate success. Tor usage collapsed during the blackout but bridge connections surged and rebounded quickly after lifting. BeePass (serving 500k+ daily users at shutdown onset) used live A/B testing of port/obfuscation-prefix combinations to probe the censors' blocking parameters in real time. The Ceno Browser's P2P network grew from 600 active peers on June 13 to ~8,000 by July 11, indicating that decentralized fallback paths stayed up even during peak blocking.

2025-iran-shutdown-measurement §Tool Performance evaluation

Encrypted DNS has attractive anti-blocking properties for circumvention rendezvous, but its constraint of conveying only small amounts of data per message makes it difficult to use as a generic data-exchange channel. Fountain codes offer an uncomplicated way to transmit discrete, bounded-length messages over such channels, including those that are unordered or unreliable.

2026-cawthon-fountain-codes-censorship Abstract defense

A proof-of-concept implementation over UDP demonstrates the essential elements of fountain-code–based rendezvous: breaking a message into pieces, transmitting them over a lossy channel, and reconstructing them at the receiver. The authors also work out a prospective design for rendezvous over encrypted DNS.

2026-cawthon-fountain-codes-censorship Abstract evaluation

Padding-based client-side defenses including WTF-PAD and Walkie-Talkie are insufficient against active bandwidth perturbation: they reshape packet timing and burst structure but cannot remove the upstream rate limit imposed by the gateway shaper. BM-Net trained on a defense-aware dataset containing both undefended and WTF-PAD/Walkie-Talkie traces still achieves 99.65% F1, and the paper explicitly notes that 'client-side padding and burst reshaping may alter the logical traffic pattern, but they do not directly remove the rate limit imposed by the upstream bottleneck.'

2026-fan-activeflowmark-assessing-tor §VI.E.2, §VII detection

TrafficMoE achieves 97.65% accuracy and F1-score on the ISCX-Tor2016 dataset, substantially outperforming all baselines including the best pretraining-based competitor FlowletFormer (91.16% F1), by separately modeling protocol headers and encrypted payloads via dual-branch sparse Mixture-of-Experts rather than treating them as a unified byte stream.

2026-he-trafficmoe-heterogeneity-aware-mixture §IV-B, Table II detection

WTF4Nym, a burst-aware cover-traffic defense adapted to Nym's Poisson-rate architecture, reduces the Tik-Tok attack F1 score from 0.87 to 0.39 at moderate overhead (latency overhead 3.78×, bandwidth overhead 4.22×). This substantially outperforms directly applying WTF-PAD to Nym (F1=0.87), applying FRONT to Nym (F1=0.63), and the F1=0.65 achieved by FRONT on Tor at comparable overhead, by learning per-network burst distributions and injecting fake bursts that match those statistics. FRONT on Tor reaches F1 = 0.65 at 2.79x latency and 1.84x bandwidth, and under WTF4Nym the Time and N-gram feature leakage fall to 26.6% and 29.0% (Table 8).

2026-joll-s-website-fingerprinting-nym §6.2, Table 7 defense

Classification from the first 5 packets × 320 bytes (1600-byte burst) achieves near-perfect accuracy across Tor (F1=0.9990), VPN (F1=0.9871), malware (F1=0.9954), and IoT attack traffic (F1=0.9966), with IP addresses masked and only header and initial payload retained. The earliest portion of each packet provides sufficient discriminative information for a classification decision made within the first kilobyte of a flow.

2026-kulatilleke-mambanetburst-direct-byte-level §III-A, §V-A, Table II–III detection

FreeUp operates under a zero-positive (unsupervised) learning paradigm — trained exclusively on normal traffic with no labeled anomaly examples — yet achieves 95.53% AUC on Tor traffic and 85.44% AUC on DNS-over-HTTPS tunneling detection. This demonstrates that frequency-aware anomaly detectors generalize to novel circumvention protocols without requiring any labeled attack data, eliminating the labeling bottleneck that previously limited ML-based censorship detection.

2026-lian-decompose-understand-fuse §III, §V-B detection

The PPBR (probabilistic profile-based routing) protocol leaks user community membership through observable routing decisions: in a controlled experiment with 800 majority and 200 minority users, a statistical disclosure attack achieved a true positive rate of 100% and false positive rate of 0% when identifying minority users. Even under a conservative PPBR configuration (top 1/3 fraction acceptance), the attack achieved 100% TPR and only 0.4% FPR.

2026-ratliff-mirage §V detection

Six widely deployed VPN and circumvention tools—OpenVPN, WireGuard/NordLynx, NordWhisper, Orbot (Tor on Android), Lantern, and Psiphon—all failed to block internal IP inference, connection-state detection, and TCP reset injection under identical adversarial conditions on fully patched Android 16. Application-layer obfuscation in Lantern and Psiphon did not prevent TCP-layer disruption; Orbot's VPN-style encapsulation of Tor traffic was bypassed via the same tunnel-level side channels.

2026-tolley-architectural §5.2, §5.4–5.5 evaluation

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.

2026-wkrp-snowflake-targeted-dtls-filtering kad09 report + abstract team notes defense

Under the TrafficSliver defense — which splits traffic across multiple Tor entry nodes so no single observer sees more than a partial fraction of packets — TMWF collapses to a P@2 of 0.399 and ARES'23 to 0.429, while DEMUX retains a P@2 of 0.940, exceeding the next-best competitor by 2.5 points. WTF-PAD and FRONT are substantially weaker defenses, with most methods maintaining near-baseline performance under WTF-PAD.

2026-yuan-demux-boundary-aware-multi-scale §V-D, Table IV evaluation

Psiphon's multi-protocol design maintained access for approximately 1.5 million users during the June 2025 Iran shutdown — roughly one-third of its normal user base — while traffic throttling rendered many single-protocol circumvention tools functionally useless for anything beyond basic text communication.

2025-miaan-stealth-blackout Executive Summary — Resilient Response evaluation

The framework is designed for adoption into existing censorship-resistant systems in the same manner as uTLS — as a drop-in Go library requiring minimal code changes. Primary integration targets are Tor pluggable transports and WireGuard-based VPNs that currently lack built-in traffic obfuscation. Predefined hand-crafted schedules are provided alongside GAN-generated ones to enable developer stress-testing without model inference.

2025-pereira-extended §2.3 defense

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.

2025-tusing-minecraft-tunnels §1, §3 defense

MinecruftPT achieves mimicry by implementing enough of the Minecraft protocol to pass as a real client-server game session, not just in header structure but in behavioral sequence. The paper evaluates it under DPI and traffic-shape analysis, finding that faithful protocol mimicry at the behavioral level (packet sequence, message types, timing) is necessary to defeat classifiers that go beyond simple byte-pattern matching.

2025-tusing-minecraft-tunnels §3, §4 defense

MinecruftPT uses the TCP-based Minecraft protocol rather than a WebRTC/UDP approach. The paper notes this gives it an availability advantage in environments where WebRTC is filtered or where UDP is blocked — a common configuration in corporate or institutional networks and some national censorship regimes. This positions it as complementary to Snowflake in the circumvention transport portfolio.

2025-tusing-minecraft-tunnels §4, §5 defense

The proposed system adopts the turbo tunnel architecture to provide a reliability layer over lossy TURN relay paths and to allow traffic reassembly at a single bridge across multiple TURN proxies. Three encapsulation modes are specified: direct application data inside TURN messages, DTLS datagrams via WebRTC data channels, and video frames inside WebRTC media streams — the latter two mimicking the encapsulation strategies of existing WebRTC circumvention systems such as Snowflake and TorKameleon.

2025-vilalonga-extended §2 System Design defense

Traffic splitting across N TURN proxies (1 ≤ N ≤ M) is hypothesized to resist active probing because each TURN server responds to probing requests identically to a regular TURN server, providing no distinguishing signal. Additionally, proxy ephemerality combined with splitting allows on-the-fly migration to new proxies when existing ones are blocked, maintaining connectivity even under partial blocking.

2025-vilalonga-extended §3.3 Censorship Evasion defense

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.

2025-wkrp-leak-geedge-networks body detection

Despite Geedge's targeted Psiphon blocking in Myanmar (confirmed by OONI, June 2024–March 2025), Psiphon gained users during Myanmar's worst internet disruptions because all circumvention tools were simultaneously disrupted, with commercial VPNs collapsing first. Grant-funded tools with active anti-censorship investment (Psiphon, Tor) showed measurably greater resilience than commercial VPNs that do not invest in pluggable transport infrastructure.

2025-wkrp-leak-geedge-networks Body evaluation

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

Cross-layer RTT discrepancy (RTTdiff) is a protocol-agnostic fingerprint that exploits an inherent architectural property of all proxy setups: transport-layer sessions terminate at the proxy while application-layer sessions remain end-to-end. Evaluation across 10 proxy protocols—including VMess, Shadowsocks, VLESS, Trojan, XTLS-Vision, and obfs4-wrapped SOCKS—shows near-identical detection rates for all except obfs4, confirming the fingerprint is not tied to any specific obfuscation scheme. At FPR=0.01, per-website detection rates exceed 70% across all tested client and proxy location combinations.

2025-xue-discriminative §I, §VI-C detection

Because WATER uses a sing-box-compatible interface, a single WASM transport module written once is immediately usable by any application that embeds the WATER host runtime — including lantern-box (Lantern's proxy SDK), any other sing-box-derived client (33k+ GitHub stars as of 2024), and standalone WATER host binaries. This gives each new transport a substantially larger deployment surface than a single-app pluggable transport achieves.

2017-frolov-water-pluggable §4 deployment

WATER (WebAssembly Transport Executables at Runtime) defines a pluggable-transport architecture in which the transport logic is compiled to a WASM module that is loaded and executed at runtime by a thin Go host process. This separates the stable host ABI (dial, accept, read, write) from the rapidly-evolving transport logic, allowing new or updated transports to be delivered as small WASM binaries without recompiling or redeploying the host application.

2017-frolov-water-pluggable §2–3 defense

The threat model requires no DPI and was fully implemented as a Linux kernel module on a NETGEAR R6120 with only a 580 MHz processor, 16 MB ROM, and 64 MB RAM, adding negligible overhead. Unlike ML-based or DPI-based VPN classifiers, the statistical model operates pre-NAT on per-device private IP flows, making it immune to obfuscation techniques that alter packet payloads or disguise protocol handshakes.

2024-almutairi-fingerprinting §I, §IV detection

WATMs are designed to be generic: any application that embeds the WATER host runtime can use the same WATM binary without modification. This means a single successfully deployed transport module reaches users of every WATER-enabled application simultaneously, collapsing the per-app porting effort that traditionally delays circumvention tool updates.

2024-chi-just §1, §4 deployment

WATER (WebAssembly Transport Executables Runtime) separates transport logic from the host application by compiling it to a WASM module (WATM) that is distributed and loaded independently at runtime. Deploying a new or updated circumvention technique requires only distributing the new WATM binary and optional configuration — no change to the host application and no app-store update cycle is required.

2024-chi-just §1, §3 defense

Traditional circumvention tool development and deployment is slow because new strategies must be developed, integrated into each tool separately, and then distributed via platform app-stores. WATER's WASM module architecture specifically addresses this asymmetry: censors evolve blocking techniques quickly, while circumventors are bottlenecked by binary release cycles. The paper argues that dynamic WATM delivery breaks this bottleneck by decoupling transport updates from application releases.

2024-chi-just §1 defense

DeTorrent is implemented as a Tor pluggable transport on top of the WFPadTools/Obfsproxy framework and deployed against live Tor traffic; a modest VPS with 4 GB RAM and 2 vCPUs running at under 50% CPU utilization can defend five simultaneous connections in real time with no GPU required. Performance drops only 0.7% when the generator is trained on one dataset partition and tested on another.

2024-holland-detorrent §5.4 deployment

DeTorrent reduces closed-world Tik-Tok attack accuracy from 93.4% to 31.9% on the BE dataset — 10.5 percentage points better than the next-best padding-only defense (FRONT at 42.4%) — and reduces Deep Fingerprinting accuracy from 94.3% to 30.0%, at a bandwidth overhead of 98.9%. On the larger DF dataset, Tik-Tok accuracy falls from 97.7% to 79.5%.

2024-holland-detorrent §6.1, Table 4 evaluation

Censors employing deep learning can use DTLS connection duration as a precise identifier to classify and block Snowflake traffic. The paper proposes switching PT connections after a variable time limit as a countermeasure to prevent duration-based classification.

2024-lorimer-extended §4.3 detection

The authors propose a 'shim' pluggable transport that splits client traffic across N PT connections using unmodified existing PT bridges as proxies and a gateway bridge that correlates streams back into a Tor circuit via the Turbo Tunnel reliability pattern. This architecture enables all existing and future PTs to benefit from traffic splitting without modifying each PT's client or server code individually.

2024-lorimer-extended §3 defense

Initial attempts to split Snowflake traffic naively across multiple WebRTC proxies produced either no improvement in performance or a net negative effect. The authors attribute this to the wide variance in proxy network stability and bandwidth and flag it as an open problem requiring more advanced splitting algorithms.

2024-lorimer-extended Appendix A evaluation

Because traffic splitting is not ubiquitous network behavior, split PT traffic may appear anomalous to a censor, allowing them to distinguish normal PT use from split PT use even without classifying the underlying protocol. The authors flag this as a key open risk to be evaluated empirically and note that splitting across multiple bridges or multiple PT types may simultaneously raise and lower different detection signals.

2024-lorimer-extended §4.3 defense

When a user splits traffic across N paths, a censor observing a single path sees only a partial trace, substantially reducing the accuracy of classifiers trained on complete network traces. Prior Tor traffic-splitting work (TrafficSliver, CoMPS, multipath Tor studies) has validated this defense against website fingerprinting outside the PT context.

2024-lorimer-extended §1, §4.2 defense

HTTP Request Smuggling—a web-security vulnerability that exploits CL/TE header parsing ambiguities between a front-end (censor) and back-end (web server)—can be systematically repurposed as a censorship circumvention technique. By hiding a censored Host in the body of a benign outer request, the censor parses only the uncensored outer request while the destination server processes both, successfully bypassing HTTP censorship in China (19 vectors), Iran (254 vectors), and Russia (all 2,015 vectors) from the evaluated vantage points.

2024-m-ller-turning §3 / §8 defense

Circumvention tools circulate through word-of-mouth and underground distribution networks rather than official app stores, making the ecosystem opaque and creating a supply-chain attack surface: adversarially-operated tools (including, per prior work, apps linked to the People's Liberation Army) reach users through the same channels as legitimate tools. The survey documents that providers are aware of misbehaving players but lack coordinated mechanisms to flag or exclude them.

2024-xue-bridging §1, §4.3, §6 evaluation

The first multi-perspective study of the circumvention-tool ecosystem surveyed 12 leading CT providers collectively serving over 100 million users, plus CT users in Russia and China. Beyond technical blocking challenges, the study found that funding constraints, usability problems, misconceptions (users and providers hold inaccurate beliefs about each other's capabilities), and misbehaving players (tools operated by adversarial actors) are equally significant threats to the ecosystem's health — and are largely unaddressed by the academic research community.

2024-xue-bridging Abstract, §4, §6 evaluation

Despite fully encrypted protocols existing since obfs2 in 2012, the first documented evidence of the GFW passively detecting them purely by randomness appeared only in 2021 — approximately a decade later — and was limited to certain foreign IP address ranges and a subsampled fraction of traffic. Meanwhile, the GFW had been discovering obfs2/obfs3 servers via active probing as early as 2013, indicating censors found active-probing-based address discovery cheaper and more reliable than passive statistical classifiers for this protocol family.

2023-fifield-comments §5 evaluation

Localhost TCP connections between the pluggable transport, load balancer, and Tor processes exhaust the ephemeral port space because source and destination IP addresses are both 127.0.0.1, leaving only port numbers to distinguish sockets. The mitigation uses distinct addresses across the full 127.0.0.0/8 loopback range combined with a custom orport-srcaddr option that assigns random source addresses from 127.0.1.0/24, expanding available socket four-tuples by a factor of 256.

2023-fifield-running §4 deployment

Operating system defaults create two additional scaling ceilings beyond CPU: (1) the default file descriptor limit is insufficient above ~64,000 simultaneous connections, requiring LimitNOFILE=1048576 (1 million) in the systemd service; and (2) Linux's conntrack default of 262,144 tracked connections was approached during peak hours for the Snowflake bridge, necessitating doubling the table to 524,288 via sysctl net.netfilter.nf_conntrack_max.

2023-fifield-running §4 deployment

A single Tor process is limited to one CPU core, creating a performance ceiling that manifests at approximately 6,000 simultaneous users and 10 MB/s of Tor bandwidth. The solution is running multiple Tor processes (starting with 4, scaling to 12) sharing the same long-term identity keys, mediated by an HAProxy load balancer, which enabled a Snowflake bridge to scale from 2,000 to ~100,000 simultaneous users between December 2021 and February 2023.

2023-fifield-running §3 deployment

Multiple Tor instances initialized with copied identity keys will independently rotate their medium-term onion keys on a 28-day schedule, causing clients with cached older keys to fail circuit construction. The fix is blocking Tor's onion key rotation by pre-creating directories at the filesystem rename targets (secret_onion_key.old, secret_onion_key_ntor.old), which now effectively makes onion keys long-term secrets requiring the same protection as identity keys.

2023-fifield-running §3.2 deployment

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

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

At 64 bps FSK encoding over cellular voice, Dolphin achieves a bit error rate below 2% across all tested data sizes (100–5000 bytes), cellular providers, and geographic distances up to ~3600 miles. Rates of 128 bps and above cause BER to jump to 5–22%, making transmission too unreliable for practical use.

2023-sharma-dolphin §5.1, Table 1 evaluation

A 280-character tweet via Dolphin takes under 1 minute end-to-end; a 500-character email takes approximately 2.7 minutes (∼1 minute for ECDH secure-channel setup plus ∼1.7 minutes for data transmission). Performance was confirmed during a real Internet shutdown in Delhi, India, where a 300-character email transferred reliably in about 1 minute.

2023-sharma-dolphin §5.2, §5.4, Figs. 8–10 evaluation

An adversary introducing audio perturbations every 2.5 seconds (sufficient to corrupt each 20-byte chunk at 64 bps) degrades PESQ call quality to 1.6, below the 2.0 'unusable' threshold, making the attack self-defeating. However, targeting only acknowledgment windows (every ~12.5 s under Dolphin's default batch-of-5 configuration) achieves PESQ 3.6 — acceptable to human callers — while fully disrupting Dolphin data transfer.

2023-sharma-dolphin §6.2 defense

Using Geneva's genetic algorithm trained against Iran's live protocol filter, four evasion strategies achieving 100% success were discovered in under two hours: (1) injecting a fingerprint-matching PSH/ACK with a corrupt checksum before the real data; (2) sending two FIN packets before the SYN; (3) sending nine non-data-carrying packets (any flags, any seq/ack) during the handshake to exhaust the filter's per-flow packet limit; (4) a server-side variant that sends nine corrupted SYN+ACKs, inducing nine client RSTs before the real ACK, enabling fully unmodified clients to benefit.

2020-bock-detecting §5.2–§5.3 defense

Existing segmentation strategies effective against Iran's standard HTTP DPI can be counterproductive when the protocol filter is also active: if the first segment is fewer than 8 bytes, it fails the HTTP fingerprint check and trips the filter. However, segmenting such that the first segment is a valid HTTP fingerprint (≥8 bytes, well-formed verb + space) while splitting the Host: header into the second segment defeats both the protocol filter and the standard DPI censor simultaneously.

2020-bock-detecting §5.1 defense

Manually-crafted decision trees combining probe non-response, FIN/RST close type, and connection timing achieved a false-positive rate below 0.001% for obfs4, Lampshade, Shadowsocks, and OSSH across 1.9 million endpoints; for OSSH specifically, 7 of 8 flagged Tap endpoints were confirmed genuine Psiphon proxies by developers. MTProto was the sole exception, producing 3,144 false positives (0.56% of Tap, 0.02% of ZMap) because its infinite-timeout behavior is shared by a non-negligible population of common hosts.

2020-frolov-detecting §V-A, Table IV evaluation

Endpoints that never close a connection and never respond to any probe ('infinite timeout') represent 0.7% of the ISP Tap dataset and 42% of the ZMap active-scan dataset; this is the single most common probe-indifferent behavior in both datasets. MTProto already exploits this: its strategy of keeping failed connections open indefinitely produces the highest false-positive rate (0.56% of Tap) among all tested protocols, making it effectively uncountable at acceptable collateral-damage thresholds.

2020-frolov-detecting §VI, Fig. 13 defense

Across 433,286 endpoints from a 10 Gbps university ISP passive tap, 94% responded with data to at least one of 8 protocol probes (TLS, HTTP, STUN, S7, Modbus, DNS-AXFR, random bytes, empty); all five tested probe-resistant proxies (obfs4, Lampshade, Shadowsocks, MTProto, OSSH) never responded with data to any probe. This single filter reduces the suspect set from 433,286 to ~26,000 endpoints and rules out 94% of ISP-observed hosts as non-proxies with zero false negatives against the tested protocols.

2020-frolov-detecting §V, Table III detection

Each probe-resistant proxy exposes a unique TCP close-threshold fingerprint: obfs4 closes with FIN at 8,192–16,384 bytes and RST at the next multiple of 1,448 bytes beyond that; Lampshade at FIN 256 bytes / RST 257 bytes; Shadowsocks-python and -outline both at FIN 50 bytes (outline also RST at 51); OSSH at FIN 24 bytes / RST 25 bytes. A binary-search tool using random probes can discover these thresholds remotely without knowing any shared secret, providing a protocol-specific fingerprint independent of payload content.

2020-frolov-detecting §IV-C, Table II detection

Anonymization and circumvention tools (VPNs, Tor, etc.) are among the three most commonly blocked content categories across all commercial filters surveyed, alongside pornography and gambling. This holds across diverse products including Fortinet, Cisco, and government-deployed firewalls in Iran, Saudi Arabia, and Bahrain.

2020-raman-measuring §V-A-1, Fig. 7 evaluation

Frolov et al. (2020) found that obfs4, Shadowsocks Outline, Psiphon's OSSH, and Lantern's Lampshade are all identifiable by TCP flag and timing patterns when servers close connections on error, because each tool's timeout value and FIN/ACK behavior are distinct. Their recommended mitigation—'forever read' on errors so the prober always closes first—forces the server to terminate with FIN/ACK consistently across all code paths.

2020-v2ray-weaknesses §Our comments defense

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.

2015-frolov-the-use-of-tls §5 defense

Approximately 10% of respondents (n=23) held uncertain or incorrect beliefs about which actor was responsible for a given block, systematically conflating government censorship with geoblocking, paywalls, and platform-side restrictions. This misidentification cascaded into inappropriate tool selection and inaccurate risk assessment: users who could not distinguish state blocking from licensing restrictions could neither choose the right circumvention tool nor accurately gauge the legal jeopardy of accessing the content. Respondents specifically requested a pre-visit blocking-actor classification tool.

2017-gebhart-internet §5.2.3, §5.4.1, §6.2.1 evaluation

Of 229 Thai Internet users surveyed, 63% (n=144) had attempted to circumvent censorship, and of those, roughly 90% (n=132) reported success using VPNs (32.64%), proxies (32.64%), or Tor (23.61%). Failures were isolated to proxies (n=2), VPNs (n=2), and alternative searches (n=3), indicating that existing circumvention tools were technically adequate but that availability and comprehensibility—not raw capability—were the binding constraints on user success.

2017-gebhart-internet §5.2.1, Table 2 evaluation

Users in Thailand relied on incident-driven tool selection—running a fresh Google search for a proxy or VPN each time they hit a block—which the paper identifies as a systematic vulnerability: the Thai Royal Police exploited this pattern after the 2014 coup by linking a phishing application to a government block page, harvesting email addresses and gaining application-level access to Facebook profile information. The paper further notes that orchestrated stricter censorship could drive users to a government-operated malicious tool.

2017-gebhart-internet §5.3.3, §6.2.2 detection

In the heavily censored environment (E3), all successful connections used meek domain-fronting bridges (meek-amazon: 11 participants, meek-google: 9, meek-azure: 3); not a single participant successfully connected using flashproxy, fte, fte-ipv6, obfs4, or scramblesuit, despite all being available as built-in options.

2017-lee-usability §7.3.1, Table 3 evaluation

The authors recommend 'smart automation' for bridge selection: the client first connects via a hard-to-censor bridge, then contacts a central Tor server over that Tor connection to identify the best available bridge for the user's location and network conditions, then reconnects using that bridge — eliminating the manual trial-and-error that caused 79% of attempts to fail. This is contrasted with 'naive automation' (sequential blind retry) which avoids UI friction but wastes time on non-working bridges.

2017-lee-usability §8 defense

Participants spent 64–78% of their total connection time on the progress/waiting screen (not in the configuration UI), and the simulated censorship environment was the dominant predictor of connection time (Kruskal–Wallis χ² = 80.5, df = 2, p < 10⁻¹⁵). In E3, each failed bridge attempt added several minutes of timeout before the user could retry, compounding the overall latency.

2017-lee-usability §7.3.3, Table 4 evaluation

79% of total user attempts (363 of 458) to connect to Tor in simulated censored environments failed. In the most heavily censored condition (E3, requiring a meek or custom bridge), only 50% (10/20) of participants using the original interface connected, and even with the redesigned interface only 68% (13/19) succeeded within 40 minutes.

2017-lee-usability §7.3, Table 2 evaluation

A redesigned Tor Launcher interface significantly increased success rates (Pearson χ² = 2.808, p < 0.047) and reduced median connection time in E3 from 40:08 to 20:25 (Mann–Whitney Z = −1.84, p < 0.0328, r = 0.172); configuration time also dropped significantly (Z = −3.28, p < 0.0005, r = 0.307). Changes included eliminating yes/no bridge and proxy question screens, adding auto-detection for proxies, consolidating options, and surfacing meek bridges as a fallback recommendation.

2017-lee-usability §6.2, §7.3.1–7.3.3, Table 2 defense

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.

2017-matic-dissecting §V-C, Table I defense

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.

2017-matic-dissecting §II-B, §VI-A, Table V detection

Wiley's Bayesian classifier against obfuscated protocols (Dust, SSL, obfs-openssh) found that entropy detection achieved 94% accuracy using only the first packet, timing-based detection achieved 89% accuracy over entire packet streams, and length-based detection achieved only 16% accuracy.

2016-khattak-sok §2.4.1 detection

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.

2015-aceto-internet Table 1 detection

Format-transforming encryption (FTE) as deployed in the Tor Browser Bundle is detected by combining a URI Shannon-entropy threshold (≥5.5 bits) with an exact URI length check (239 bytes) on the first HTTP GET request. This embellished test produces only 264 false positives across approximately 10 million HTTP URIs in three campus datasets, while a length-only test causes roughly 15% false-positive rate over the same flows.

2015-wang-seeing §5.2, Figure 6 detection

CART decision-tree classifiers trained on entropy-based and packet-header features detect all five Tor pluggable transports (obfsproxy3/4, FTE, meek-amazon, meek-google) with average PR-AUC=0.987, TPR=0.986, and FPR=0.003 on synthetic traces. On 14 million real campus flows the highest per-obfuscator FPR is 0.65%, and meek-google yields only 842 false positives across all three datasets. However, cross-environment portability is poor: classifiers trained on an Ubuntu/campus setup and tested on a Windows/home network achieve true-positive rates as low as 52% with false-positive rates reaching 12%.

2015-wang-seeing §6.1, Tables 8–9 detection

The paper demonstrates that 'having no fingerprint is itself a fingerprint': randomizing obfuscators that emit uniformly random bytes from the first packet are detectable precisely because conventional protocols (TLS, SSH, HTTP) always begin with fixed plaintext headers. This structural distinction requires no deep payload parsing — the attack operates on only the first TCP packet — and achieves TPR=1.0 / FPR=0.002 against obfsproxy3/4 using commodity-implementable statistics.

2015-wang-seeing §1, §5.1 defense

CloudTransport Cirriform in tunnel and proxified-Tor modes achieves performance comparable to Tor with Obfsproxy across Web browsing (Alexa Top 30 front pages), 300 KB SCP uploads, 10 MB YouTube uploads, and 5-minute 480p streaming video. Bandwidth overhead per message is 350–400 bytes for Amazon S3, with HTTPS adding an extra 2–3% overhead. Per-page browsing costs are as low as $0.00100¢ (Cumuliform on S3), with idle-polling costs of $0.185/day plus $0.34/day/connection for Cirriform on S3.

2014-brubaker-cloudtransport §5, Table 3, Table 4 evaluation

Four circumvention tool names were explicitly blocked as URL substrings with zero allowed requests passing through: hotspotshield (126,127 blocked), ultrareach (50,769), ultrasurf (31,483), and the generic keyword israel (48,119). All matching requests — including update checks and background pings — were denied at 0% pass-through rate.

2014-chaabane-censorship §5.4, Table 9 detection

TRIST integrated with StegoTorus as a one-hop SOCKS proxy introduces minimal additional bandwidth overhead: JPEG steganography throughput falls between StegoTorus's PDF and JSON schemes across link delays of 20–400 ms and 1–4 parallel circuits. The steganographic expansion factor is 1:6 to 1:12 (message bytes to cover JPEG file length), adequate for basic web surfing.

2014-connolly-trist §6 evaluation

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.

2014-jones-facade §4, §5.1 defense

LibFTE exposes a regex-based API (Python, C++, JavaScript) that instantiates DPI-defeating FTE schemes from a regular-expression format specification alone, without expert cryptographic knowledge. The DCRS FTE scheme implemented in the library makes ciphertexts indistinguishable from real HTTP, SMTP, SMB, or other network-protocol messages under state-of-the-art DPI, and was already integrated into the Tor Browser Bundle at time of publication.

2014-luchaup-libfte §1, §7 defense

GoHop without traffic shaping achieved 76.8–78.5 Mbps (virtual NIC) on a 1 Gbps LAN; traffic shaping reduced this to 58.1 Mbps (~26% overhead from fragmentation). In a Beijing-to-Seattle real-world download test, GoHop delivered 960–999 KB/s against a 1,544 KB/s direct baseline, with the 96.7 Mbps WAN link—not GoHop—as the bottleneck. This compares to Tor's 40–300 KB/s (30–80 KB/s with obfuscation plugins such as SkypeMorph).

2014-wang-gohop §V.B, Table II, Table III evaluation

Obfsproxy (predecessor to obfs4) listens on randomized ports as an explicit defense against discovery by comprehensive Internet-wide scanning, because an adversary must scan all 65,535 ports to locate bridges rather than a single known port — multiplying scan cost by roughly 65,000× relative to a single-port sweep.

2013-durumeric-zmap §4.4 defense

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.

2013-durumeric-zmap §4.4 detection

Manually-generated FTE regexes achieve a 100% misclassification rate against all six tested DPI systems — appid, l7-filter, YAF, bro, nProbe, and the proprietary enterprise-grade DPI-X — for HTTP, SSH, and SMB target protocols. Each regex took less than 30 minutes to specify and debug against known classifiers.

2013-dyer-protocol §4.2, Figure 4 defense

An FTE-tunneled Tor circuit using intersection, manual, and auto HTTP formats successfully traversed the Great Firewall of China from a VPS inside China to a server in the United States on port 80. A persistent tunnel polling a censored URL every five minutes remained active for one month until VPS account termination, with no blocking observed.

2013-dyer-protocol §6 deployment

The bulk-transfer mode requires both the censored client and the cooperating proxy to accept incoming TCP connections, rendering it unusable for clients behind NAT without port-forwarding capability. Rendezvous mode is unaffected because it only requires the client to send a single outbound request. The authors note that many real-world residential users are behind NAT, limiting practical deployment of the bidirectional channel.

2013-fifield-oss §6 evaluation

OSS operators—not the censor—are the primary abuse-detection risk for high-bandwidth use. PDFmyURL's published policy blocks clients making more than 100 requests in 2 hours that cumulatively consume more than 1000 seconds of server CPU and more than 10% of CPU resources. The authors were blocked by PDFmyURL and Twitter during high-bandwidth tests, suggesting that covert use must stay well below these thresholds.

2013-fifield-oss §6.2 evaluation

OSS throughput varies from 250 B/s (vURL/HTTP-302) to 265 KB/s (PDFmyURL/JavaScript-onload). High-rate OSSes—Dr.Web at 20 KB/s, GoMo at 22–175 KB/s, PDFmyURL at 160–265 KB/s—support bulk bidirectional transfer; low-rate OSSes (AdSense 500 B/s, vURL 250 B/s) are suited only for rendezvous. Concurrent streams scale linearly (2× aggregate throughput) for all tested OSSes except AdSense, which rate-limits per source IP.

2013-fifield-oss §5.2, Table 5 evaluation

Injecting a single replayed ACK packet every 100 ms into a SkypeMorph session is sufficient to permanently stall data transfer: the server continuously resets its sequence counter back to the replayed position and never advances, while legitimate VoIP call traffic is completely unaffected. The attack requires the censor to induce only a small amount of server-to-client packet loss to prevent the legitimate ACK counter from overtaking the injected value, as shown in Figure 5b.

2013-geddes-cover §4.3.3, Figure 5 detection

By targeting SkypeMorph's deterministic ACK-flagging schedule (one ACK every ~100 ms) and capping overall packet loss at 5–20%, a censor can drop up to 47% of ACK packets, reducing SkypeMorph throughput from its normal ~200 KB/s to 5–10 KB/s (a 90–95% reduction) while VoIP call quality remains within acceptable MOS thresholds. The attack exploits the reliability mismatch between the loss-tolerant UDP cover channel and the TCP-like retransmission layer SkypeMorph builds over it.

2013-geddes-cover §4.3.2, Figure 4 detection

Protocol mimicry approaches (SkypeMorph, StegoTorus, CensorSpoofer) do not execute the target protocol in full and leave detectable discrepancies: SkypeMorph fails to replicate Skype's TCP handshake, and CensorSpoofer's IP-spoofing downstream channel enables active traffic analysis by censors who can inject manipulated packets and observe whether the purported VoIP endpoint reacts. The authors state that morphing approaches provide no provable indistinguishability, and protocol evolution further invalidates mimicry over time.

2013-houmansadr-i §IX / §X detection

Hypothetical fixed parrot systems (SkypeMorph+ and StegoTorus+) that correct all passive detection failures remain unambiguously detectable via active and proactive attacks (Table II). Supernode cache flushing and TCP control channel manipulation — e.g., sending RST causes genuine Skype to drop the call immediately while parrots produce no reaction — distinguish them from genuine Skype because the parrot cannot actually execute Skype protocol logic.

2013-houmansadr-parrot §VII-B, §VII-C, Table II detection

The authors enumerate 12 requirements a parrot system must satisfy simultaneously (Correct, SideProtocols, IntraDepend, InterDepend, Err, Network, Content, Patterns, Users, Geo, Soft, OS) while a censor need detect only one failure. They conclude 'unobservability by imitation is a fundamentally flawed approach' and recommend embedding covert traffic in genuine encrypted payloads of a real running protocol (e.g., FreeWave in Skype voice, SWEET in email), which constrains detection to OM adversaries performing large-scale multi-flow analysis.

2013-houmansadr-parrot §XI defense

SkypeMorph and StegoTorus-Embed fail 5 of 9 standard Skype identification tests (Table I), including the TCP control channel (T9), SoM packet headers (T3), and periodic message exchanges (T6/T7). All failures are detectable by a local (LO) passive censor at line speed without requiring ISP-scale statistical analysis.

2013-houmansadr-parrot §VII-A, Table I detection

The StegoTorus-HTTP module returns '200 OK' for non-existent URIs, produces no response to HEAD, OPTIONS, DELETE, and TEST method requests, and omits xref tables from generated PDF files. Using httprecon with 9 request types, the StegoTorus server is distinguishable from any real HTTP server by an OB (resource-limited) censor that records port-80 destination IPs at line speed and fingerprints them offline.

2013-houmansadr-parrot §VIII-B, §VIII-C, Table III detection

Among 1,175 Chinese circumvention users surveyed in late 2012, purpose-built anti-censorship platforms showed severe attrition: Freegate had 44.3% former users but only 15.3% current users, while GoAgent and paid VPNs (piggybacking on commercially indispensable infrastructure) were the top two most-used tools in the past month. The median respondent had used four different types of circumvention tools, indicating frequent switching driven by blocking events.

2013-robinson-collateral §2 Tool Usage, Figure 2.1 evaluation

ScrambleSuit defeats active probing by requiring clients to prove knowledge of an out-of-band shared secret before the server responds; a probing censor receives only silence. Two mechanisms are provided: session tickets (preferred for non-Tor applications) and an authenticated UniformDH handshake (optimized for Tor's shared-secret bridge distribution model), with both producing payloads computationally indistinguishable from random.

2013-winter-scramblesuit §4.1 defense

DPI boxes used for censorship do not rely solely on simple regular expressions but also employ context-sensitive languages for protocol identification. The paper notes that precise knowledge of these DPI patterns could be fed directly into format-transforming encryption to enable targeted protocol misidentification.

2013-winter-towards §5 defense

Flash proxies successfully relayed Tor traffic from within China in December 2011, but the test relied on a simple HTTP-based rendezvous blockable by IP address; the authors identify rendezvous — getting just a few bytes (the client's IP address) out of the censored region — as the bottleneck that determines whether the entire proxy system remains operational.

2012-fifield-evading §4.4, §6 deployment

Because browser-based proxies can only initiate outbound connections, flash proxies connect to censored clients rather than the reverse, requiring the facilitator to maintain a registry of client IP addresses; a censor can impersonate a legitimate flash proxy to query the facilitator and enumerate the IP addresses of circumvention users.

2012-fifield-evading §5.1 detection

Applying Little's law to measured traffic parameters (mean inter-arrival time 1/λ = 1407.6 s, mean visit duration µ = 285.8 s), 100 volunteer web pages each embedding the flash proxy badge can support approximately 203 simultaneous censored clients; capacity scales linearly, so 1,000 such pages support ~2,030 clients.

2012-fifield-evading §4.3 evaluation

Flash proxies provide mean throughput of 79.7 KB/s when uninterrupted — comparable to direct Tor (69.5 KB/s) — but throughput drops to 56.6 KB/s (20–40% lower) when proxies alternate on 8-second duty cycles, with most variance attributable to Tor circuit reconstruction overhead rather than transport switching.

2012-fifield-evading §4.2 evaluation

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.

2012-fifield-evading §5.1 detection

SkypeMorph decouples bridge reachability from IP address: clients identify a bridge solely by its Skype ID, so a bridge can change IP address and port at any time without redistributing contact information through BridgeDB. This makes IP-list blocking of known bridges ineffective; a censor that discovers a bridge's current IP cannot prevent the bridge from migrating to a new one while remaining reachable to existing clients.

2012-moghaddam-skypemorph §8 (Mobile Bridges) defense

After a Tor client inside China connected to a US-based bridge, that bridge subsequently received a series of Tor connection-initiation messages from different Chinese hosts — consistent with GFW active probing triggered by the initial client connection. The probe burst was followed by loss of the original client connection, demonstrating a two-phase detect-then-block pattern: passive identification of suspicious traffic triggers active re-probing to confirm the protocol before blocking.

2012-moghaddam-skypemorph §1 detection

SkypeMorph's packet size and inter-packet delay distributions are statistically indistinguishable from real Skype video calls: Kolmogorov-Smirnov tests on both the naïve traffic-shaping and enhanced Traffic Morphing outputs report p > 0.5, indicating no significant difference from the Skype target distribution. The original Tor traffic distribution, by contrast, is considerably different from Skype, validating the need for the morphing layer.

2012-moghaddam-skypemorph §7, Figure 6 evaluation

SkypeMorph achieves a goodput of 33.9 ± 0.8 KB/s (naïve shaping) and 34 ± 1 KB/s (enhanced Traffic Morphing) versus 200 ± 100 KB/s for a normal Tor bridge, with overhead of ~28% compared to 12% for normal Tor. The two traffic-shaping methods perform statistically identically (KS p > 0.5), but the overhead grows during silent periods because the transport must transmit padding to maintain Skype's constant bitrate even when the Tor buffer is empty.

2012-moghaddam-skypemorph Table 1, §8 evaluation

Tor's fixed 512-byte cells packed into TLS 1.0 records produce a characteristic TCP payload of 586 bytes (512 + 74 bytes of TLS overhead). A perimeter filter running a simple exponential moving average (τ ← ατ + (1−α)1ₗ₌₅₈₆, α=0.1, T=0.4) identifies Tor flows within a few dozen packets; this attack succeeds at backbone rates of ~540,000 packets/second on commodity hardware. Obfsproxy does not alter packet sizes or timings and therefore does not defeat this classifier.

2012-weinberg-stegotorus §5.1, Figure 3 detection

StegoTorus distributes a fixed set of packet traces and HTTP covertext databases with the software, but allows users to record their own; classifiers trained on the distributed covertext will not generalize to user-generated databases. The paper further notes that reusing a small number of traces repeatedly creates a statistical fingerprint because censors can learn conversation patterns from packet sizes and timings alone, implying that trace diversity must be maintained over time.

2012-weinberg-stegotorus §4.1.1, §5.2 defense

During the December 2010 Nobel Peace Prize ceremony blocking in China, of two Psiphon nodes brought online for the BBC English News site, one was blocked almost immediately while the other remained available throughout the weekend, serving 387 logins on the ceremony day with no direct promotional channel available. A non-BBC-branded live-stream page promoted via a bit.ly URL released one hour before the ceremony received 4,236 clicks, with approximately 50% from China, accounting for about one-third of total stream viewers.

2011-kathuria-bypassing §3.3 deployment

During the June 2009 blocking of BBC Persian in Iran, the BBC observed a more-than-fourfold increase in traffic to its BBC Persian TV Internet live stream, with geographic IP lookups confirming the majority of streaming originated from inside Iran. The BBC deployed Psiphon web-proxy nodes — chosen over alternatives because they required no executable installation on the user's PC and could be hosted by a trusted third party — promoted via email newsletters, Twitter, Facebook, and on-air announcements.

2011-kathuria-bypassing §3.1 deployment

BBC Chinese's multi-channel Psiphon promotion — radio broadcasts three times daily with additional trails, daily email newsletters, and ad hoc tweets — allowed its service to reach page-view parity with BBC Persian's established Psiphon deployment within eight weeks of launch in September 2010. Separately, a third-party BBC Persian iPhone app using full-text RSS feeds received over 50% of its downloads from inside China, demonstrating that syndicated full-text content distributed across multiple third-party sites and apps is difficult for censors to enumerate and block.

2011-kathuria-bypassing §3.2, §4.3 deployment

BridgeSPA encodes a 32-bit SHA256-HMAC ConnectionTag derived from a time-limited MACKey into the TCP SYN packet's ISN (lower 3 bytes) and TCP timestamp (lower 1 byte) fields—values that are uniformly random in Linux 2.6 and therefore carry the tag innocuously. Bridges silently drop unauthorized SYN packets without returning any response, preventing aliveness queries. MACKeys rotate every 1–7 days (bridge-configured), so hoarded descriptors become stale within the epoch.

2011-smits-bridgespa §4, §5 defense

Global anonymity is maximized when the anonymity set is large and behavior is uniformly distributed: 'global anonymity is maximal iff all subjects within the anonymity set are equally likely.' Strong global anonymity does not protect individual 'likely suspects' — even in a strong-anonymity system, one user with distinctive behavior may have weak individual anonymity. Strong or even maximal global anonymity does not imply strong anonymity of each particular subject.

2010-pfitzmann-terminology §3 defense

Adding dummy traffic to any anonymity mechanism yields the corresponding kind of unobservability: 'A mechanism to achieve some kind of anonymity appropriately combined with dummy traffic yields the corresponding kind of unobservability.' DC-nets achieve sender anonymity and MIX-nets achieve relationship anonymity; with dummy traffic both achieve the corresponding sender and relationship unobservability respectively.

2010-pfitzmann-terminology §8 defense

Pseudonymity uses persistent identifiers other than real names, enabling accountability while providing partial unlinkability; however, use of the same pseudonym across different contexts enables linkability: the attacker can link all data related to a pseudonym. Unlinkability of two messages requires that the attacker cannot sufficiently distinguish whether they share a sender or recipient; for a scenario with n senders, this holds iff the probability of common authorship is sufficiently close to 1/n.

2010-pfitzmann-terminology §4, §9, §11 defense