Skip to content
Snippets Groups Projects

Snowflake

Build Status

A Pluggable Transport using WebRTC, inspired by Flashproxy

Table of Contents

Status

Successfully & automatically bootstraps with a WebRTC transport, using HTTP signaling (with optional domain fronting) speaking to a multitude of volunteer "snowflakes". Still lots of work to do.

Usage

cd client/
go get
go build
tor -f torrc

This should start the client plugin, bootstrapping to 100% using WebRTC.

Dependencies

Client:

Proxy:


More Info

The client uses the following torrc options:

ClientTransportPlugin snowflake exec ./client \
-url https://snowflake-reg.appspot.com/ \
-front www.google.com \
-ice stun:stun.l.google.com:19302

Which allows it to speak to the Broker, get matched with a "snowflake" browser proxy, and negotiate a WebRTC PeerConnection.

To see logs, do tail -F snowflake.log in a second terminal.

You can modify the torrc to use your own broker, or remove the options entirely which will default to the old copy paste method (see torrc-manual):

ClientTransportPlugin snowflake exec ./client --meek

Building a Snowflake

This will only work if there are any browser snowflakes running at all. To run your own, first make sure coffeescript is installed. Then, build with:

cd proxy/
cake build

(Type cake by itself to see possible commands)

Then, start a local http server in the proxy/build/ in any way you like. For instance:

cd build/
python -m http.server

Then, open a browser tab to http://127.0.0.1:8000/snowflake.html, which causes you to act as an ephemeral Tor bridge.

FAQ

Q: How does it work?

In the Tor use-case:

  1. Volunteers visit websites which host the "snowflake" proxy. (just like flashproxy)
  2. Tor clients automatically find available browser proxies via the Broker (the domain fronted signaling channel).
  3. Tor client and browser proxy establish a WebRTC peer connection.
  4. Proxy connects to some relay.
  5. 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...

Appendix

-- Testing Copy-Paste Via Browser Proxy --

Open a browser proxy, passing the manual parameter; e.g. http://127.0.0.1:8000/snowflake.html?manual=1,

Open up three terminals for the client:

A: tor -f torrc-manual SOCKSPort auto

B: cat > signal

C: tail -F snowflake.log

Then, in the browser proxy:

  • Look for the offer in terminal C; copy and paste it into the browser.
  • Copy and paste the answer generated in the browser back to terminal B.
  • Once WebRTC successfully connects, the browser terminal should turn green. Shortly after, the tor client should bootstrap to 100%.
-- Testing directly via WebRTC Server --

See server-webrtc/README.md for information on connecting directly to a WebRTC server transport plugin, bypassing the Broker and browser proxy.

More documentation on the way.

Also available at: torproject.org/pluggable-transports/snowflake