Snowflake, a censorship circumvention system using temporary WebRTC proxies
Cecylia Bocovich, Arlo Breault, David Fifield, Serene, Xiaokang Wang
https://censorbib.nymity.ch/#Bocovich2024a
Online HTML
usenix.org page (will have slides and presentation video eventually)
PDF
This paper describes the Snowflake circumvention system: how it works, and a retrospective of operation since 2021, including reactions by censors. The principle behind Snowflake’s blocking resistance is the use of numerous (currently on the order of 100,000) non-permanent proxies that communicate with censored clients using WebRTC protocols. Snowflake proxies are simple and cheap to operate in comparison to a traditional proxy server; they can even run in a web page or browser extension; there is also a command-line version and a Snowflake proxy built into Orbot. The large and dynamic pool of proxy IP addresses is supposed to be difficult for a censor to enumerate and block, and the use of common protocols (WebRTC is often used in web browsers for audio and video communication) makes it more expensive to block by protocol.
The Snowflake system involves a many interacting components. A censored client contacts a central server called the broker, which matches the client with one of the currently available proxies and helps exchange the information that the client and proxy need in order to establish a connection (WebRTC signaling). The censor is assumed to block the client from contacting the broker directly, so the client must communicate with the broker using a blocking-resistant rendezvous protocol. (The currently implemented rendezvous methods are domain fronting, AMP cache, and Simple Queue Service.) The client starts sending information to the proxy, but the proxy doesn’t exit the client’s traffic directly: instead, it forwards the traffic to a permanent, centralized bridge, which is what actually delivers the traffic to the client’s desired destination. The traffic stream is encrypted between the client and the bridge, so proxies cannot eavesdrop on or tamper with user traffic. Having a separate bridge also ensures that client traffic is not wrongly attributed to volunteer proxies. The protocol stack features a Turbo Tunnel layer (underneath the WebRTC) so that clients can switch from one proxy to another without interruption. (Proxies are allowed to go offline at any time, even when they are being used by a client.)
Section 4 is a blow-by-blow account of how Snowflake has fared in deployment, and how the number of users and proxies have been affected by world events. The authors provide detailed case studies of reactions of censors in four countries. At the end of 2021, users in Russia became the largest contingent of Snowflake users after an incident of blocking of Tor servers and protocols. In 2022, a large number of people began using Snowflake in Iran after shutdowns and blocking there. Snowflake was briefly blocked by TLS fingerprinting but recovered, and the majority of Snowflake users are in Iran to this day. In China there has not been much evidence of attempts to block Snowflake, with only one or two minor incidents recorded. In Turkmenistan, Snowflake has not been very successful, only ever having a maximum of a few dozen simultaneous users; nevertheless there is a history of blocking and unblocking events.