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.
Client:
- go-webrtc
- Go 1.5+
Proxy:
Tor can plug in the Snowflake client via a correctly configured torrc.
For example:
ClientTransportPlugin snowflake exec ./client \
-url https://snowflake-broker.azureedge.net/ \
-front ajax.aspnetcdn.com \
-ice stun:stun.l.google.com:19302
-max 3
The flags -url and -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
method (see torrc-manual):
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
(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 to view
the debug-console of the snowflake.,
So long as that tab is open, you are an ephemeral Tor bridge.
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...
cd proxy-go
go build
./proxy-go
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%.
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