[tor-bugs] #33745 [Circumvention/Snowflake]: Merge a turbotunnel branch
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Mar 27 21:48:35 UTC 2020
#33745: Merge a turbotunnel branch
-------------------------------------+--------------------------
Reporter: dcf | Owner: dcf
Type: task | Status: assigned
Priority: Medium | Milestone:
Component: Circumvention/Snowflake | Version:
Severity: Normal | Resolution:
Keywords: turbotunnel | Actual Points:
Parent ID: #19001 | Points:
Reviewer: | Sponsor:
-------------------------------------+--------------------------
Old description:
> Snowflake turbo tunnel features have now been through a test deployment
> (#33336) and a few iterations of Tor Browser packages. There haven't been
> as many test reports as I'd like, but what testing there has been has
> been mostly positive. Turbo tunnel–like features are a dependency of some
> of the tasks for a stable release of Snowflake (#19001). So we should
> merge it.
>
> Some sub-tasks:
> * Decide between the
> [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-
> kcp KCP] and [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h
> =turbotunnel-quic QUIC branch].
> * Test without `LearnCircuitBuildTimeout 0` and find another workaround,
> if necessary. See comment:15:ticket:33336.
> * Rebase and clean history of the chosen branch.
> * Redeploy bridge from master.
>
> Summary of turbo tunnel development history till now:
> * [https://lists.torproject.org/pipermail/anti-censorship-
> team/2020-February/000059.html Turbo Tunnel in Snowflake]
> * [https://lists.torproject.org/pipermail/anti-censorship-
> team/2020-February/000074.html Second draft of Turbo Tunnel Snowflake
> packages]
> * [https://lists.torproject.org/pipermail/anti-censorship-
> team/2020-March/000075.html Third draft of Turbo Tunnel Snowflake
> packages]
> * [[#33336|Trial deployment of Snowflake with Turbo Tunnel]]
> * [[#33519|Support multiple simultaneous SOCKS connections]]
>
> One bug that may or not be snowflake's fault:
> * [[#33669|"Pluggable Transport process terminated" but Tor keeps on
> going (and of course doesn't work)]]
New description:
Snowflake turbo tunnel features have now been through a test deployment
(#33336) and a few iterations of Tor Browser packages. There haven't been
as many test reports as I'd like, but what testing there has been has been
mostly positive. Turbo tunnel–like features are a dependency of some of
the tasks for a stable release of Snowflake (#19001). So we should merge
it.
Some sub-tasks:
* Decide between the
[https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-
kcp KCP] and [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h
=turbotunnel-quic QUIC branch].
* Test without `LearnCircuitBuildTimeout 0` and find another workaround,
if necessary. See comment:15:ticket:33336.
* Rebase and clean history of the chosen branch.
* Redeploy bridge from master.
Summary of turbo tunnel development history till now:
* [https://lists.torproject.org/pipermail/anti-censorship-
team/2020-February/000059.html Turbo Tunnel in Snowflake]
* [https://lists.torproject.org/pipermail/anti-censorship-
team/2020-February/000074.html Second draft of Turbo Tunnel Snowflake
packages]
* [https://lists.torproject.org/pipermail/anti-censorship-
team/2020-March/000075.html Third draft of Turbo Tunnel Snowflake
packages]
* [[ticket:33336|Trial deployment of Snowflake with Turbo Tunnel]]
* [[ticket:33519|Support multiple simultaneous SOCKS connections]]
One bug that may or not be snowflake's fault:
* [[#33669|"Pluggable Transport process terminated" but Tor keeps on going
(and of course doesn't work)]]
--
Comment (by dcf):
Replying to [ticket:33745 dcf]:
> * Decide between the
[https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-
kcp KCP] and [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h
=turbotunnel-quic QUIC branch].
On this point, I advocate for the kcp-go branch. I think that quic-go will
be the cause of a lot of maintenance difficulties. There's nothing really
wrong with QUIC the protocol (apart from it still being a changing
standard); the problem is the instability of the quic-go package.
* quic-go doesn't have a stable API, and the API
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h
=turbotunnel-quic&id=42c07f2c140e4c6f1f752329a67fdf15cd6bd8c5 has broken]
in the time I've been using it.
* quic-go is tightly coupled to a specific version of Go and its standard
library, because it uses internal data structures of the crypto/tls
package. If you compile quic-go with the wrong version of Go, you get an
error not at compile time but at runtime. The version of quic-go currently
being used requires Go 1.13, which means it cannot be built in Tor Browser
until Tor Browser upgrades its own version of Go, which is currently
stalled pending changes in rbm (#32027). It cuts the other way as well:
any future upgrade of Go will require a simultaneous upgrade of quic-go
and work to fix any API breakage.
* Upgrading quic-go past where it is now pinned will add a lot of weighty
dependencies (comment:15:ticket:33336).
* The quic-go repository is volatile. Not [[comment:1:ticket:33401|once]]
but [https://github.com/lucas-clemente/quic-go/issues/2172 twice] I
encountered significant bugs whose fix was only a few days or weeks old,
not yet in any numbered release.
* Different versions of quic-go do not necessarily interoperate.
Specifically, I know that the version of quic-go currently packaged in Tor
Browser (as a dependency of pion-webrtc), which is less than one year old,
does not interoperate with current versions of quic-go, because the old
version does not send ALPN in its TLS handshake, and newer versions
require it.
Could I be wrong in my assessment? Of course. kcp-go is not perfect either
--in particular I'm thinking about patching it to remove what of its
dependencies we don't use. If quic-go were the only option, I would say go
ahead with it, and live with the maintenance costs. But my considered
opinion is that it is more risky to deploy a system based on quic-go than
one based on kcp-go and smux.
Replying to [comment:1 arma]:
> So as we choose, we should learn if kcp has gotten much testing.
I know you mean well, but I find comments like this demoralizing. You make
it sound as I have not been thinking about this among many considerations
for months, and going out of my way to document my reasoning. You should
read my [https://github.com/net4people/bbs/issues/14 initial candidate
protocol evaluation] if you have not already.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33745#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list