Pluggable Transport using WebRTC, inspired by Flashproxy.
- Transport: Successfully connects using WebRTC.
- Rendezvous: HTTP signaling (with optional domain fronting) to the Broker arranges peer-to-peer connections with multitude of volunteer "snowflakes".
- Client multiplexes remote snowflakes.
- Can browse using Tor over Snowflake.
- Reproducible build with TBB.
Table of Contents
cd client/ go get go build tor -f torrc
This should start the client plugin, bootstrapping to 100% using WebRTC.
- Go 1.5+
Tor can plug in the Snowflake client via a correctly configured
ClientTransportPlugin snowflake exec ./client \ -url https://snowflake-reg-test.appspot.com/ \ -front www.google.com \ -ice stun:stun.l.google.com:19302 -max 3
-front allow the Snowflake client to speak to the Broker,
in order to get connected with some volunteer's browser proxy.
-ice is a
comma-separated list of ICE servers, which are required for NAT traversal.
For logging, run
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
ClientTransportPlugin snowflake exec ./client --meek
This describes how to build the in-browser snowflake. For the client, see Usage, above.
The client will only work if there are browser snowflakes available. To run your own:
cd proxy/ cake build
cake by itself to see possible commands)
Then, start a local http server in the
proxy/build/ in any way you like.
cd build/ python -m http.server
Then, open a browser tab to
http://127.0.0.1:8000/snowflake.html to view
the debug-console of the snowflake.,
So long as that tab is open, you are an ephemeral Tor bridge.
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...
-- Testing with Standalone Proxy --
cd proxy-go go build ./proxy-go
-- Testing Copy-Paste Via Browser Proxy --
Open a browser proxy, passing the
manual parameter; e.g.
Open up three terminals for the client:
tor -f torrc-manual SOCKSPort auto
cat > signal
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