Tor Bridge Distribution via Moat: Secure Bridge Delivery Mechanisms

Tor bridges only remain useful if censors cannot enumerate them and block them all. If every bridge address were publicly listed, censors would simply block all listed addresses. Bridge distribution must: give bridges only to legitimate Tor users (not to censors posing as users), limit how many bridges any single requester can obtain (preventing bulk enumeration), and distribute bridges over channels that are themselves censorship-resistant. This is the fundamental challenge that Moat and the bridge distribution system address.

Moat is integrated into Tor Browser's bridge request flow. When a user requests bridges, Tor Browser contacts the BridgeDB server over a meek transport (which routes through Cloudflare or Amazon CDN infrastructure, making it very hard to block). The request includes a CAPTCHA solution to prevent automated bulk requests. BridgeDB returns a set of bridge addresses appropriate for the user's likely geographic location and requested transport type. The CDN-fronting of the request means that blocking the bridge distribution mechanism requires blocking Cloudflare or Amazon CDN infrastructure - which censors are generally unwilling to do because it would break huge amounts of legitimate internet traffic.

Beyond Moat, bridges can be obtained through: email to bridges@torproject.org from Gmail or Riseup accounts (anti-spam filter, different distribution channel), the Tor Project's web interface at bridges.torproject.org over HTTPS (CAPTCHA-protected, accessible through Tor), and the Tor Project's Telegram bot. Each channel provides different bridges, so if one channel is compromised or enumerated, others remain viable. Organizations operating private bridges for specific communities (journalists, activists) distribute bridge addresses through secure channels outside the public BridgeDB system - Signal groups, encrypted email, in-person distribution.

BridgeDB implements several anti-enumeration protections. Rate limiting: each email address or IP gets only a limited number of bridge addresses per day. Compartmentalization: bridges are distributed in different subsets to different requesters, so no single requester can build a complete list. Non-predictability: bridge addresses are not assigned in any predictable pattern. The goal is that an adversary attempting to enumerate all bridges would need to make an infeasibly large number of distinct requests to collect a majority of bridges. Combined with IP diversity requirements for requesters (using different source IPs to get different bridges), full enumeration is impractical for most adversaries.

Once a bridge is known to BridgeDB, it remains available until: the operator takes it offline, it is identified and blocked by censors, or the operator requests removal. Bridges added to BridgeDB are publicly audited by the Tor Project but not publicly listed - they are 'semi-private.' For maximum security, private bridges (not submitted to BridgeDB) operated by specific organizations or individuals provide addresses known only to intended users. Private bridges become blocked only if the censor actively monitors traffic to known bridge operators or conducts specific targeted surveillance, rather than through BridgeDB enumeration.