Pluggable Transport using WebRTC, inspired by Flashproxy.
Table of Contents
broker/
contains code for the Snowflake brokerdoc/
contains Snowflake documentation and manpagesclient/
contains the Tor pluggable transport client and client library codecommon/
contains generic libraries used by multiple pieces of Snowflakeproxy/
contains code for the Go standalone Snowflake proxyprobetest/
contains code for a NAT probetesting serviceserver/
contains the Tor pluggable transport server and server library code
Snowflake is currently deployed as a pluggable transport for Tor.
To use the Snowflake client with Tor, you will need to add the appropriate Bridge
and ClientTransportPlugin
lines to your torrc file. See the client README for more information on building and running the Snowflake client.
You can contribute to Snowflake by running a Snowflake proxy. We have the option to run a proxy in your browser or as a standalone Go program. See our community documentation for more details.
Snowflake can be used as a Go API, and adheres to the v2.1 pluggable transports specification. For more information on using the Snowflake Go library, see the Snowflake library documentation.
There is a Docker-based test environment at https://github.com/cohosh/snowbox.
Q: How does it work?
In the Tor use-case:
- Volunteers visit websites which host the "snowflake" proxy. (just like flashproxy)
- Tor clients automatically find available browser proxies via the Broker (the domain fronted signaling channel).
- Tor client and browser proxy establish a WebRTC peer connection.
- Proxy connects to some relay.
- Tor occurs.
More detailed information about how clients, snowflake proxies, and the Broker fit together on the way...
Q: What are the benefits of this PT compared with other PTs?
Snowflake combines the advantages of flashproxy and meek. Primarily:
-
It has the convenience of Meek, but can support magnitudes more users with negligible CDN costs. (Domain fronting is only used for brief signalling / NAT-piercing to setup the P2P WebRTC DataChannels which handle the actual traffic.)
-
Arbitrarily high numbers of volunteer proxies are possible like in flashproxy, but NATs are no longer a usability barrier - no need for manual port forwarding!
Q: Why is this called Snowflake?
It utilizes the "ICE" negotiation via WebRTC, and also involves a great abundance of ephemeral and short-lived (and special!) volunteer proxies...
We have more documentation in the Snowflake wiki and at https://snowflake.torproject.org/.
Using gomobile
it is possible to build snowflake as shared libraries for all
the architectures supported by Android. This is in the .gitlab-ci.yml, which
runs in GitLab CI. It is also possible to run this setup in a Virtual Machine
using vagrant. Just run vagrant up
and it will
create and provision the VM. vagrant ssh
to get into the VM to use it as a
development environment.