Snowflake bridges explained: how volunteers become temporary Tor relays
When a government blocks the Tor network, the standard advice is to switch to a bridge. But bridges are servers, and servers have addresses that censors can eventually collect and block. Snowflake took a different path: instead of fixed entry points, it built a crowd of thousands of short-lived proxies operated by ordinary volunteers.
A crowd instead of a server
Snowflake grew out of an earlier experiment called Flashproxy and reached stable status in Tor Browser 10.5 in 2021, when the Tor Project counted roughly 8,000 available proxies per day (Tor Project blog). The core idea was radical simplification. A proxy did not need a dedicated server, root access, or guaranteed uptime. It just needed a browser tab or extension. Volunteers install the Snowflake extension for Firefox or Chrome, and whenever their browser is idle, their connection becomes a relay hop for someone else. Crucially, volunteers never see which sites a user visits, because traffic is wrapped in Tor encryption end to end and exits elsewhere. Inside a WebRTC proxy hop
The technical trick is WebRTC, the protocol suite that powers browser video calls. Because browsers expose WebRTC APIs to JavaScript, an entire proxy can be implemented inside a web page, making it dramatically cheaper to operate than a VPN or traditional relay (snowflake.torproject.org). WebRTC also solves an old usability problem. Its built-in NAT traversal means volunteers behind home routers do not need manual port forwarding, which had limited Flashproxy adoption. The connection between client and volunteer looks, on the wire, like ordinary video-call signaling. - The client: a censored Tor user who requests a proxy.
- The snowflake: a volunteer-run WebRTC proxy, usually ephemeral.
- The broker: a matchmaking service pairing clients with proxies.
- The bridge: the centralized Tor relay all snowflakes forward traffic to.
The broker problem and domain fronting
Before any traffic flows, the client must find a willing volunteer. Both sides contact the broker to exchange WebRTC session descriptions, and that rendezvous channel itself has to dodge censorship. Early on, developers solved this with domain fronting: requests aimed at a major CDN's domain, such as ajax.aspnetcdn.com, were secretly routed to the broker hiding behind it. That era ended abruptly. In April 2018, Google and Amazon both shut down domain fronting on their networks, breaking meek and briefly knocking out Snowflake rendezvous in countries like the UAE (Tor Project blog). The team migrated to Microsoft Azure, and later added AMP-cache based rendezvous as an alternative that no longer depends on fronted domains. Capacity limits and growing pains
Snowflake trades reliability for scale. Individual proxies vanish constantly as volunteers close tabs, so clients seamlessly re-match through the broker when one melts away. The system assumes every component can disappear at any moment, according to the authors of the definitive USENIX Security 2024 study (Bocovich et al., USENIX 2024). The bottleneck sits at the bridge side, not the volunteer pool. For years a single bridge carried nearly all Snowflake users; a second bridge shipped in Tor Browser 12.0 in December 2022 after hardware optimizations ran out of headroom. By early March 2024 the system had transferred roughly 15 petabytes of circumvention data lifetime, serving about 1.2 percent of all Tor users. Tested under fire
Real-world stress came fast. During Iran's September 2022 protests, Iranian users jumped from 1 percent to 67 percent of all Snowflake clients within four days. Two weeks later Iran blocked the TLS fingerprint used by the client, forcing emergency fixes before usage recovered. Russia followed with DTLS fingerprint blocking in late 2021, again met with countermeasures. Independent verification comes from OONI, whose Tor Snowflake test bootstraps Tor over the transport and records whether it succeeds on a given network (OONI). That open data lets researchers distinguish real blocks from transient failures. What Snowflake changed about bridge access
Snowflake reframed the arms race around economics. Blocking it requires censoring WebRTC wholesale, sacrificing video calls across an entire country, a cost most regimes hesitate to pay. As the USENIX paper puts it, resistance is measured by what sacrifices a censor must make rather than claims of absolute unblockability. For everyday users, it lowered the bar further still: no bridge line needed, just a checkbox in getting bridges settings or Tor Browser's connection panel. It complements rather than replaces obfuscation classics, as our explainer on obfs4 bridges details. The lesson stuck: sometimes the best defense against enumeration is having nothing permanent to enumerate.
