Tor Bridge Distribution: How Bridges Reach Censored Users

BridgeDB is the Tor Project's bridge distribution system. When you configure your bridge with BridgeDistribution in torrc, it registers in BridgeDB and is distributed through one of several channels. Distribution channels: (1) HTTPS distribution - bridges.torproject.org provides bridges via HTTPS, rate-limited by IP to prevent bulk enumeration. Uses domain fronting so the site appears to be a CDN connection. (2) Email distribution - bridges@torproject.org responds to email requests with bridges, rate-limited by email address using a Hashcash-like token. Gmail and Riseup email addresses are accepted (reducing throwaway account abuse). (3) Moat - a built-in Tor Browser feature that fetches bridges directly from BridgeDB via domain fronting without requiring manual website access. (4) Reserved distribution - bridges distributed to partner organizations (OONI, Access Now) for distribution to specific censored communities. Configure with BridgeDistribution moat or BridgeDistribution https or BridgeDistribution email.

Moat is a BridgeDB distribution channel integrated into Tor Browser that reduces friction for users needing bridges. When a Tor Browser user selects Request a Bridge in the Connection settings, Tor Browser contacts BridgeDB via a domain-fronted API (appearing to contact a Cloudflare CDN domain) to fetch bridge addresses without the user needing to visit a website or send email. The domain fronting means the request to BridgeDB is invisible to network censors who block bridges.torproject.org. Moat is designed to be resistant to the blocking of bridges.torproject.org itself. From a bridge operator's perspective: configuring BridgeDistribution moat distributes your bridge via the Moat channel, reaching Tor Browser users who use the built-in bridge request feature. This is the fastest path to reaching new censored users who need bridges.

Public BridgeDB bridges face the risk of enumeration: sophisticated censors systematically probe BridgeDB with many IPs and collect bridge addresses for blocking. Private bridges (not registered in BridgeDB) avoid this risk but require the operator to distribute addresses manually. Configure a private bridge by omitting or not setting BridgeDistribution in torrc - or setting it to none. The bridge runs but is not registered with BridgeDB. Distribute bridge addresses manually: via encrypted channels (Signal, PGP email, Tor-routed messaging), through civil society organization networks, on printed materials at physical events, or embedded in trusted community resources. Private bridges distributed to a small, trusted network are much harder for censors to enumerate than public BridgeDB bridges. The trade-off: fewer users can discover and use the bridge. Best for: organizations with a defined set of at-risk users who need reliable access.

In the most restrictive environments (where bridges.torproject.org itself is blocked), domain fronting enables bridge discovery. Domain fronting: the HTTPS connection appears to go to a major CDN domain (Cloudflare, Fastly) while the actual HTTP request inside the TLS tunnel goes to bridges.torproject.org. Censors blocking bridges.torproject.org cannot block it via SNI-based blocking without blocking all HTTPS connections to the CDN. Tor Browser's Moat feature implements domain fronting automatically. For organizations distributing bridges to ultra-restricted environments: maintain a domain-fronted web endpoint that serves bridge addresses from a CDN-fronted URL, so users can fetch bridges even when bridges.torproject.org is blocked. Update the bridge list regularly as old bridges may be blocked.

Running a bridge for a specific censored community requires capacity planning. Key metrics: (1) Expected user count - how many people will use the bridge simultaneously? Each Tor user consumes a few KB/s of bandwidth. 100 simultaneous users require 1-5 Mbit/s. (2) Bandwidth budget - how much data transfer per month? A bridge handling 100 users continuously uses 300 GB - 1 TB per month. (3) Server resources - Tor relay CPU usage scales with circuit count, not bandwidth. A 1 GHz CPU core handles thousands of circuits. (4) Geographic placement - bridges in Europe (Iceland, Netherlands) have good latency to North Africa, Middle East, and Latin America. Bridges in Asia (Singapore, Tokyo) serve South and Southeast Asian users better. Monitor your bridge's usage via Tor Metrics (metrics.torproject.org) after it has been operational for 2-4 weeks.