Snowflake Tor Bridge: Technical Architecture and Performance Analysis

Snowflake involves three parties: the Tor client (user), the Snowflake proxy (volunteer running browser extension or standalone proxy), and the Snowflake broker (coordination server). The handshake: (1) Tor client contacts the Snowflake broker via domain fronting (broker's URL is fronted by a CDN, making it appear as traffic to the CDN). (2) Broker matches the client with an available proxy. (3) Client and proxy establish a WebRTC peer connection. (4) Tor traffic flows through the WebRTC connection to the proxy. (5) Proxy forwards to the Tor network entry point. The proxy's IP is what appears to network observers - volunteer residential IPs are extremely difficult to block comprehensively.

The Snowflake broker (which matches clients with proxies) is the most vulnerable component - if blocked, clients cannot find proxies. Domain fronting protects the broker: the HTTPS request appears to go to a CDN domain (e.g., ajax.googleapis.com) but the Host header inside the TLS connection routes to the actual broker. This makes blocking the broker impossible without blocking the entire CDN. CDN providers have contested domain fronting (Google and AWS specifically prohibited it in their terms), leading Snowflake to develop alternative signaling channels. The current implementation uses AMP (Accelerated Mobile Pages) caching as a domain fronting alternative, using Google's AMP cache as a fronting domain.

Snowflake proxies are run by volunteers using a browser extension (available for Chrome/Firefox) or a standalone Go binary. The proxy establishes a WebRTC connection with the censored user and forwards traffic to the Tor network's Snowflake bridge server. Security properties of the proxy: the proxy sees only obfuscated Tor traffic (not the user's browsing content). The proxy knows the user's IP (WebRTC peer connection requires IP exchange). The proxy does not know the user's final Tor destination. Running a Snowflake proxy is less operationally demanding than running a bridge server (no server required, runs in browser) and carries lower legal risk than running an exit relay (not forwarding user traffic to public internet).

Snowflake performance is variable because it depends on volunteer proxies. Factors affecting performance: proxy geographic location relative to the user (nearby proxies mean lower RTT), proxy connection quality (residential connections vary widely), number of available proxies (high demand periods have more clients competing for proxies). Typical performance: 1-5 Mbps bandwidth, 200-500ms additional latency from WebRTC overhead. Compared to obfs4: Snowflake is slower (WebRTC has more overhead than obfs4's simple XOR-based obfuscation), but provides a much larger and more geographically diverse IP pool. The Snowflake standalone server (on datacenter VPS) has better performance than volunteer browser extension proxies.

Two ways to contribute to Snowflake: (1) Snowflake proxy - run as a browser extension or standalone binary, acts as an intermediary between censored users and the Snowflake bridge server. No server required. Low operational burden. (2) Snowflake bridge server - a full Tor bridge with the Snowflake transport server component, which is the entry point for Snowflake traffic into the Tor network. Requires a server with public IP. More complex setup but more impact per operator. The Tor Project runs official Snowflake bridge servers. Running a private Snowflake bridge server and distributing the bridge line provides a high-privacy bridge resistant to automated censorship because the Snowflake protocol's WebRTC connections are difficult to identify as Tor traffic.