[tor-bugs] #33336 [Circumvention/Snowflake]: Deploy a Turbo Tunnel–aware Snowflake bridge

[Tor Bug Tracker & Wiki]

#33336: Deploy a Turbo Tunnel–aware Snowflake bridge
-------------------------------------+------------------------------
 Reporter:  dcf                      |          Owner:  dcf
     Type:  task                     |         Status:  needs_review
 Priority:  Medium                   |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:  turbotunnel              |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+------------------------------
Changes (by dcf):

 * status:  assigned => needs_review


Old description:

> We now have a
> [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel
> turbotunnel branch] of Snowflake that uses an inner transport protocol to
> migrate session across multiple proxies.
>  * https://lists.torproject.org/pipermail/anti-censorship-
> team/2020-February/000059.html
> And some first-draft Tor Browser builds that can use it:
>  * https://lists.torproject.org/pipermail/anti-censorship-
> team/2020-February/000069.html
>
> I want to deploy a bridge that supports Turbo Tunnel, then make Tor
> Browser builds and invite testers to test them.
>
> There's the question of whether to run the Turbo Tunnel code on the
> existing public bridge, or to set up a second bridge reserved for the
> Turbo Tunnel experiment. I propose to run the Turbo Tunnel code on the
> existing public bridge (i.e., snowflake.torproject.net). This is because
> (1) the Turbo Tunnel server is [https://lists.torproject.org/pipermail
> /anti-censorship-team/2020-February/000062.html backward-compatible] with
> non–Turbo Tunnel clients, and (2) we would need to somehow provide proxy
> capacity for the second bridge, which our current proxy code cannot
> easily handle. Running a separate bridge would have the advantage,
> though, that because we would have to run our own special proxy-go
> instances to support it, we could closely control the proxy environment;
> but part of my goal in an experimental deployment is to see how the Turbo
> Tunnel code fares with the organic proxies we have now.
>
> I've have versions of the code using two different session/reliability
> protocol libraries: kcp-go and quic-go. Other than to note that two two
> libraries are [https://github.com/net4people/bbs/issues/14 basically
> equivalent in features], I haven't done much to compare them as to
> performance. kcp-go is more mature and stable, while quic-go
> [https://lists.torproject.org/pipermail/anti-censorship-
> team/2020-February/000069.html add fewer dependencies to the Tor Browser
> build].
>
> We could make use of this opportunity to compare the two options. We set
> up a triple-mode bridge: supporting legacy, KCP, and QUIC clients. We
> make two Tor Browser builds, one with KCP and one with QUIC, and invite
> testing of both. Based on the results of user testing, we decide which we
> like better, and finally deploy only that option (and the backward-
> compatible mode). The only thing is, giving people two options to test is
> more confusing than giving them one.

New description:

 We now have a
 [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel
 turbotunnel branch] of Snowflake that uses an inner transport protocol to
 migrate session across multiple proxies.
  * https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/000059.html
 And some first-draft Tor Browser builds that can use it:
  * https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/000069.html

 I want to deploy a bridge that supports Turbo Tunnel, then make Tor
 Browser builds and invite testers to test them.

 There's the question of whether to run the Turbo Tunnel code on the
 existing public bridge, or to set up a second bridge reserved for the
 Turbo Tunnel experiment. I propose to run the Turbo Tunnel code on the
 existing public bridge (i.e., snowflake.torproject.net). This is because
 (1) the Turbo Tunnel server is [https://lists.torproject.org/pipermail
 /anti-censorship-team/2020-February/000062.html backward-compatible] with
 non–Turbo Tunnel clients, and (2) we would need to somehow provide proxy
 capacity for the second bridge, which our current proxy code cannot easily
 handle. Running a separate bridge would have the advantage, though, that
 because we would have to run our own special proxy-go instances to support
 it, we could closely control the proxy environment; but part of my goal in
 an experimental deployment is to see how the Turbo Tunnel code fares with
 the organic proxies we have now.

 I've have versions of the code using two different session/reliability
 protocol libraries: kcp-go and quic-go. Other than to note that the two
 libraries are [https://github.com/net4people/bbs/issues/14 basically
 equivalent in features], I haven't done much to compare them as to
 performance. kcp-go is more mature and stable, while quic-go
 [https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/000069.html adds fewer dependencies to the Tor Browser
 build].

 We could make use of this opportunity to compare the two options. We set
 up a triple-mode bridge: supporting legacy, KCP, and QUIC clients. We make
 two Tor Browser builds, one with KCP and one with QUIC, and invite testing
 of both. Based on the results of user testing, we decide which we like
 better, and finally deploy only that option (and the backward-compatible
 mode). The only thing is, giving people two options to test is more
 confusing than giving them one.

--

Comment:

 Shall we deploy the Turbo Tunnel bridge? I can do it as early as today. I
 was waiting until we had figured out #33367 (and I've added the patch for
 #33367 to the turbotunnel branch).

 To be specific, what I want to do is build the server at commit
 [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel&id=da37211c74b7d6992f4cb07adb6033a684d56838
 da37211c74b7d6992f4cb07adb6033a684d56838] to the public bridge. Then watch
 it closely for a few hours to make sure it hasn't broken currently
 deployed clients. The Tor Browser packages from comment:4 should start
 working just by selecting "snowflake" from the menu, without extra
 configuration.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33336#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online