2011-smits-bridgespa
findings extracted from this paper
-
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.
-
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.
-
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.
-
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.