bridges   Bridges / private relays

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

Shared domestic-entry transit architectures (国内入口 + 海外转发) suffered disproportionate impact because all nodes sharing a single domestic entry point went down simultaneously when that entry was reported and cut. Operators described configurations degrading from 'three-line redundancy to single entry,' eliminating failover capacity under enforcement pressure.

2026-ermao-april-airport-outage §为什么中转机场这次受冲击更明显 detection

Transit/relay architectures (国内入口 + 海外转发) suffered disproportionate impact because multiple nodes share a single domestic entry point: when that entry is reported or cut, the entire batch of nodes fails simultaneously. Operators described this as "三线变单线" (three-line to single-line collapse), with only direct-connect fallback remaining — at higher latency and with worse peak-hour performance.

2026-ermao-april-airport-outage §为什么中转机场这次受冲击更明显 evaluation

Using a 1%-scaled tornettools simulation with historical Tor consensus data, a single adversary-controlled exit relay at 148 Mbps yields an exit-observation probability of approximately 2.13%; deploying 5 adversary-controlled exit relays pushes observation probability above 10%. The aggregation effect is concave — repeated observations across T independent windows compound via 1 − (1 − Pcorr)^T.

2026-fan-activeflowmark-assessing-tor §VI-A evaluation

NATA requires no endpoint compromise, no Tor-browser modification, and no payload decryption; it operates solely from (1) an upstream gateway controlling Tor TCP connections via standard Linux tc/wondershaper rate-limiting and (2) one or more adversary-controlled exit relays passively recording packet traces. The shaper identifies Tor connections using flow-level metadata (client IP, relay IP, port, transport protocol), meaning the adversary needs only ISP or AS-level vantage, not host-level access.

2026-fan-activeflowmark-assessing-tor §III-A, §IV-A detection

Using tornettools-based simulations with historical Tor consensus data scaled to 1% of the real network (80 relays), the adversary's exit-observation probability p̂exit grows monotonically with adversary-controlled bandwidth: a single exit relay at 148 Mbps yields p̂exit ≈ 2.13%, and 5 adversary-controlled exit relays push p̂exit above 10%.

2026-fan-activeflowmark-assessing-tor §V.B, §VI.A evaluation

Simulations extending the ENEM19 game-theory framework show that ephemeral proxy schemes (modeled on Snowflake/Lantern) effectively neutralize both the "optimal" and "aggressive" censors from the original framework. In overprovisioned settings (proxies arriving at 250/step vs. 200 clients/step), even the null censor scenario outperforms either censor in equal-arrival settings. Over 90% of waiting users receive a proxy within 1 time step. The critical variable is not censor sophistication but proxy arrival rate relative to client demand—high proxy churn combined with high arrival rate defeats both enumeration strategies tested.

2026-fares-game §4, Fig 1, Fig 2, Table 1 evaluation

The host-profiling censor (passive traffic analysis: count connections per server, block those exceeding a threshold τ within a window w) blocks essentially all circumvention user traffic within 30 time steps for all classifier qualities tested (ρ_TP ∈ {0.9, 0.95, 0.99}), while causing far less collateral damage than zig-zag (never exceeding ~30% innocent server blocking). Snowflake resists this attack well: with w=3, τ=3, over 94.48% of users receive a proxy within 2 steps even with worst-classifier rules, and final unblocked server rates are 91.24–99.04%. The host profiling approach is feasible for passive censors who cannot enumerate the distribution channel.

2026-fares-game §5.2, Table 2, Table 3 detection

Multi-censor simulations show that single-censor-optimized distribution strategies perform suboptimally in realistic multi-region deployments. When two networks have different censor strategies (e.g., one optimal, one zig-zag), the distributor cannot detect that a proxy is blocked until all censors have blocked it; this leaves clients without reachable proxies despite the proxy appearing "available" from the distributor's view. The authors conclude that "single-censor evaluation does not accurately predict more realistic deployment performance." A zig-zag censor in one region with 0.25 weight caused 44.4% collateral damage while reducing proxy lifetime to a median of 4 steps.

2026-fares-game §6, Table 4 evaluation

The zig-zag traffic analysis attack (confirmed supported in Geedge TSG leak) rapidly enumerates all static proxy pools. With ζ_watch ∈ {4, 6} steps and a best-quality classifier (ρ_TP=0.99, ρ_FP=0.001), almost total proxy enumeration and user blockage occurs well before step 300. Even ζ_watch=2 leaves ~50% of users blocked. Collateral damage is high across all settings when ζ_watch ≥ 4: eventually ~50% of innocent servers are also blocked. However, Snowflake-style ephemeral proxies resist zig-zag effectively: reachability remains above 95% after 360 steps because churn prevents the censor from expanding its known proxy set beyond agents' direct assignments.

2026-fares-game §5.1, Fig 3, Fig 4 detection

Despite AWS, Google, and Microsoft having publicly withdrawn CDN-level domain-fronting support to preserve commercial relationships with censoring states, domain fronting remains functional on AWS Lambda as of early 2026. Microsoft Azure Functions explicitly rejects mismatched SNI/Host headers, whereas AWS Lambda permits a client to present a legitimate *.lambda-url.*.on.aws SNI while routing internally to a different serverless function via the HTTP Host header.

2026-kang-censorless-serverless §4.7 defense

CensorLess's function refresher automatically retires serverless bridges and deploys fresh ones in batches across diverse regions; the expected time until a bridge is identified and blocked in practice is 2 days (per Fifield et al.), while Tor bridges in China are discovered within 2–36 days. The old bridge is only removed after all clients have completed live migration to a new URL, maintaining uninterrupted connectivity.

2026-kang-censorless-serverless §4.5 defense

During the cold-start phase on a newly migrated serverless bridge (approximately the first 0–50 invocations), average function duration spikes to over 6,000 ms and success rate occasionally drops below 90%. The system stabilizes between invocations 100–200, with average durations consistently below 1,000 ms and success rates above 95%; AWS Lambda by default supports up to 1,000 concurrent invocations without throttling.

2026-kang-censorless-serverless §6.2, Figure 5 evaluation

CensorLess's threat model explicitly relies on a rational-censor assumption: the censor will not block entire cloud-provider IP ranges or domain namespaces because the collateral damage to legitimate business services would be politically and economically unacceptable. AWS Lambda's inherent IP-address ephemerality (new IPs on each invocation, function lifetime up to 15 minutes) means even censors willing to attempt enumeration face a continuously shifting target distributed across the cloud provider's global address space.

2026-kang-censorless-serverless §4.2 defense

CensorLess vanilla mode costs $0.27/month for a single proxy processing 6.76 GB of traffic monthly, a 97.1% reduction (34.4×) over SpotProxy's optimal single-NIC configuration ($9.28/month). The private mode, which adds a t4g.micro EC2 VPS for end-to-end encryption via SOCKS, costs $3.41/month — still 63.3% cheaper than SpotProxy's cheapest option. Costs remain below $3.50/day even when scaling to 300 proxies.

2026-kang-censorless-serverless §6.3, Figure 6 evaluation

Two mechanistically distinct blocking categories account for Tor exit-node inaccessibility: explicit blocks (deliberate CDN/WAF configuration, e.g., Akamai Bot Manager renders AirBnB inaccessible over Tor) and dynamic blocks (abuse-detection systems that flag Tor exit-node IPs because pooled traffic from diverse users raises apparent abuse scores, triggering rate-limiting or blocking despite no explicit Tor policy). Cloudflare does not block Tor by default, but its aggressive IP scoring results in disproportionate blocking in practice.

2026-micallef-reportor-facilitating-user §6.1.1 evaluation

MIRAGE constructs a global mobility graph using locally differentially private per-user submissions, requiring only O(ln(|M|/β) / (α²ε²)) users to achieve per-edge accuracy α with probability 1−β. For a 100-district map with ε=0.05 and α=0.5, fewer than 1 million users suffice for top-2 district reporting; for top-3 districts the requirement drops to under 200K users.

2026-ratliff-mirage §VI-B defense

Obscura proxies resist active probing by never exposing open ports or accepting incoming connections; combined with a large ephemeral volunteer pool (analogous to Snowflake's scale), the vast IP address space and rapid proxy rotation make exhaustive enumeration infeasible without causing sufficient collateral damage to deter the censor — consistent with the absence of observed blind-blocking campaigns against Snowflake.

2026-vilalonga-obscura-enabling-ephemeral §5.1 defense

A Russian user ran a self-built snowflake-proxy from inside the censored country using the 'random-and-mimic' fingerprint option, successfully serving Iranian, Turkmen, Russian, and German Tor users, demonstrating that the blocking is unidirectional (targeting client DTLS hellos) and that snowflake-broker and rendezvous domains (snowflake-broker.torproject.net, snowflake-01/02.torproject.net) remained accessible behind the .net SNI — only the DTLS data channel was filtered.

2026-wkrp-snowflake-targeted-dtls-filtering kad09 original report, Issue #422 comment evaluation

A Tor relay serving as a Bento server and hosting a CenTor instance for 10,000 simultaneous clients experienced only approximately 0.4% performance degradation compared to a vanilla relay; running 20 concurrent CenTor instances on a single relay caused roughly 1% degradation. Shadow-aware routing in a low-relay-density region (US, 933 of 6,666 relays in shadow) produced 0.7% relay degradation while delivering 3.6% client performance improvement.

2025-arora-improving-performance-security §5.2 evaluation

CenTor, a CDN for Tor onion services deployed as a Bento network function, achieved approximately 56.4% reduction in download time compared to standard Tor under a geographically-aware shadow configuration, while location-unaware CenTor (reducing hops without shadow restriction) achieved a 34.5% reduction. The key mechanism is eliminating the server-side 3-hop circuit by deploying replicas in non-anonymous mode, cutting the default 6-hop onion service path to 3 hops.

2025-arora-improving-performance-security §5.1 evaluation

CenTor protects origin onion service operators from DoS and deanonymization by routing all client traffic through geographically distributed Bento replicas running inside SGX-based Trusted Execution Environments (TEEs). The original operator can go fully offline after deploying static content; replicas enforce confidentiality and integrity of hosted content with ephemeral per-enclave encryption keys, preventing malicious Bento node operators from inspecting or modifying content even if they control the underlying hardware.

2025-arora-improving-performance-security §3.1, §5.3 defense

The blocking-resistance of CenPush derives from the collateral damage a censor would incur by blocking APNs or FCM: doing so would break push notifications for every app on iOS or Android respectively. This is the same collateral-damage deterrent mechanism that makes CDN-based domain fronting and TLS-over-CDN transports resilient, applied to the control plane rather than the data plane.

2025-sharma-cenpush §2, §4 defense

CenPush uses mobile platform push-notification services (APNs, FCM) as a blocking-resistant control channel for distributing fresh proxy IPs and client configuration to users in censored regions. Push notification infrastructure is already widely deployed, has high collateral-damage cost to block, and is a server-push channel — meaning the client never has to initiate a query to an out-of-band endpoint that a censor could block.

2025-sharma-cenpush §1, §3 defense

CenPush is implemented and evaluated specifically for Tor bridge distribution, replacing the existing polled bridge-line fetching with push delivery. The design is presented as a general mechanism applicable to any circumvention tool that needs to push fresh proxy addresses to clients — not just Tor bridges — whenever censors block the tool's normal update channel.

2025-sharma-cenpush §3, §5 deployment

Snowflake's sustained operation in heavily censored regions demonstrates that WebRTC must remain accessible to users, which in turn requires that TURN servers remain unblocked to support NAT traversal for peer-to-peer WebRTC connections. This transitive unblockability makes TURN service providers viable rendezvous channels for the Bridge Distribution Problem.

2025-vilalonga-extended §3.2 Bridge Distribution Problem 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

The paper defines Unauthenticated Push (UP) channels as a distinct archetype from signaling/rendezvous channels, characterized by three properties: strictly unidirectional delivery, no client authentication or account association required, and higher bandwidth (kilobytes to megabytes) to support software updates rather than just minimal proxy-address exchanges. This design deliberately shifts operational-security burden onto senders to approach receiver anonymity.

2025-vines-extended §1–§3 defense

Among surveyed channels, Skyhook, PushRSS, SQS, AMPCache, and Meek satisfy all three UP channel properties (unidirectional, no client auth, higher bandwidth); CloudTransport and Raven do not because they require authenticated user accounts; Tor's email- and Telegram-based bridge distribution also fails the no-auth requirement. The analysis was prompted in part by the 2022 GFW entropy-based blocking event, which required software updates to be pushed to users before fully-encrypted protocols could resume functioning.

2025-vines-extended §3 defense

A concrete UP channel implementation uses keyed steganographic encoding embedded in videos posted to a public hosting service (e.g., flickr.com), addressed via a time-epoch pseudorandom tag generator drawn from publicly known trending-topic lists. Clients query the top-n videos matching the current epoch tag and attempt decryption; real-world video size variability supports data transmissions from a few kilobytes (configuration updates) to megabytes (software updates).

2025-vines-extended §2 defense

Snowflake has been deployed in Tor Browser and Orbot for several years and served as a significant circumvention tool during the Russia 2021 network disruptions and Iran 2022 protests. The paper documents a history of deployment and blocking attempts, providing empirical evidence that the ephemeral WebRTC proxy design has sustained availability under real censor pressure across multiple high-profile events.

2024-bocovich-snowflake §1, §6 deployment

Snowflake's blocking resistance rests on a large, constantly changing pool of volunteer WebRTC proxies implemented as lightweight JavaScript browser extensions or web pages. Because the proxy population is in constant churn and new addresses appear faster than censors can enumerate and block them, IP-list blocking is structurally ineffective. The system is designed so that when an in-use proxy goes offline, the client seamlessly migrates to another with no disruption to upper network layers.

2024-bocovich-snowflake §1, §2 defense

Snowflake proxies are simple enough to run as JavaScript inside a web page or browser extension, making them far cheaper to operate than a traditional VPN or proxy server. This low operational cost enables a large volunteer pool (orders of magnitude more participants than server-hosted bridge networks), which is the structural property that makes IP enumeration hard for censors.

2024-bocovich-snowflake §2, §3 defense

NetShuffle targets edge networks — small autonomous systems and entities that obtain IP address blocks from upstream providers — as a new class of support base for circumvention infrastructure. This class has received scant attention from prior work, which has focused on cloud providers and volunteer desktop machines. Edge networks represent a large pool of diverse IP space that is harder to block via ASN blackholing compared to a small number of major cloud providers.

2024-kon-netshuffle §1, §2 defense

NetShuffle decouples regular proxy services (e.g., HTTPS proxies, Tor bridges) from their network addresses via continuous in-network change using programmable switches at edge networks. Because the network location of a proxy is in constant flux, blocking by IP or address enumeration becomes structurally ineffective: the proxy service itself is unchanged but its visible address rotates continuously.

2024-kon-netshuffle §1, §3 defense

NetShuffle was prototyped in testbed environments and operated on a live campus network for more than one month. The evaluation shows that the in-network address shuffling provided by programmable switches is transparent to both services and clients and incurs negligible performance overhead, validating the drop-in appliance deployment model.

2024-kon-netshuffle §5 evaluation

SpotProxy's active fleet-management algorithm continuously searches for cheaper Spot and regular VM instances and migrates the proxy fleet to lower-cost options. The paper demonstrates that this approach yields significant cost savings compared to operating a fixed fleet of on-demand instances, while simultaneously improving anti-blocking properties through higher IP churn.

2024-kon-spotproxy §4, §5 defense

SpotProxy exploits cloud Spot VMs — instances backed by excess capacity that can be reclaimed at any moment and re-spawned at new IP addresses — to create a high-churn proxy fleet. The observation is that Spot VM preemption, which is an operational liability for normal workloads, is a circumvention asset: it continuously refreshes proxy IP addresses, making censor enumeration and blocklisting structurally ineffective.

2024-kon-spotproxy §1, §3 defense

SpotProxy adapts both WireGuard and Snowflake to work with its active proxy migration mechanism, demonstrating that the approach is protocol-agnostic. The active migration mechanism allows clients to move between proxies seamlessly without performance degradation or connection disruption when a proxy is replaced — a requirement for any high-churn proxy infrastructure.

2024-kon-spotproxy §3, §5 defense

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

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

Reusing the same 64-bit client ID across rendezvous attempts caused approximately 3-minute delays in failure scenarios because the SQS queue deletion API can take up to 60 seconds to complete, forcing subsequent attempts to wait for the previous outgoing queue's deletion before a new queue with the same ID can be created. The fix generates a fresh random 64-bit client ID per attempt, eliminating the dependency on prior-attempt cleanup.

2024-pu-exploring §4.2 defense

A single shared bidirectional SQS queue was rejected for Snowflake rendezvous because SQS provides no mechanism to direct messages to a specific consumer — all polling clients would receive all other clients' messages, creating a privacy violation. The adopted design uses one shared incoming queue (broker-read-only) plus per-client temporary outgoing queues identified by randomly generated 64-bit IDs, with the broker periodically deleting queues idle for more than a configurable number of minutes.

2024-pu-exploring §3.1 defense

Amazon SQS routes client traffic through a single fixed HTTPS endpoint (https://sqs.us-east-1.amazonaws.com), making it infeasible for a censor to distinguish circumvention-bound SQS traffic from legitimate AWS service traffic; blocking this signaling channel would require blocking all Amazon SQS, imposing significant collateral damage on businesses and developers.

2024-pu-exploring §2.2 defense

AWS credentials distributed publicly to enable client access to the SQS API were flagged by GitHub's automated secret-scanning and AWS Support requested their deletion, even though the credentials carried intentionally limited permissions. The operational workaround adopted — base64-encoding credentials before public distribution — bypasses automated scanning but provides no real security.

2024-pu-exploring §4.2 deployment

The SQS rendezvous method was deployed in Snowflake v2.9.0 / Tor Browser 13.0.10 (February 2024) and as of 2024-06-22 had served over 14,808 client connections from over 20 countries including Iran, China, the United States, and Russia, while remaining within the AWS Free Tier limit of 1 million requests per month and incurring no monetary cost.

2024-pu-exploring §4 deployment

Separating the Broker role (a server that holds and manages bridge information) from both the rendezvous channel and the censorship evasion system enables modular protocol design: the rendezvous carrier can be swapped independently of the proxy system. The authors identify broker authentication and multi-broker load distribution as open problems not addressed in the current prototype.

2024-vilalonga-looking §3.1, §5 defense

Google Cloud Pub/Sub is blocked entirely in China, limiting the system's applicability in the highest-censorship environment. Azure Pub/Sub is a structurally weaker candidate for rendezvous channels because each created resource receives a unique per-resource domain, enabling censors to block it with minimal collateral damage compared to blocking a shared Google or AWS endpoint.

2024-vilalonga-looking §4.1 deployment

Using Google Pub/Sub as a rendezvous channel adds 7.17 seconds of bootstrapping overhead vs. a 1.32-second direct baseline when establishing a TorKameleon WebRTC bridge connection (total: 8.49s vs. 1.32s). The dominant bottleneck is subscription creation time (5.23s), not the message exchange itself (3.26s), averaged across 10 samples with 113 ms cross-Atlantic latency.

2024-vilalonga-looking §4.2, Table 1 evaluation

The paper surveys the rendezvous channel design space and identifies at least six prior carrier approaches: domain fronting via CDNs, AMP cache proxying, Amazon SQS queues, push notification services, email tunneling (Mailet, SWEET), and cryptocurrency covert channels (MoneyMorph). Pub/Sub adds bidirectional real-time messaging with broad IoT/enterprise adoption as a new carrier class not previously evaluated for circumvention rendezvous.

2024-vilalonga-looking §2.2 defense

The system uses a shared Pub/Sub topic for all users, where session IDs (SIDs) are visible to all subscribers on the broker topic. The paper argues this does not compromise user anonymity because SIDs are randomly generated per-session by client-side software with no link to user identity, and all subsequent bridge-info payloads are encrypted under a session-specific symmetric key exchanged via asymmetric encryption.

2024-vilalonga-looking §3.2 defense

The paper documents that bridge distribution across major circumvention tools (Tor Browser's Moat, Snowflake) relies entirely on domain fronting (meek) for automated, user-friendly bootstrapping. This concentration means a censor that defeats domain fronting — or that pressures CDN providers to stop offering it — removes essentially all automated bridge-discovery pathways simultaneously, leaving only manual out-of-band methods (email/Telegram accounts) that require many user interactions.

2024-vines-communication §2.1 evaluation

Raceboat formalizes a decomposition of application-protocol-tunneling channels into three reusable components (Transport, User Model, Encoding) and a channel manager that supports mixing unidirectional channels. By composing seven different channels from these modular components (including email, AWS S3, and Redis variants), the paper demonstrates that the current ad-hoc one-protocol-one-implementation model wastes significant re-implementation effort: the same transport or encoding logic is duplicated across Snowflake, meek, CloudTransport, and others.

2024-vines-communication §1–§5 defense

The paper argues that a greater diversity of signaling channels reduces the censor's leverage: when many independent services (cloud storage, email, push notifications, domain fronting) can each bootstrap a circumvention connection, a censor must block all of them to prevent access, and the collateral damage of blocking each may deter action. Skyhook specifically targets cloud storage as an additional independent pathway alongside existing channels like meek, Raven (email), and PushRSS.

2024-vines-ten §1 defense

Skyhook redesigns the 2014 CloudTransport concept as a signaling channel for bridge/proxy bootstrapping rather than a general-purpose browsing channel. By scoping to two-message exchanges (~1KB per direction, ~1 minute latency tolerance), Skyhook eliminates the requirement for censored users to create paid cloud storage accounts — the key usability barrier in the original design — and uses unilateral permissioning over AWS S3 objects so blocking Skyhook requires blocking all HTTPS traffic to an entire AWS S3 region.

2024-vines-ten §2, §4 defense

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

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

Residual censorship — where a censor detects an objectionable connection via one method and then blocks all traffic between the same 3-tuple (client IP + server IP + port) or 4-tuple (client IP + port + server IP + port) for a short duration — was documented in China, Iran, and Kazakhstan. This means a single detected circumvention attempt can trigger temporary IP-level blocking of the entire endpoint regardless of protocol.

2023-master-worldwide §4.3 detection

Following the invasion, Psiphon user counts and VPN usage in Russia increased many-fold and correlated with specific censorship events, while multiple access paths to Tor (direct connections, bridges, pluggable transports) were progressively blocked. Despite this surge, circumvention tools reached only a small fraction of all Russian Internet users, indicating that aggressive multi-vector blocking and lack of user awareness left most people unable to access censored resources.

2023-ramesh-network §6 evaluation

Relying on third-party email providers to verify users was demonstrated by Ling et al. to leave Tor's BridgeDB vulnerable to censors capable of creating multiple accounts, enabling bridge enumeration via sock-puppet attacks at scale. Active and passive detection techniques — including traffic flow analysis, DPI, website fingerprinting, and active probing — have been demonstrated in prior work to reveal Tor bridges, making Tor inaccessible for the majority of users in some regions.

2023-tulloch-lox §2.2.1 detection

The Lox check-blockage protocol response size and time grow linearly with the number of blocked bridges — 6 kB / 11 ms at 5% blocked, 63 kB / 64 ms at 50%, and 126 kB / 122.5 ms at 100% — creating a bandwidth bottleneck a strategic and patient censor can exploit by triggering mass bridge blockages during a critical event (election, coup) to deny successful blockage migrations at the moment users most need them.

2023-tulloch-lox Figure 1, §5.2 detection

In a Rust implementation evaluated over 10,000 runs with 3,600 bridges (1,800 open-entry single-bridge buckets and 600 hot-spare three-bridge buckets), Lox's trust promotion protocol incurs the highest latency at 364.2 ms response time and 378 kB response size due to the encrypted migration hashtable, but this operation occurs only once per user. All other protocols complete in under 16 ms with request sizes under 3.4 kB.

2023-tulloch-lox Table 4, §5.2 evaluation

Lox's trust level scheme (L=0 through L=4, requiring 30, 14, 28, 56, and 84 days respectively per level before upgrading, per Table 2) with blockage inheritance — invited users inherit their inviter's blockage count d — prevents a censor from resetting their reputation through self-invitation after causing blocking events, while users with d ≥ 4 become ineligible to migrate, capping the damage a persistent infiltrator can do.

2023-tulloch-lox §4.2.1, §2.4.2, Table 2 defense

Lox uses Chase et al.'s keyed-verification algebraic MAC anonymous credentials in a single-issuer/verifier setting with jointly-chosen credential IDs (neither party can unilaterally select them), so a fully compromised Lox Authority cannot link credential showings to specific users or reconstruct the social graph — the LA learns only that a shown credential was authentically issued.

2023-tulloch-lox §3.1, §4.2 defense

27 of 80 tested VPN providers had servers within a single AS (AS 9009, M247 Ltd), and VPNalyzer identified 14 providers sharing 4 specific IP blocks within that AS; 2 additional providers shared an IP block in AS 60068 (Datacamp). Such infrastructure concentration enables censors to block multiple VPN products simultaneously with a single IP-range or AS-level rule.

2022-ramesh-vpnalyzer §VI-D evaluation

34 of 41 obfuscated OpenVPN configurations and 18 of 20 UDP configurations were co-located with vanilla TCP OpenVPN servers within the same /29 subnet; probing the /29 subnet of a suspected obfuscated or UDP endpoint revealed nearby vanilla TCP servers, enabling confirmation by 'guilt by association' even when the obfuscated endpoint itself resisted direct fingerprinting. Some providers additionally share infrastructure across different VPN brands, further compounding exposure.

2022-xue-openvpn §7.5, §9.1 detection

Switching source IP via VPN, Tor, or HTTP proxy is the primary victim-side mitigation because residual censorship is tuple-keyed; however, if the proxy entry node's path also crosses the censor, the attacker can redirect the attack at the proxy itself. On the censor side, null-routing middleboxes could eliminate the vulnerability by validating TCP sequence/acknowledgment numbers before dropping traffic, or by replacing null routing with an explicit block-page response.

2021-bock-your §VII defense

A prototypical Python implementation of MoneyMorph completes all cryptographic operations in under 50 milliseconds on a commodity Intel Core i7 (2.2 GHz, 16 GB RAM): fresh key-pair generation takes approximately 120ms, shared key derivation approximately 41ms, and symmetric encryption/decryption under 1ms. The dominant latency in practice is blockchain confirmation time, not computation.

2020-minaei-moneymorph §6.1 evaluation

MoneyMorph provides provable chosen-covertext attack security (SBS-CCA) for proxy bootstrapping, unlike prior email or social-media rendezvous approaches which offer only heuristic security. Under SBS-CCA, the censor's advantage in distinguishing a covertext-bearing transaction from a random transaction in the same space is negligible.

2020-minaei-moneymorph §2.3, §4.2 defense

Zcash shielded transactions provide the highest per-transaction bandwidth of any tested cryptocurrency: 1148 bytes for the challenge covertext and 1168 bytes for the response, at a transaction fee of less than 0.01 USD. Bitcoin yields only 20/40 bytes at $0.34 fee and Ethereum only 20 bytes at $0.18 fee.

2020-minaei-moneymorph §5.5, Table 1 evaluation

Survey data indicates 31% of Chinese Internet users use VPN services compared to Tor's approximately 2 million daily users globally, and centralized non-anonymous systems like Lantern and Psiphon dominate adoption over anonymity-focused tools. The paper argues this demonstrates that the majority of censored users prioritize blocking resistance over anonymity, supporting a separation-of-properties design principle.

2020-nasr-massbrowser §III-B policy

MassBrowser proxies operate on NATed IP addresses shared with other users and services, meaning blocking them imposes collateral damage on unrelated parties. The proxy IP pool scales linearly with user count via client-to-client proxying, and IPs rotate as volunteers move between networks, making enumeration-and-block strategies progressively more costly for censors.

2020-nasr-massbrowser §III-E, §IV-A defense

MassBrowser estimates operational cost at $0.0001 per active client per month at large scale; the domain-fronted Operator alone costs ~$0.001 per active client per month because signaling traffic volume is small. Domain fronting used for bulk data proxying is characterized as prohibitively expensive and not viable at scale.

2020-nasr-massbrowser §III-E, §VI-C evaluation

Hong Kong is the sole geographic exception: it experiences no measurable slowdowns when accessing the foreign Internet, and Chinese mainland receivers accessing Hong Kong as a sender averaged only ~3 hours of slowdown per day — compared to 5–17 hours for US, European, and most Asian senders — making it an effective high-performance relay between mainland China and the rest of the world.

2020-zhu-characterizing §3, §4.2 Observation 1, Figure 7 evaluation

A proxy assignment algorithm derived from the Gale-Shapley college admissions game, using multi-feature utility functions across five client metrics (proxy utilization capped at T, new-proxy request rate, blocked-proxy usage, known-blocked count, client distance) achieves superior connected-client ratios and lower wait times compared to state-of-the-art rBridge in all tested ecosystem configurations (Static, Slow, Alive, Popular), without requiring knowledge of individual client types at assignment time.

2019-nasr-enemy §IV, §VII defense

A game-theoretic optimal censorship strategy — in which coordinated agents maximize a joint utility combining proxy discovery and blocking impact (equation 3, parameterized by ω) — is significantly stronger than both aggressive (immediate block) and conservative (timed-delay) heuristic strategies evaluated in prior work including rBridge; changing ω (surveillance vs. blocking preference) further modulates the damage a censor can inflict on any given distribution profile.

2019-nasr-enemy §VII-C evaluation

In a static proxy pool (λ=0, no new proxies added), the fraction of connected censored clients decreases monotonically to near zero regardless of censorship strategy, even at low censoring-agent fractions (ρ=0.05) and against a non-strategic aggressive censor with a strict-balanced distributor profile.

2019-nasr-enemy §VII-A evaluation

obfs4 successfully established Tor circuits on the authors' own unpublished bridge relays but failed to connect to any public obfs4 bridge, consistent with the GFW having scraped and blacklisted public bridge addresses. This demonstrates that address confidentiality is a prerequisite for obfs4's effectiveness, independent of its obfuscation properties.

2018-dunna-analyzing §5.1 evaluation

Configuring iptables to drop incoming Tor packets whose TCP MSS equals 1400 (the value observed on GFW scanners) prevented bridge IPs from being added to the blocklist across the entire 44-hour experiment. This technique requires changes only on the relay, unlike pluggable transports that require both client and server upgrades.

2018-dunna-analyzing §5.2 defense

Despite I2P's decentralized design, a censor can block more than 95% of peer IP addresses known to a stable I2P client by operating only 10 routers in the network. The censor learns this by passively monitoring the distributed netDb through injected floodfill and non-floodfill nodes, exploiting the fact that I2P's peer-discovery mechanism exposes the near-complete address space to any sufficiently resourced participant.

2018-hoang-empirical Abstract, §6 detection

A simpler but effective complement to IP-list blocking is to block access to I2P's small set of hardcoded reseed servers: first-time users cannot fetch RouterInfos of other peers and are entirely prevented from joining the network. Reseed servers are functionally equivalent to Tor directory authorities as a single point of failure for bootstrapping.

2018-hoang-empirical §2, §6.1 detection

Across all tested countries, circumvention and anonymization tools are the most consistently blocked category: www.hotspotshield.com is blocked in 5 of 13 detected censoring countries, and three Tor Project properties (bridges.torproject.org, www.torproject.org, ooni.torproject.org) each appear in the top-10 most broadly blocked domains. Collateral damage is also documented — Iran blocks psiphonhealthyliving.com as a substring match for the psiphon.ca circumvention domain.

2018-vandersloot-quack §6.2, Figure 12 evaluation

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

Bridges that carry clients are highly stable: their median lifetime is 116 days (~4 months) and 84% never change IP address, with 90% having at most one IP change. This means current censor policies that remove bridge IP blocks every 25 hours are far more conservative than necessary — an adversary could sustain blocks for months without significant collateral damage.

2017-matic-dissecting §V-B, Figure 3 evaluation

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

Default bridges — whose IP addresses are hardcoded in the Tor Browser Bundle — carry 91.4% of all bridge clients globally in April 2016, and 86.1% in Iran and 69.2% in Syria. Because these addresses are trivially obtainable from the Tor Browser Bundle configuration files, a censor can block the vast majority of bridge users in a country at any time.

2017-matic-dissecting §V-E, Table II evaluation

Four OR ports (443, 8443, 444, 9001) account for 82% of all active public bridge fingerprints as of April 2016, down from 95% in March 2013 but still concentrated. Scanning just three of these ports (443, 8443, 9001) is sufficient to deanonymize 71% of all active public bridges. Additionally, CollecTor's published per-bridge usage statistics allow a censor to rank bridges by client count per country and identify the highest-impact OR ports to scan next.

2017-matic-dissecting §V-D, Figure 6, Table IV detection

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

CloudFlare platform policy creates outsized blocking: 80% of CloudFlare-hosted websites discriminate against at least 60% of studied Tor exits, while Amazon- and Akamai-hosted sites show high policy diversity. Social networking and shopping sites are the most aggressive discriminators — 50% block over 60% of studied exits — while search engines are least aggressive, with 83% blocking fewer than 20% of exits.

2017-singh-characterizing §6.4 evaluation

7% of 84 commercial IP blacklists proactively blacklist Tor exit relay IPs as a matter of policy: the Snort IP and Paid Aggregator blacklists listed newly deployed relay IPs within 3 hours of their first appearance in the Tor consensus and maintained the listing for the entire relay lifetime. In total, 88% of all Tor exits appear on at least one commercial blacklist, compared to 9% of VPNGate and 69% of HMA VPN endpoints.

2017-singh-characterizing §5.2, §5.3, §5.6 detection

Salmon simulations show that a censor with agents comprising 1% of 10,000 users can block at most 4A servers (one block per agent per full group) against a system with 1,000–2,000 servers; server groups with a hard cap of M=10 users that fill entirely with legitimate users before any agent joins become permanently invincible to server discovery. The censor's optimal strategy is to ensure each agent is always alone in its group at the time of joining, which requires knowing the user arrival rate — information Salmon withholds by not publishing user statistics.

2016-douglas-salmon §5.1 / §5 evaluation

Without recommendation-tree grouping logic, a censor starting agents at trust level 6 who each recommend 1–2 additional agents (requiring 4–5 months of waiting) can cut off over 95% of users even at agent percentages in the 15–30% range, as shown in Figure 6. With recommendation-tree grouping enforced, the same attack at equivalent agent fractions produces dramatically lower service disruption because agents cluster among themselves rather than spreading across innocent user groups.

2016-douglas-salmon §5.3 / Figure 6 detection

Salmon's trust-level mechanism (7 discrete levels; promotion from level n to n+1 requires 2^(n+1) days; banning triggered when suspicion exceeds T=1/3) reduces the fraction of users cut off by an attacking censor by more than 3× relative to rBridge under the same agent-percentage conditions. Simulations with 10,000 users (1–10% censor agents) and 1,000–2,000 servers show that trust levels keep high-seniority innocent users isolated from newer users where agents concentrate.

2016-douglas-salmon §5.2 / §3.6 defense

A single harvesting script running for 9 days on one free Amazon EC2 instance verified 3,101 working VPN Gate servers by testing 44,039 IP addresses, demonstrating that VPN Gate's collective defense mechanism — which relies on detecting automated scanning patterns — can be fully bypassed by routing successive queries through previously verified VPN servers. This result implies that a censor could, with no collateral damage, essentially completely shut down VPN Gate by blocking all verified servers.

2016-douglas-salmon §4.1 evaluation

Salmon's defense against the active zig-zag attack — where a censor blocks a known server to force users onto new ones and watches for correlated reassignments — requires both per-user authentication (unique login credentials per server so unauthorized probes receive a plausible HTTPS page) and traffic camouflage. Without authentication, the server must respond as a functioning proxy to any connection, fully exposing itself to the censor; without camouflage, even a rejected connection may reveal the server's nature.

2016-douglas-salmon §3.10 defense

All bridges in a given Tor Browser release batch were blocked simultaneously within a 20-minute window, and every blocking event occurred during China Standard Time business hours (between 10:40 and 17:00 CST). The combination of unpredictable multi-day delay followed by abrupt simultaneous batch blocking suggests a semi-manual process: human analysts discover bridges after an irregular delay, then an automated system applies blocks.

2016-fifield-censors §4 Results, Table 3 evaluation

China's firewall never blocked a bridge before its public Tor Browser release, despite bridges being discoverable earlier via bug-tracker tickets and source code commits. The four bridges distributed only in Orbot (not Tor Browser) remained unblocked throughout the experiment, indicating the GFW monitors end-user software releases rather than upstream repositories or alternative distribution channels.

2016-fifield-censors §4 Results detection

The Great Firewall of China blocked newly published obfs4 Tor Browser default bridges after delays of 7, 2, 18, 11, and 36 days following the first public software release, and up to 57 days after bridges were first discoverable via bug-tracker ticket filing. Iran showed no blocking of the same default bridges across the entire five-month measurement period.

2016-fifield-censors §4 Results, Table 2 evaluation

Some obfs4 bridges exhibited a roughly 24-hour periodic semi-blocking pattern from China, where bridges cycled between reachable and blocked states with a ~24-hour period. This diurnal pattern differed between the two China probe sites and between bridges, and one blocking failure coincided with a documented nationwide GFW outage that also briefly restored access to Google services.

2016-fifield-censors §4 Results, Figure 3 evaluation

GFW blocking was keyed on both IP address and port number, not IP address alone. Bridges with port 22 (SSH) open had that port remain reachable even as other ports on the same IP were blocked, confirming per-(IP, port) tuple granularity in the GFW blocklist.

2016-fifield-censors §4 Results detection

Password-protected Castle game sessions (passwords distributed via a BridgeDB-like mechanism) prevent censors from joining instances to observe in-game state or identify participants; when a client fails to supply the correct password within a timeout, the Castle proxy falls back to an AI player, making Castle instances indistinguishable from legitimate games even to an adversary who enters the lobby.

2016-hahn-games §6.2 defense

Vanilla Castle achieves 42–190 bytes/second (average) and transfers a 10 KB file in 52–238 seconds depending on the game (0-A.D. / Aeons / Conquerors); game-specific exploitation of per-unit click logging in Aeons raised throughput to ~3 KB/s. These rates are sufficient for asynchronous text-based communication (tweets, email, news articles) and bootstrapping Tor bridge IP distribution.

2016-hahn-games §8, Table 2, §8.3 evaluation

The Great Firewall detects Tor bridges through a two-stage active-probing pipeline: GFW DPI first flags a flow as a potential Tor connection, then random Chinese IP addresses initiate Tor handshakes to the suspected bridge; if the handshake succeeds, the bridge IP:port combination is blocked.

2016-khattak-sok §2.4.1 detection

Mailet resists proxy enumeration because clients communicate exclusively through widely-used email hosting providers over standard POP3/SMTP/IMAP ports; no direct client-to-Mailet-server connection ever exists, so even if a censor learns a Mailet server's IP address, blocking it requires blocking all email to major providers — collateral damage that is politically infeasible.

2016-li-mailet §1, §2.1 defense

Winter and Lindskog [157] (2012) documented that the GFW used TLS SNI inspection in combination with IP/port filtering and TCP disruption to block Tor, as recorded in the survey's Table 1. This is one of the earliest published accounts of the GFW applying SNI-based blocking specifically to a circumvention protocol, demonstrating that the GFW correlated multiple detection signals rather than relying on any single technique.

2015-aceto-internet Table 1 detection

The GFW sends protocol-specific probe payloads tailored to each circumvention tool: Tor bridges receive a TLS ClientHello mimicking Tor's own; obfs2/obfs3 servers receive random-looking payloads; Shadowsocks servers receive random bytes. A server that responds differently to these crafted probes versus innocent traffic (e.g., by sending a valid protocol handshake in response to a probe) reveals itself and is subsequently blocked.

2015-ensafi-active-probing §5 detection

The GFW blocks Tor primarily by dropping SYN/ACK segments entering China from blacklisted IP/port pairs, not by dropping SYN segments leaving China. Of 142,802 CN→Tor-Relay measurements, 81.52% were Server-to-client-dropped versus only 0.55% Client-to-server-dropped. Blocking Tor directory authorities also showed substantial Client-to-server drops (19.61%), suggesting authorities may be treated differently.

2015-ensafi-analyzing §4.1, Table 1 detection

Routing traffic from a user on ISP-B through a peer relay on ISP-A (which applied only HTTP-level filtering and permitted HTTPS) produced the smallest page load times in most cross-ISP comparison runs, beating both HTTPS/domain-fronting and Tor. The performance gain is attributed to lower end-to-end latency on the intra-country cross-ISP path relative to international relay routes.

2015-nisar-case §3.2 / Figure 2c / Insight-3 evaluation

C-Saw's design demonstrates that coupling circumvention capability with censorship measurement creates a self-reinforcing incentive loop: users opt in for improved page load times, their participation grows the vantage-point pool, and richer measurements enable finer-grained technique selection per ISP and URL. The system avoids requiring a pre-populated URL list by building a blocked-URL database dynamically from user-initiated requests.

2015-nisar-case §1 / §3.3 / §4.2 defense

The dead-drop bootstrapping protocol is vulnerable to censor stuffing: because bridge dead drops are publicly advertised and world-writable, censors can flood them with fake tickets containing credentials for non-existing rendezvous accounts, potentially exhausting bridge polling resources. The paper mitigates this only partially via exponential backoff on inactive accounts, and acknowledges that if the censor's stuffing rate significantly exceeds the bridge's check-and-discard rate the attack may hinder bootstrapping. Censors may also delete genuine tickets, though cloud providers such as Dropbox preserve all file versions for 30 days, allowing bridges to collect the first version of every file.

2014-brubaker-cloudtransport §4.2 evaluation

CloudTransport's passive-rendezvous design ensures clients never establish direct connections to bridges; consequently, even a censor in complete control of a bridge cannot enumerate client IP addresses without computationally intensive flow-correlation analysis. Blacklisting the IP address of a CloudTransport bridge has zero effect on CloudTransport connections, and when a bridge migrates to a new IP address this change is completely transparent to clients.

2014-brubaker-cloudtransport §4.3 defense

Port 9001 (Tor) ranked third among all blocked ports in Syria, behind only ports 80 and 443. Proxy SG-48 was responsible for a disproportionate share of Tor censorship — blocking Tor traffic for multiple consecutive days — while other proxies in the same deployment did not, indicating per-proxy policy specialization or traffic steering of suspected circumvention flows to dedicated blocking infrastructure.

2014-chaabane-censorship §4 (Ports), §5.2 detection

Approximately 10% of China's IP addresses respond to IPID probes, and 13% of those exhibit globally incrementing IPIDs, meaning roughly 1% of China's total IP address space can serve as passive measurement vantage points with no cooperation from host owners. In contrast, Tor bridge blocking from Chinese clients was observed in 58.91% of server-to-client cases versus 0% for non-China Asia-Pacific clients.

2014-ensafi-detecting §5, Table 1 evaluation

Over 5 days of measurement, 73.04% of connections from Chinese clients to Tor directory servers were blocked server-to-client (stateless SYN/ACK dropping), 16.73% were blocked client-to-server (null routing), and only 0.63% were unblocked. Of all censored Tor directory server connections measured across all regions, 98% originated from Chinese clients.

2014-ensafi-detecting §5, Table 1 evaluation

Collaborative spy detection aggregates VPN connection logs (complete, incomplete, and tiny calls) across all volunteer nodes to a central log analyzer, which identifies censor probe IPs by looking for clusters of incomplete or tiny calls from the same /24 block, then distributes a Spy List back to every server so probing packets are silently dropped before the handshake completes. A single server cannot distinguish a spy from a regular client in time; the cross-server aggregate makes pre-response spy identification feasible.

2014-nobori-vpn §4.3 defense

After deploying innocent IP mixing and collaborative spy detection, VPN Gate raised server reachability from China from a low of ~30% to 78.5% by June 19, 2013, sustaining 60–70% reachability through end of August. On August 29, 2013, VPN Gate served 9,000 daily unique IP addresses from China versus Tor's estimated 3,000.

2014-nobori-vpn §6.2, Figure 12 evaluation

In a 140-hour measurement, requests forwarded into a 10-node Darknet connected to the Opennet by a single bridge link succeeded only 0.08% of the time, versus 8.46% for Opennet-forwarded requests — a ~100× failure-rate gap caused by ID-space isolation between the two overlay segments.

2014-roos-measuring §4.3 evaluation

GNS uses a proof-of-work-gated network flood for key revocation, requiring an adversary to block flood traffic on every path between the revocation origin and all peers to suppress it. This is substantially more robust than X.509 certificate revocation lists, which an adversary can render ineffective by simply blocking access to CRL servers — a weakness severe enough that browser vendors must bundle revocation lists inside software updates.

2014-wachs-censorship-resistant §A.5 defense

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

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.

2013-durumeric-zmap §4.6 detection

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

Default Tor connections to a private bridge inside China were detected by the Great Firewall via active probing: an initial connection succeeded, followed by a probe from a Chinese IP address approximately 15 minutes later that performed a TLS handshake and then blacklisted the (IP, port) combination. Subsequent connection attempts resulted in a successful SYN followed by spoofed TCP RSTs terminating both the client and bridge connections.

2013-dyer-protocol §6 detection

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

Online scanning services span security scanners, ad networks (Google AdSense), web diagnostics, and link shorteners—categories economically important enough that blocking them wholesale causes severe collateral damage. The paper identifies five broad OSS categories with dozens of providers, and notes that translation services, photo printers, RSS aggregators, and image hosts are additional unexplored candidates, making exhaustive enumeration by a censor infeasible.

2013-fifield-oss §2, §3, §9 defense

SkypeMorph and FreeWave both overlay a client-proxy communication model onto a peer-to-peer VoIP network; because Skype clients attempt direct peer contact before falling back to supernodes, initiating a call to a FreeWave proxy reveals its IP address directly to the caller, and proxy nodes accumulate user-to-bridge ratios that reached 8–12× in Syria/Iran and up to 120:1 in China (Figure 8), producing concentration signatures uncharacteristic of normal P2P call distributions. These architectural mismatches allow enumeration and fingerprinting attacks independent of traffic-content analysis.

2013-geddes-cover §5, Figure 8 detection

FreeWave routes client VoIP connections through oblivious intermediary nodes (e.g., Skype supernodes) rather than directly to the FreeWave server, so even if a censor discovers the server's VoIP ID or IP address it cannot block clients via IP filtering. This 'server obfuscation' is absent from SkypeMorph and StegoTorus; the authors note that Chinese censors enumerated all Tor bridges—on which SkypeMorph depends—in under a month, rendering those transports instantly blockable.

2013-houmansadr-i §IX-A defense

Existing censorship-resistant systems share a fundamental vulnerability: they require the user to know a finite set of entry points (bridge addresses, rendezvous points, or ISP-level collaborators) that a censor can enumerate by impersonating a legitimate user. China has blocked the majority of Tor bridges since 2010 and Iran blocked all encrypted traffic in 2012, demonstrating this attack is operationally deployed at scale.

2013-invernizzi-message §1 detection

In simulated event-driven (crisis) blocking where all corrupt users simultaneously block bridges on day 300, available bridges drop from ~500 to ~150 and thirsty users spike to 25%; maintaining 50 reserve bridges (~10% of deployed stock) halves the thirsty-user count, and 100 reserve bridges nearly eliminates thirstiness among users who had accumulated sufficient credits.

2013-wang-rbridge §4.3.2 evaluation

Knowing a user's bridge assignment narrows the adversary's anonymity set to the small group sharing that bridge, deanonymizing Tor users even when the bridge itself is not compromised; rBridge addresses this using 1-out-of-m Oblivious Transfer, Pedersen commitments, and non-interactive zero-knowledge proofs so the bridge distributor learns nothing about which bridges a user holds.

2013-wang-rbridge §5, §5.1 defense

China's GFW was able to enumerate all Tor bridges distributed via IP address or Gmail account in under a month, demonstrating that standard small-subset distribution strategies are insufficient against a state-level adversary controlling large numbers of accounts and Sybils.

2013-wang-rbridge §2.1 detection

rBridge tolerates up to ~30% malicious users with acceptable bridge protection, but fails at f≥50%; with f=5% under aggressive blocking, over 95% of users are never bridge-starved and ~50% of bridges are never blocked, while conservative blocking (corrupt users waiting 225 days before acting) causes ~10% of users to be thirsty 15% of the time because delayed blockers accumulate enough credits to inject additional malicious invitees.

2013-wang-rbridge §4.3.2 evaluation

rBridge outperforms Proximax by at least one order of magnitude across all robustness metrics under aggressive blocking with 5% malicious users: to support 200 users for 30 days, Proximax requires at least 2400 bridges while rBridge needs only 108, and in Proximax fewer than 5% of bridges produce more than 20 user-hours versus 99% in rBridge.

2013-wang-rbridge §4.3.3 evaluation

Client proof-of-work puzzles are ineffective as an active-probing defense because a state-level censor with parallel hardware can solve multiple puzzles simultaneously, one per CPU core. The authors estimate that the Tor bridge churn rate (rate of new bridge IP addresses) is too low to raise a well-equipped censor's workload beyond practical limits without simultaneously making the scheme impractical for legitimate clients — the same balancing problem as PoW for spam.

2013-winter-scramblesuit §4.1.1 evaluation

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

DEFIANCE's Address-Change Signaling (ACS) requires each client to contact a sequence of IP addresses with precise timing (per-user wait and window parameters) and a one-time passphrase derived from NET provisioning. Connections arriving out of order, outside the timing window, or lacking the correct passphrase receive only innocuous content, so a censor probing a suspected address block finds only normal commodity servers.

2012-lincoln-bootstrapping §4 defense

A balls-and-bins analysis shows that an adversary conducting N full rounds of a rate-limited rendezvous protocol discovers only 63% of a pool of N entry points; full coverage requires N ln N rounds (the coupon collector's bound). Concretely, with three 8-hour shifts of 100 humans performing 60-minute CAPTCHA+proof-of-work challenges, an adversary discovers ~2,400 entry points per day, exhausting a static pool of 10,000 addresses in roughly 19 days.

2012-lincoln-bootstrapping §3 evaluation

The mod_freedom Apache module hooks into the HTTP 404 ErrorDocument handler and steganographically embeds encrypted NET payloads in image responses to valid RP requests, while returning normal content to all other clients. Using Identity-Based Encryption (IBE, Boneh-Franklin) keyed on the server's hostname eliminates any need for out-of-band public-key distribution and allows deployment on thousands of volunteer webservers without mutual trust.

2012-lincoln-bootstrapping §3.1 defense

With 512 PlanetLab nodes each advertising 50 KB/s as malicious Tor middle routers, the theoretical catch probability that at least one bridge circuit traverses a controlled node reaches P(512, 50, 30) ≈ 99% after only 30 circuits. In real-world validation, the 21st circuit created by a bridge client traversed one of the 512 controlled PlanetLab nodes, matching theory. The result generalizes: the 30-circuit exposure threshold applies to any adversary whose nodes' aggregated bandwidth reaches the equivalent of 512 × 50 KB/s = ~25.6 MB/s.

2012-ling-extensive §IV-B, §V-B, Fig. 7, Theorem 4 detection

Tor's bandwidth-weighted path selection creates a structural amplification: 60% of middle routers selected across 430 circuits had bandwidth above 1 MB/s, yet only 10% of all Tor routers exceed 1 MB/s. This skew means that an adversary advertising a single high-bandwidth middle node achieves selection probability far exceeding its proportional count in the network, making high-bandwidth Sybil nodes highly cost-effective for bridge discovery.

2012-ling-extensive §V-B, Fig. 8, Fig. 9 detection

The paper identifies three countermeasure classes against bridge discovery: (i) CAPTCHA on email/HTTPS distribution (limited by automated solving services); (ii) uniform random middle-node selection, which defeats bandwidth-Sybil attacks but degrades Tor throughput by routing through low-bandwidth nodes; (iii) DHT-based P2P architecture where no central server holds all bridge IPs, making systematic enumeration infeasible—though DHT systems introduce Sybil and eclipse-attack vulnerabilities of their own.

2012-ling-extensive §VI defense

Large-scale email and HTTPS enumeration of Tor bridges using 500+ PlanetLab nodes and 2,000 Yahoo accounts discovered 2,365 distinct bridges over approximately one month. The bridge https server rate-limits distribution to 3 bridges per 24-bit IP prefix per day, and the email server to 1 reply per account per day; these controls are circumvented by sourcing requests from hundreds of distinct prefixes. Bridge distribution follows a weighted coupon collector model proportional to bridge bandwidth, not uniform probability.

2012-ling-extensive §III-B, §III-C, §IV-A, §V-A detection

A single malicious Tor middle router advertising 10 MB/s bandwidth discovered 2,369 distinct bridges in 14 days. The catch probability is determined solely by the aggregated bandwidth M = k·b of malicious middle routers regardless of how that bandwidth is distributed across nodes: three routers at 10 MB/s each achieve strictly greater catch probability than 512 nodes at 50 KB/s each. This means a well-resourced single node is equivalent to or surpasses hundreds of low-bandwidth Sybil nodes.

2012-ling-extensive §IV-B, §V-B, Theorem 3 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

A blocked Tor bridge becomes reachable again after approximately 12 hours if Chinese scanners are unable to reach it continuously. In the authors' experiment, one bridge (port 23941) whitelisted to their Chinese VPS via iptables was unblocked within 12 hours despite remaining actively used, while an unrestricted bridge (port 27418) stayed blocked indefinitely.

2012-winter-great §4.2 detection

Of 2819 public Tor relays in the February 2012 consensus, only 47 (1.6%) were reachable via TCP from within China. After three days, only 1 of those 47 remained reachable. The GFC blocks relays by IP:port tuple rather than by IP to minimize collateral damage to co-hosted services.

2012-winter-great §4.1, §4.3 detection

Over 3295 active-probing scans observed across 17 days, 51% (1680) originated from a single IP address (202.108.181.70), while 98% of the remaining 1615 addresses were unique. All scanner IPs belong to three Chinese ASes: AS4837 (65.7%), AS4134 (30.5%), and AS17622 (3.8%). TTL analysis of 85 connections shows the scanner IPs are likely spoofed by the GFC—post-scan ping TTLs differed by +1 from during-scan TTLs.

2012-winter-great §4.5 detection

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.

2012-winter-great §2, §4.1 detection

COR does not solve the bootstrapping problem: a user's first connections to the COR bootstrapping network are vulnerable to the same IP-enumeration and blocking attacks as public Tor directory connections. To mitigate directory-partitioning attacks, directory retrieval is always performed through an existing COR circuit, and directories return only a random subset of available nodes rather than the full list—but this subset-delivery design is itself exploitable by a malicious directory that can fingerprint users via uniquely-assigned relay subsets.

2011-jones-hiding §2.3, §3.1, §5 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

Routing all traffic through rendezvous mailboxes with a put/get interface prevents direct DoS against end hosts and hides service host addresses; each service deploys many mailboxes with a randomly chosen sequence per connection, so an attacker can disrupt at most a fraction of any given flow even with substantial resources.

2011-liu-tor §5, §7.1 defense

Channel blocking risk in Proximax is modeled as an independent Poisson process with rate λj; when a proxy is advertised on multiple channels simultaneously the risk parameters add (Λi = γ + Σλj), so each additional dissemination channel shortens expected proxy lifetime 1/Λi. The analytic result is that redundant multi-channel broadcasting is strictly suboptimal once cumulative risk exceeds the marginal usage gain.

2011-mccoy-proximax §3.1 defense

A sophisticated censor can infiltrate a proxy distribution system, accumulate large numbers of proxy addresses and channel identities, and delay mass-blocking for weeks or months to maximize information before acting. The paper argues this is self-limiting: delayed blocking extends proxy lifetimes (benefiting system yield), and the infiltrating account's subtree reputation score degrades sharply the moment it begins blocking proxies, triggering exclusion from future proxy assignments.

2011-mccoy-proximax §4 detection

Proximax uses fast-flux DNS — multiple IP addresses registered to one personalized domain with short TTLs and round-robin rotation — to resist channel-level DNS blocking. When a channel's domain is blocked, the system issues a fresh individualized hostname, forcing the censor to repeat discovery rather than permanently suppressing the channel with a single DNS entry removal.

2011-mccoy-proximax §2.2 defense

Open proxy distribution registrations are vulnerable to adversary flooding with fictitious accounts that inflate yield scores via dummy connections. Proximax uses invitation-only registration with RICO-style subtree reputation scoring — a compromised sub-node taints the entire inviting user's subtree — and sub-linearly credits usage from closely clustered source IP prefixes to limit bot-driven inflation.

2011-mccoy-proximax §2.2, §4 defense

Proximax frames proxy distribution as a yield-maximization problem: the expected yield of a proxy is its attracted usage Ui divided by its total blocking risk Λi. A dissemination channel should only be assigned a proxy if the channel's own yield ratio u/λ exceeds the proxy's current yield ratio; otherwise the added risk outweighs the additional traffic and the channel must not be used at all.

2011-mccoy-proximax §3.3 defense

Russia's high AS complexity (score 19.39, 2,346 ASes) enabled the Russian Business Network to hide malware-hosting ASes by chaining traffic through multiple intermediate legitimate-seeming ASes, making connections very difficult to trace and sever. The paper concludes that higher national AS complexity directly raises the operational cost of enumerating and cutting any given connection.

2011-roberts-mapping §IV, §VI defense

When RIAA filed suit against more than 30,000 individual filesharers, users migrated toward anonymous channels, small-world networks of vetted peers, ephemeral pointers, and user-generated IP blacklists for spoofed-peer detection. The University of Washington demonstrated IP-to-person attribution is unreliable — a networked laser printer received a DMCA takedown notice.

2011-seltzer-infrastructures §1.3 defense

Some politically active bloggers in the studied country deliberately continued publishing on officially court-blocked platforms, reasoning that official blockage created a legal defense against persecution: 'if they say you wrote this on your blog, I will say all of these blogs are blocked according to this court decision—they don't exist and they are officially inaccessible to citizens.' This co-option of censor infrastructure as a shield was treated as a serious protective strategy.

2011-shklovski-online §Blocked sites as a form of protection defense

Tor bridges that always accept incoming connections enable a three-phase 'bridge aliveness attack': an adversary collects bridge descriptors at scale, correlates bridge uptime timestamps with pseudonymous post timestamps to narrow the candidate set (winnowing), then confirms identity via circuit-clogging and timing attacks. Because bridge descriptors remain valid indefinitely and the BridgeDB rate-limits only to one descriptor set per /24 prefix per week, an adversary with botnet or open-proxy access can hoard enough bridges for the winnowing phase to succeed.

2011-smits-bridgespa §1, §1.1 detection

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.

2011-smits-bridgespa §4, §6.2.1 defense

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

Measured over 5,000 SYN/SYN-ACK pairs on a shared physical network hub—the best-case vantage for an adversary—BridgeSPA's DoorKeeper adds a mean latency of approximately 90 µs (280±20 µs baseline vs. 370±80 µs with BridgeSPA). This overhead is consistent with prior SilentKnock analysis concluding that an adversary would need hundreds of observed connections before gaining statistical advantage in distinguishing SPA-protected hosts from dynamic-firewall behavior.

2011-smits-bridgespa §6.2, Table 3 evaluation

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.

2011-smits-bridgespa §6.2.2, §7.5 detection

Dust eliminates the in-band key-exchange fingerprint surface via an out-of-band half-handshake: the server's public key, IP, port, and a single-use secret are bundled into a PBKDF-encrypted invite packet transmitted out-of-band; only the decryption password (not the server IP) appears in plaintext, defeating the email/IM IP-address blocking attacks documented against prior systems.

2011-wiley-dust §3, §3.1 defense

At the time of writing, the Tor network had no publicly announced exit nodes located on the Chinese mainland, making direct Tor-based measurement of GFW filtering unavailable. The paper generalizes this: heavily filtered countries show systematically low availability of relay services, precisely where measurement need is highest.

2011-wright-fine-grained §4.2 evaluation

A dynamic binary-tree partitioning algorithm solves the proxy distribution problem with at most k(1 + ⌈log₂(n/k)⌉) total proxy keys: partition n users into k groups in round 1, then halve each compromised group on each compromise event. Each of k adversaries can trigger at most ⌈log₂(n/k)⌉ compromises, bounding total proxy expenditure tightly.

2010-mahdian-fighting §4 Theorem 3 defense

A simple entropy argument proves the dynamic key distribution problem requires at least Ω(k log(n/k) / log(k + log n)) keys: the algorithm must identify which k of n users are adversaries from at most ℓ log ℓ bits of feedback (ℓ round outcomes each indexing one of ℓ keys), and distinguishing among C(n,k) adversary sets requires log C(n,k) = Ω(k log(n/k)) bits.

2010-mahdian-fighting §4 Theorem 6 evaluation

The static proxy distribution problem — giving k²-adversarial users keys from m proxies so that all n−k legitimate users retain at least one uncompromised proxy — requires at most O(k² log n) keys and cannot be solved with fewer than Ω(k log(n/k)) keys. This establishes the information-theoretic cost of one-shot proxy distribution against k colluding informants among n users.

2010-mahdian-fighting §3 Theorem 2 defense

By reusing keys already held by trusted (non-suspicious) users for ℓ−1 of ℓ subgroups when bisecting the suspicious cohort — issuing only one fresh key per round — the total proxy count drops from O(k log n) to O(k² log n / log log n) in expectation. The information-theoretic lower bound is Ω(k log(n/k) / log(k + log n)), so this bound is tight in n up to a factor of k.

2010-mahdian-fighting §4 Theorems 4–6 defense

In invitation-based proxy networks (modeled on Psiphon's trust-tree), a single adversary can invite fake accounts as children in the trust tree, multiplying the effective adversary count k and invalidating sublogarithmic key budgets. For k=1 adversary on a trust tree of depth O(log n), an O(log n)-key algorithm exists by keeping the 'suspicious group' always rooted at a subtree boundary; for k>1 this remains an open problem.

2010-mahdian-fighting §5 Theorem 7 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

SkyF2F's friend-to-friend service model, where a server publishes its appid only to trusted contacts rather than publicly, provides significant resistance to both sybil attacks (malicious censor-controlled servers) and DoS exhaustion attacks. A censor posing as a client can establish many tunnels to exhaust a public server's resources; restricting service to a trusted friend list eliminates most of this attack surface.

2009-cao-skyf2f §V.A defense

Using Tor exit nodes to query the bridge authority, the authors enumerated 247 bridge descriptors over two weeks (out of 1,716 active bridges during that period). An adversary running a relay advertising just 10 MBps of bandwidth would discover 63% of bridges that relay at least 40 circuits and 87% of bridges running at least 80 circuits, because all Tor clients proactively build circuits every 10 minutes.

2009-mclachlan-risks §3.2 detection

A circuit-clogging attack against bridge operators—using median-normalized latency correlations—achieved an AUC of 0.884 and an equal error rate of 0.2 when distinguishing the victim bridge from innocent bridges in PlanetLab experiments with 180 victim and 180 disjoint runs. With 10 repeated clogging experiments and a majority-vote threshold, the false positive (and false negative) rate drops below 0.033, confirming a bridge operator's identity with high confidence given a candidate set of ≤4.4 bridges from the winnowing stage.

2009-mclachlan-risks §3.4 detection

The architectural coupling of 'surfing' and 'serving' in Tor's bridge design—where enabling the bridge service is required to use Tor as a client—means a bridge always accepts connections whenever its operator is online, allowing a remote non-global adversary to probe a bridge's availability at negligible cost (less than 2 bps per bridge per status check via SYN/RST). Of the 247 enumerated bridges, only an average of 29.6 (just over 10%) were accessible at any given moment, providing a highly discriminating availability signal for intersection attacks.

2009-mclachlan-risks §2.2, §4.2 evaluation

An 'unfair queuing' mechanism that partitions CPU time between bridge-operator circuits and bridge-client circuits using a time-allocation parameter τ=0.9 reduced the circuit-clogging AUC from 0.884 to 0.520 (median-normalized) and 0.412 (mean-normalized)—indistinguishable from random guessing—in 20 PlanetLab experiments. The mechanism eliminates latency interference between the two circuit types without requiring the bridge to ever refuse connections, but introduces up to 1−τ performance loss for client traffic.

2009-mclachlan-risks §4.3 defense

Cross-referencing the online/offline status of 87 monitored bridges against 186,935 Wikipedia users' edit sessions showed that 95.7% of users with 50 or more sessions matched zero bridges after winnowing. For users with 180 or more sessions (a surrogate for long-term pseudonymous activity), only 89 false positives remained among 2,329 users—a false positive rate of 0.000439—meaning that even if 10,000 Tor clients volunteer to bridge, on average only 4.4 bridges remain after the winnowing stage.

2009-mclachlan-risks §3.3 detection

Centralized proxy-discovery services are reliably disabled by censors: both Anonymizer and SafeWeb were blocked in China by targeting their central discovery sites, and Wikipedia identified and blocked all 700+ Tor anonymizing relay servers to prevent anonymous edits. Any single publicly-known host that handles proxy distribution becomes the censor's primary and sufficient target.

2008-sovran-pass §2 detection

Kaleidoscope uses at most one intermediate relay hop so proxies can serve users beyond their immediate trust neighborhood without directly learning user addresses. If a system allowed each proxy to directly advertise to N users, a censor posing as a proxy would learn N user identities; the one-hop relay design caps per-proxy exposure to r=5 relay addresses and keeps end-user identities hidden from proxies.

2008-sovran-pass §3 defense

On a crawled Orkut subgraph of 42,474 users (≈90% Brazilian nodes treated as the censored domain, 15% of external nodes as proxies = 1.5% overall), the median node reaches 7 proxies — higher than the synthetic graph due to greater average degree (5.59 vs. 4.65) and lower clustering. Even when subverted trust links reach half the total proxy count, more than 94% of users can still access at least one proxy unknown to the censor.

2008-sovran-pass §3.2 evaluation

Kaleidoscope bounds censor knowledge by routing proxy advertisements over symmetric random routes of length r=5 on a social trust graph: if the censor controls f subverted trust links, they can learn of at most r×f = 5f users or proxies regardless of how many Sybil identities they generate. Symmetric routing ensures the set a node learns of and the set that learns of a node are identical, closing the asymmetric information-leakage channel.

2008-sovran-pass §3, §3.2 defense

Simulation on a synthetic social graph of one million nodes (average degree 4.65, maximum 13) shows that when 1.5% of nodes act as proxies and random routes of length r=5 are used, the median node can reach 3 proxies and more than 90% of nodes can access at least one proxy.

2008-sovran-pass §3.2 evaluation

Tor's public relay list (a few thousand IP addresses as of 2006) can be trivially enumerated and blocked by a censor. The paper proposes 'bridge relays' drawn from Tor's existing user base of hundreds of thousands of people, creating a pool of frequently-changing IP addresses that is too large and dynamic for a censor to enumerate completely. Bridge relays rate-limit relayed connections to ~10 KB/s and publish descriptors only to a private bridge directory authority rather than the public consensus.

2006-dingledine-design §5.1 defense

The paper proposes dividing public bridge addresses into 8 pools (n=3 bits from HMAC(identity-key, authority-secret)) each assigned a distinct distribution strategy: time-windowed release, IP-subnet-partitioned assignment, time+location combined, mailing-list rotation, email/CAPTCHA delivery, and social-trust delegation. Deploying all strategies concurrently forces the attacker to allocate resources across every channel simultaneously, making all strategies more robust than any single strategy deployed alone.

2006-dingledine-design §7.4, §7.8 defense

If bridges run on predictable ports and any TCP connection to a bridge port reveals it as a Tor bridge, a censor can scan the entire address space of residential ISP ranges to enumerate and block all bridges. The paper proposes 'scanning resistance': bridges require a nonced hash of a pre-shared password before revealing Tor behavior, and respond to unauthenticated connections by impersonating an ordinary HTTPS server (e.g., default Apache page or a random legitimate website).

2006-dingledine-design §9.3 defense

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.

2006-dingledine-design §6 detection

Tor encrypts payload but does not obscure traffic volume, leaving a residual publisher-vs-reader asymmetry: a user publishing a home video generates a markedly different upload/download ratio than one reading news. The paper also notes that website fingerprinting attacks — where the adversary pre-downloads hundreds of popular sites and matches traffic patterns to a Tor client's stream — remain possible even through bridge circuits, and are exacerbated by Tor's varying supported protocols (web vs. IM produce different timing signatures).

2006-dingledine-design §8.2 detection

The paper proposes using CAPTCHAs (hard AI problems) to gate forwarder-list access, forcing the blocker to expend human resources solving every puzzle while each blockee solves only one. However, a 'stealing cycles from humans' attack allows a censor to relay CAPTCHAs to unwitting third parties (e.g., visitors to an attacker-operated website) who solve them on the censor's behalf.

2004-k-psell-achieve §5.3 defense

NAT and firewalls make volunteer forwarders (JAPR) unreachable for inbound connections by default, removing the incentive for volunteers to reconfigure their systems for no personal benefit. The design response is to reverse the connection direction — JAPR initiates contact with JAPB — shifting the NAT/firewall configuration burden to the motivated blockee who gains direct benefit from solving it.

2004-k-psell-achieve §6.4 deployment

The Eternity Service's core design stores a file on 100 servers worldwide but retains records of only 10 for auditing, destroying the remaining 90 records. Even if a user is legally compelled to disclose all 10 known server locations and those copies are seized, 90 copies survive at unknown locations and can be retrieved via anonymous broadcast once the user leaves the jurisdiction.

1996-anderson-eternity §4.3 defense