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.

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.

§5.1 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).

§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.

§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).

§8.2 detection

The June 2025 Iran shutdown—carried out during the Iran-Israel war beginning ~June 19—did not use BGP route withdrawals as in 2019. Instead, authorities applied service-level restrictions at the national border: DNS poisoning of foreign destinations, protocol whitelisting permitting only pre-approved domestic services, and DPI to block circumvention-tool traffic. Iran's international traffic fell roughly 90% while the country's BGP routes remained advertised, making the shutdown invisible to BGP-based monitoring systems. OONI measurement volume, which totalled 121,333 in June 2025, collapsed to under 200 submissions on June 19-20.

2025-iran-shutdown-measurement Executive Summary / §2 dpidns-poisoningport-blockingip-blocking

Article 19 documents that Iran's National Information Network (NIN / SHOMA) was designed with explicit reference to China's Great Firewall as a model, with institutional mirroring: Iran's Supreme Council of Cyberspace parallels China's Cyberspace Administration of China, and both governments share a "cyber sovereignty" doctrine used to justify domestic content controls and cross-border technology transfer. The report frames Iran's filtering infrastructure as deliberately architected to replicate GFW capabilities, not as an independently developed system.

2026-article19-tightening-the-net §2, §3 dpisni-blockingdns-poisoningip-blockingbgp-hijackthrottling

Article 19 documents that Iran combines technical filtering with formal coercion of major foreign platforms (including Telegram, Instagram, and WhatsApp) to comply with content removal orders under threat of full blocking. The report notes that Iran's 2022 Women Life Freedom protests accelerated platform blocking when foreign operators refused compliance, demonstrating that the censorship system operates in two modes: coerce-and-allow for compliant platforms, block for non-compliant ones. Domain fronting via these platforms is therefore subject to sudden revocation if political conditions change.

2026-article19-tightening-the-net §6 ip-blockingdns-poisoningthrottling

Brussee measures a systematic pattern of Chinese government websites actively blocking access from outside China (the "reverse Great Firewall"), publishing a CSV dataset of affected domains (available at zenodo.org/records/18172145). The paper frames this outbound geo-blocking as a cybersecurity-motivated practice — Chinese authorities classify foreign access to domestic government infrastructure as an attack surface — distinct from the inbound information control goal of the GFW.

2026-brussee-reverse-great-firewall §3, §5 ip-blockingasn-blackholing

Brussee develops a conceptual framework distinguishing two logics of government geo-blocking: (1) information control (blocking inbound foreign content from domestic users) and (2) data sovereignty / attack-surface reduction (blocking outbound access by foreign actors to domestic systems). Chinese government site blocking of external IPs is motivated primarily by the second logic, creating an asymmetric internet topology where CN citizens cannot reach the outside world, and outside actors cannot probe CN government infrastructure.

2026-brussee-reverse-great-firewall §2, §4 ip-blockingasn-blackholing

ShieldShare demonstrates that an Android application can route all hotspot-client traffic through a VPN tunnel without root access by using a SOCKS5/HTTP/HTTPS proxy layer between the hotspot and the VPN, with per-client traffic accounting and quota management. The system works because Android's native hotspot does not forward VPN routing tables to connected clients; ShieldShare interposes a proxy that handles this. Released as open-source.

2026-edorh-shieldshare §Abstract ip-blocking