WebRTC Pluggable Transport
Pluggable Transport using WebRTC, inspired by Flashproxy.
Table of Contents
cd client/ go get go build tor -f torrc
This should start the client plugin, bootstrapping to 100% using WebRTC.
Client: - pion/webrtc - Go 1.10+
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
-frontallow the Snowflake client to speak to the Broker, in order to get connected with some volunteer's browser proxy.
-iceis a comma-separated list of ICE servers, which are required for NAT traversal.
For logging, run
tail -F snowflake.login a second terminal.
You can modify the
torrcto use your own broker:
ClientTransportPlugin snowflake exec ./client --meek
There is a Docker-based test environment at https://github.com/cohosh/snowbox.
Q: How does it work?
In the Tor use-case:
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 build ./proxy
More documentation on the way.
Also available at: torproject.org/pluggable-transports/snowflake