Snowflake
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:
- go-webrtc.
- Go 1.5+
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:
- 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...
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