On Tue, Feb 11, 2020 at 10:17:42PM -0700, David Fifield wrote:
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.
https://gitweb.torproject.org/user/dcf/tor-browser-build.git/commit/?h=snowf... https://people.torproject.org/~dcf/pt-bundle/tor-browser-snowflake-turbotunn...
Here's a build that replaces kcp-go and smux with quic-go. Instead of adding 7 new projects to tor-browser-build, it adds none. Functionally, it's the same as the kcp-go version (but incompatible, of course).
https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=turbotunnel&a... Here are the changes to convert from kcp-go to quic-go. As you can see, it's not that bad. The main thing, as I've said, is that QUIC has its own TLS handshake which means you need a certificate for the server. I decided not to have the client verify the server's certificate (here in the inner QUIC layer only, independent of any other TLS interactions the client may do), because we don't rely on having a secure channel here, and the code necessary to support it would distract from the Turbo Tunnel changes I want to emphasize. If you want to see what that code would look like: https://gitweb.torproject.org/pluggable-transports/meek.git/commit/?h=turbot...
== 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 5eff0f3ba406eb7d8cd90711edab7de7d7bda4fa 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.
Beware that with Tor Browser 9.5a5 soon to be released, these special builds will try to auto-update themselves right away, and then you won't have a special Turbo Tunnel build anymore. Set app.update.auto=false in about:config to prevent the automatic upgrade.