[anti-censorship-team] Tor Browser with Turbo Tunnel–enabled Snowflake

David Fifield david at bamsoftware.com
Wed Feb 12 05:17:42 UTC 2020


https://gitweb.torproject.org/user/dcf/tor-browser-build.git/commit/?h=snowflake-turbotunnel&id=a0c7ffa70f09ca4d86e18a93483c1a378c3067b4
https://people.torproject.org/~dcf/pt-bundle/tor-browser-snowflake-turbotunnel-9.5a4-20200212/

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.



More information about the anti-censorship-team mailing list