How Snowflake Tor Bridges Work: Technical Guide

Snowflake has three main components: the Snowflake client (built into Tor Browser for censored users), the Snowflake broker (a centralized server that coordinates connections), and Snowflake proxies (volunteer browsers running the Snowflake browser extension or standalone proxy). When a censored user starts Tor Browser with Snowflake enabled, the Tor client contacts the Snowflake broker via a domain-fronted HTTPS connection, which hides the broker request within traffic to a major CDN. The broker matches the client with an available volunteer proxy and exchanges WebRTC signaling information. The client then establishes a WebRTC data channel directly to the volunteer proxy. From the ISP's perspective, this looks like a standard WebRTC peer-to-peer connection - the same traffic pattern as browser-based video calls.

The Snowflake broker is a centralized service that censored users must reach to find proxies. To prevent the broker itself from being blocked, Snowflake uses domain fronting: the TLS SNI header shows a legitimate CDN domain (like a major cloud provider) while the HTTP Host header requests the actual broker URL. This technique works when the CDN and the broker's hosting domain share the same IP infrastructure. Domain fronting has been blocked by some cloud providers (Google, Amazon) that explicitly prohibited it in their terms of service. Snowflake uses multiple domain fronting options and AMP cache fronting as fallback mechanisms to maintain broker accessibility even as individual fronting paths become unavailable.

WebRTC (Web Real-Time Communication) is a browser API for peer-to-peer audio, video, and data communication without plugins. WebRTC is used by browser-based video conferencing (Google Meet, Facebook Messenger, Discord), online gaming, and peer-to-peer file sharing applications. Censors blocking WebRTC traffic would disrupt these legitimate applications, creating significant collateral damage for businesses and individuals using web-based video communication. This collateral damage makes broad WebRTC blocking unacceptable for most governments that need to maintain functional internet for economic activity. Snowflake exploits this protection by tunneling Tor traffic through WebRTC data channels that are protocol-identical to legitimate application WebRTC connections.

Anyone can run a Snowflake proxy by installing the Snowflake browser extension (Firefox or Chrome) or running the standalone snowflake-proxy binary on a server or desktop computer. The extension or proxy registers with the Snowflake broker as an available proxy. When a censored user connects through the broker, the proxy relays traffic between the censored user and the Tor network. The proxy sees obfuscated Tor traffic but cannot read contents (Tor's encryption protects content). Proxies do not need open ports or static IPs - they initiate the WebRTC connection outward. This means proxies work behind NAT and residential connections without router configuration. The Snowflake WebExtension page shows real-time statistics on connections served.

Snowflake's primary limitation is its dependence on the broker for connection initiation. If the broker becomes unreachable (domain fronting blocked or CDN cooperation withdrawn), new Snowflake connections cannot be established, though existing connections may continue. Snowflake is also slower than obfs4 for many users because WebRTC connections route through STUN servers for NAT traversal, adding latency. Active censor probing of suspected Snowflake proxies is difficult because the WebRTC handshake does not distinguish a Snowflake proxy from a legitimate video call endpoint without the broker's signaling information. Sophisticated censors can potentially use traffic analysis to identify characteristic Snowflake connection patterns over time, though this requires sustained monitoring infrastructure.