https://gitweb.torproject.org/user/dcf/tor-browser-build.git/commit/?h=snowf... https://people.torproject.org/~dcf/pt-bundle/tor-browser-snowflake-turbotunn...
This is a build of Tor Browser using the Turbo Tunnel–enabled Snowflake. The public Snowflake bridge is not yet Turbo Tunnel–aware, so at this point you have to run your own local broker, proxy, and bridge.
== How to try it ==
Download the branch and build all but the client: git clone https://git.torproject.org/pluggable-transports/snowflake.git cd snowflake git remote add dcf https://git.torproject.org/user/dcf/snowflake.git git fetch dcf git checkout 2cb47769e3c83a8998fcaccf0527701c7630f048 for d in broker proxy-go server; do (cd $d && go build); done Run the broker: broker/broker --disable-tls --addr 127.0.0.1:8000 Run a proxy: proxy-go/proxy-go --broker http://127.0.0.1:8000/ --relay ws://127.0.0.1:8080/ Run the bridge: tor -f torrc.server # contents of torrc.server: DataDirectory datadir-server SocksPort 0 ORPort 9001 ExtORPort auto BridgeRelay 1 AssumeReachable 1 PublishServerDescriptor 0 ServerTransportListenAddr snowflake 0.0.0.0:8080 ServerTransportPlugin snowflake exec server/server --disable-tls --log snowflake-server.log
Unpack the Tor Browser package and edit the file Browser/TorBrowser/Data/Tor/torrc-defaults. Configure it to use the local broker by changing the "ClientTransportPlugin snowflake" line: ClientTransportPlugin snowflake exec ./TorBrowser/Tor/PluggableTransports/snowflake-client -url http://127.0.0.1:8000/ -ice stun:stun.l.google.com:19302 -log snowflake-client.log
Run Tor Browser. Select "Configure" then "Tor is censored in my country" then "Provide a bridge I know". Enter snowflake 0.0.3.0:1 The purpose of this step is to provide a bridge line without a fingerprint. If you just select "snowflake" from the menu, it will use a bridge line with a fingerprint of the public bridge, which won't match the fingerprint of the bridge you are running locally.
Now click "Connect" and you can surf. I think you'll agree that the experience is markedly better than currently exists with Snowflake. Part of that is because you're using a fast and reliable local proxy, but also, you can leave it running all day and come back to it, and it will still be working.
== Dependency considerations ==
While implementing the tor-browser-build changes, I was dismayed at the number of new dependencies introduced by kcp-go. And the sad thing is, almost none of them are actually used in the build--they are only needed to support features of kcp-go that we don't actually use, like the built-in crypto and forward error correction.
- snowflake - pion-webrtc - smux (new) - kcp-go (new) - goerrors - gogmsm (new) - goreedsolomon (new) - gocpuid (new) - goxcrypto - x/crypto/blowfish (new) - x/crypto/cast5 (new) - x/crypto/pbkdf2 (new) - x/crypto/salsa20 (new) - x/crypto/tea (new) - x/crypto/twofish (new) - x/crypto/xtea (new) - goxnet - x/net/ipv4 (new) - x/net/ipv6 (new) - go-templexxx-xorsimd (new) - go-templexxx-cpu (new)
It's making me have second thoughts about using kcp-go instead of quic-go. quic-go is already present in the tor-browser-build tree, as a dependency of pion-webrtc, so it wouldn't introduce a new nest of dependencies.
Switching from kcp-go to quic-go isn't very difficult, because the APIs are similar. The main thing is to decide what to do with the obligatory TLS layer in quic-go. We could just disable certificate verification in the client (because the data we send is already encrypted+authenticated), or do public key pinning as I did in the meek implementation: https://github.com/net4people/bbs/issues/21#issue-540238698
So I think I will try another build with quic-go in place of kcp-go. Then I'm thinking that we should deploy the turbotunnel branch to the public bridge, and invite testing with another Tor Browser build.