Technical overview of the Snowflake Proxy
Snowflake is a new WebRTC pluggable transport. This document provides a technical overview of Snowflake in terms of system components, interactions and code. It is intended to introduce Snowflake to a tech-savvy reader and those interested in this project and internet freedom in general. In particular, this document discusses Snowflake's use of WebRTC, its approach to rendezvous using domain fronting, its method for NAT traversal using ICE negotiation, and a number of other considerations without assuming significant prior knowledge of these topics. Snowflake and this live document are under development. As the Snowflake project evolves, this document will be updated and additional documents will be made available to discuss metrics, additional topics, and other relevant findings in light of future work on this project.
Introduction
Snowflake is a new circumvention tool that provides access to the free and open Internet. As a pluggable transport, it provides easy access to a censorship circumvention system, such as Tor. It is inspired by and builds on previous work such as Flashproxy. Snowflake is similar to a mixture of previous Pluggable Transports, and this document serves as a guide to exploring this system.
To illustrate this in the context of Tor, Snowflake allows anyone to leave a browser tab open to become an ephemeral Tor bridge. Similar to the design of Flashproxy, Snowflake consists of a large network of highly ephemeral volunteer proxies, with the goal of overtaking the censor's ability to block proxy IP addresses and providing a very simple, reliable, and hard-to-filter method of circumventing censorship. Previously, users had difficulty manually configuring port forwarding, which limited the adoption of older tools such as Flashproxy. Snowflake addresses NAT traversal by making it automatic and not the responsibility of the user, alongside a number of new benefits.
Ease of use and reliability are important to the Snowflake system, both in terms of simplifying the connection process for people in censored regions and enabling volunteers to help others connect very easily. This allows the bypass system to scale more easily in both the number of volunteers and clients. In this way, the Snowflake system becomes stronger and stronger in terms of circumvention capacity, bandwidth and resilience with the size of its volunteer network.
Overview
Using Tor as a use case, the sequence of interactions in a Snowflake session can be as follows:
A user in the filtered region wants to access the free and open Internet. They open the Tor browser and select Snowflake as the pluggable transport. This launches the Snowflake client.
Volunteers outside the filtered region visit websites that host the Snowflake proxy code. The browsers of these volunteers then become temporary proxies available to a Snowflake client.
The filtered user's Snowflake client automatically finds some of these volunteer remote in-browser Snowflake proxies using a secure rendezvous strategy that also automatically traverses NAT.
These two Snowflake peers establish a peer-to-peer connection via WebRTC.
Once WebRTC is ready, the Snowflake client makes the WebRTC transport available for use by Tor.
In the meantime, the volunteer's Snowflake proxy connects to a target Tor relay and begins transmitting traffic between the Snowflake client and the Tor relay.
Tor establishes a circuit and the user can now bypass censorship.
To further clarify, it is not the website hosting Snowflake that acts as the Snowflake proxy. Rather, it is the visitor to the website - their browser tab becomes a volunteer proxy.
Snowflake consists of three components that enable this process:
The Snowflake client, which is a client transport plugin that conforms to the Pluggable Transport Specification. Tor uses this like any other pluggable transport. Any other ptspec-aware system could do this as well. This component is written in Golang.
The Snowflake proxy, which is a miniature in-browser WebRTC proxy. It transmits data between Snowflake clients and a target - for Tor, this would be a Tor relay. This component is written in CoffeeScript.
The broker, responsible for the rendezvous. It is similar to the “Facilitator” of Flashproxy, but currently only uses domain fronting. This component is written in Golang.
The Snowflake client and the Snowf