b9cc54b3b7
Normally all dangling goroutines are terminated when the main function exits. However, for projects that use a patched version of snowflake as a library, these goroutines continued running as long as the main function had not yet terminated. This commit has all open SOCKS connections close after receiving a shutdown signal. |
||
|---|---|---|
| broker | ||
| client | ||
| common | ||
| doc | ||
| probetest | ||
| proxy | ||
| server | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| README.md | ||
Snowflake
Pluggable Transport using WebRTC, inspired by Flashproxy.
Table of Contents
Usage
cd client/
go get
go build
tor -f torrc
This should start the client plugin, bootstrapping to 100% using WebRTC.
Dependencies
Client:
- pion/webrtc
- Go 1.10+
More Info
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:
ClientTransportPlugin snowflake exec ./client --meek
Test Environment
There is a Docker-based test environment at https://github.com/cohosh/snowbox.
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 with Standalone Proxy --
cd proxy
go build
./proxy
More documentation on the way.
Also available at: torproject.org/pluggable-transports/snowflake