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.

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.

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

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

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

§6.2.2, §7.5 detection

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 ip-blockingactive-probingflow-correlation

Tor-like anonymizing overlays are easily censored because they rely on centralized, publicly visible relay lists; governments can blacklist Tor nodes or monitor all Tor exit traffic so that traffic analysis can reveal the source. Traffic to or from Tor 'essentially advertises itself as probably worth tracking.'

2011-liu-tor §1–§2 ip-blockingflow-correlationactive-probing

InterSecLab's 76-page analysis of the Geedge/MESA leak (based on nine months of indexing and translating >100,000 documents) characterizes the Tiangou Secure Gateway (TSG) product line as a commercially deployable detection stack that combines deep packet inspection, real-time mobile subscriber monitoring, active probing, ML-based traffic classifiers, and granular per-region rule sets. TSG is not a research prototype — leaked documentation includes deployment timelines and client government interactions for Kazakhstan, Ethiopia, Pakistan, Myanmar, and one unnamed country, with censorship rules explicitly tailored to each region.

2025-interseclab-internet-coup §3–§5 (InterSecLab report) dpiactive-probingml-classifiersni-blockingip-blockingtraffic-shapefully-encrypted-detect

Justice for Myanmar documents that Geedge Networks supplied Myanmar's military junta with GFW-derived surveillance and censorship infrastructure under Belt and Road frameworks following the February 2021 coup. The deployed system (Tiangou Secure Gateway / TSG) incorporates the same DPI, active-probing, and ML-classifier capabilities as the domestic Chinese GFW, giving Myanmar one of the most technically capable censorship systems in Southeast Asia.

2025-jfm-silk-road-surveillance §3, §5 dpisni-blockingip-blockingtraffic-shapeml-classifieractive-probing

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 ip-blockingactive-probing

TURN servers used by major applications such as Facebook Messenger for media relay are hypothesized to be less likely blocked in censored regions due to collateral damage to legitimate WebRTC traffic. Providers like Cloudflare, Metered Video, and ExpressTURN supply geographically distributed TURN infrastructure that can be used without any special configuration by a censorship evasion system.

2025-vilalonga-extended §1 Introduction & Background dpiactive-probingip-blocking