How Tor Clients Discover Snowflake Proxies

The Tor network uses Snowflake, a pluggable transport, to help users bypass internet censorship by routing encrypted traffic through temporary, volunteer-operated WebRTC proxies. Because these volunteer proxies are transient and frequently change IP addresses, the Tor client does not maintain a static list of proxies. Instead, it discovers available Snowflake proxies through a centralized rendezvous mechanism known as the Snowflake Broker, using techniques like domain fronting to safely negotiate peer-to-peer connections without being blocked by censors.

The Role of the Snowflake Broker

The discovery process is orchestrated by a central rendezvous server called the Broker. Volunteer proxies (often running as browser extensions or standalone programs) constantly poll the broker via HTTP or WebSocket requests to announce their availability. The broker maintains an active pool of these idle proxies, waiting to match them with censored clients seeking access to the Tor network.

Step-by-Step Discovery and Connection Flow

  1. Reaching the Broker via Censorship-Resistant Channels Because access to Tor infrastructure is often blocked in censored regions, the Tor client cannot simply connect to the broker directly. Instead, the client uses domain fronting (or alternative rendezvous methods like AMP caches or Amazon SQS) to communicate with the broker. To a network censor, this traffic appears as an ordinary HTTPS connection to a major content delivery network (CDN) or cloud provider.

  2. Generating and Sending the WebRTC Offer Once a route to the broker is established, the Tor client generates a WebRTC Session Description Protocol (SDP) offer. This offer contains the necessary network metadata, such as ICE candidates and encryption parameters, required to establish a peer-to-peer data channel. The client transmits this SDP offer to the broker inside its encrypted rendezvous request.

  3. Proxy Matching and Dispatch Upon receiving the client’s offer, the broker selects an available volunteer proxy from its pool. The broker delivers the client’s SDP offer to the chosen proxy during the proxy’s regular polling cycle.

  4. Returning the SDP Answer The volunteer proxy accepts the offer, generates its own WebRTC SDP answer, and sends it back to the broker. The broker then relays this answer back to the waiting Tor client via the domain-fronted connection.

  5. Establishing the Peer-to-Peer WebRTC Connection With both the client and the volunteer proxy possessing each other’s SDP information, they perform NAT traversal using STUN (Session Traversal Utilities for NAT) or TURN (Traversal Using Relays around NAT) servers. They establish a direct, encrypted WebRTC peer-to-peer data channel.

Handover to the Tor Network

Once the WebRTC link between the client and the Snowflake proxy is established, the client stops communicating with the broker. The volunteer proxy acts as an ephemeral bridge, forwarding the client’s encrypted Tor traffic to a dedicated Snowflake bridge relay, which then routes the data into the wider Tor network. If the volunteer closes their browser or disconnects, the Tor client seamlessly repeats the broker discovery process to find a new proxy.