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

[Tor Bug Tracker & Wiki]

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

Comment (by dcf):

 My observations from running the quic and kcp browsers more or less
 continuously since yesterday.

  * The experience is still pretty hit or miss. Sometimes you get a good
 proxy and cruise on it for a while; other times you get delays of several
 minutes caused by a series of non-working proxies—not slow proxies, but
 ones that never send any downstream data at all. I don't know why so many
 proxies should be broken in this way; for me it must be over 50% of them.
  * I got to the point of continuously tailing both snowflake-client logs
 to get some insight into what was happening.
  * The worst is when a series of bad proxies causes a delay of a few
 minutes with no data transfer; in that case tor gets into a "No running
 bridges" bridges state that it is hard to coax out of. When this happens
 it's not evident in the snowflake-client log; you have to go to
 about:preferences#tor and look at the tor log. It may look like this:
{{{
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $3F50D11DE55C028B8F3EFC272BB1CD9138C1F9A4~0x616e6f6e at 178.17.171.78.
 Retrying on a new circuit.
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $3F50D11DE55C028B8F3EFC272BB1CD9138C1F9A4~0x616e6f6e at 178.17.171.78.
 Retrying on a new circuit.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
}}}
Or this:
{{{
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $6B062B0FDFEAC3C6F9203FB9584451E295574DAD~idideditTheconfig at
 51.15.37.97. Retrying on a new circuit.
 [NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
 $7761DDC7EB1BE26D4155F74A15F12C32A36FE0F2~CalyxInstitute09 at
 162.247.74.217. Retrying on a new circuit.
 [NOTICE] Delaying directory fetches: No running bridges
 [NOTICE] Application request when we haven't received a consensus with
 exits. Optimistically trying known bridges again.
}}}
When this happens, I usually have luck in going to
 about:preferences#tor, momentarily switching from snowflake to obfs4, then
 switching back to snowflake. This restarts the snowflake-client process
 and seems to cause tor to have a fresh look at its bridges.
  * I'm not noticing a ton of subjective difference in the feel of the two
 browsers. The main difference I have seen is that the quic one
 occasionally spends a few minutes at 100% CPU: #33401.
  * It may be my imagination, but I get the impression that everything
 works better while the connection is being used. Initially my impression
 was positive as I was trying to stress the system by having videos playing
 in the background. Then the experience became more frustrating as I tried
 normal text browsing and I encountered the occasional delays mentioned
 above. It made me think that perhaps there is something in the proxy that
 drops idle connections, but I didn't find anything like that. It's
 possible that this is my imagination and that my initial impression was
 just getting good luck with proxies.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

Comment (by cohosh):

 Nice, it's also working for me on a non-Turbo Tunnel 9.5a5 version of Tor
 Browser.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

Comment (by dcf):

 All right, both the packages from comment:4 are working for me, with no
 configuration other than picking "snowflake" from the menu. I had to try
 bootstrapping the quic one twice, but now it's working playing video and
 everything.

 One thing I didn't think about is that if you want a log for debugging,
 you'll have to manually add a `-log` option to the `ClientTransportPlugin`
 line in Browser/TorBrowser/Data/Tor/torrc-defaults.
 {{{
 ClientTransportPlugin snowflake exec ./TorBrowser/Tor/PluggableTransports
 /snowflake-client -url https://snowflake-broker.azureedge.net/ -front
 ajax.aspnetcdn.com -ice stun:stun.l.google.com:19302 -log snowflake-
 client.log
 }}}

 Here's a tip on how to run multiple Tor Browsers at the same time. This
 way you can run the experimental Turbo Tunnel bundles alongside your
 ordinary Tor Browser. It can be helpful to go to the Customize... menu and
 pick different themes (default/light/dark) to distinguish which is which.
  * [[doc/TorBrowser/Hacking#Launching Tor with an Alternate SOCKS and
 Control port]]

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

 * status:  merge_ready => accepted


Comment:

 I built commit
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel=da37211c74b7d6992f4cb07adb6033a684d56838
 da37211c74b7d6992f4cb07adb6033a684d56838] using go1.13.8, installed it,
 and started it at 2020-02-19 18:03:30.

 I set it up as a symlink so we can easily restore the non–Turbo Tunnel
 version if needed.
 {{{
 lrwxrwxrwx 1 root root   28 Feb 19 18:03 snowflake-server ->
 snowflake-server.turbotunnel
 -rwxr-xr-x 1 root root  9067083 Feb 18 23:18 snowflake-server.normal
 -rwxr-xr-x 1 root root 12459290 Feb 19 18:01 snowflake-server.turbotunnel
 }}}

 I tested with a non–Turbo Tunnel client at [https://gitweb.torproject.org
 /pluggable-
 transports/snowflake.git/log/?id=380b133155ad725126bc418d0e66b3c550b4c555
 380b133155ad725126bc418d0e66b3c550b4c555] using snowflake/client/torrc at
 and was able to bootstrap once, but that's all I have tested so far.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

 * status:  needs_review => merge_ready


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#6: 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:
-+--

Comment (by cohosh):

 Replying to [comment:5 dcf]:
 > 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=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.
 Yes, I'd like to go ahead with this. When it's deployed I'll make some
 trial connections on my side with the three different Snowflake Tor
 Browser builds (existing alpha, kcp, and quic). Let me know if you want
 extra eyes on the server.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

#6: 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/59.html
> And some first-draft Tor Browser builds that can use it:
>  * https://lists.torproject.org/pipermail/anti-censorship-
> team/2020-February/69.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/62.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/69.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/59.html
 And some first-draft Tor Browser builds that can use it:
  * https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/69.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/62.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 

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

[Tor Bug Tracker & Wiki]

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

Comment (by dcf):

 Here are two Tor Browser builds. These are what I hope to announce to
 testers. They are built from the [https://gitweb.torproject.org/user/dcf
 /tor-browser-build.git/log/?h=snowflake-turbotunnel-
 kcp=96495fea60b2a5aac9808343cb0d3bcec87c9230 snowflake-turbotunnel-kcp]
 and [https://gitweb.torproject.org/user/dcf/tor-browser-build.git/log/?h
 =snowflake-turbotunnel-quic=06e0ad9d4ef4c1094638648515fc846c37b1b704
 snowflake-turbotunnel-quic] branches of tor-browser-build.git
 respectively. In both cases I had the rbm submodule at
 
[https://gitweb.torproject.org/user/boklm/rbm.git/log/?h=bug_33283_v2=e4f12abe9ed81050994b5345c21b988005259396
 bug_33283_v2] from #33283 in an attempt to speed up the build.
  * [https://people.torproject.org/~dcf/pt-bundle/tor-browser-snowflake-
 turbotunnel-kcp-9.5a5-20200215/ tor-browser-snowflake-turbotunnel-
 kcp-9.5a5-20200215]
  * [https://people.torproject.org/~dcf/pt-bundle/tor-browser-snowflake-
 turbotunnel-quic-9.5a5-20200215/ tor-browser-snowflake-turbotunnel-
 quic-9.5a5-20200215]

 Both builds have [https://gitweb.torproject.org/user/dcf/tor-browser-
 build.git/commit/?h=snowflake-turbotunnel-
 kcp=59aa57b64682a17f4aaa62fae9633732dce4a1a9 a commit] that attempts to
 disable automatic updates for 60 days. My reasoning is that we don't want
 our testers to experience an automatic update while they are testing these
 special builds, because an update would remove the snowflake-turbotunnel
 features. But also, if someone for some reason decides to keep using an
 experimental build, we don't want them to be stuck on a non-updating
 browser forever.

 == How to try them locally ==

 When we deploy the [[comment:1|triple-mode bridge]], it will be possible
 to just select "snowflake" from the menu. But until a Turbo Tunnel–aware
 bridge is deployed, you have to run a broker, proxy, and bridge locally.

 1. Download the turbotunnel 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 d5be0906ffe4ef8de8a9345690713bc362d3bcee # turbotunnel branch
 for d in broker proxy-go server; do (cd $d && go get); done
 # set dependencies to the same versions that Tor Browser uses
 (cd $GOPATH/src/github.com/lucas-clemente/quic-go && git checkout
 907071221cf97f75398d9cf8b1174e94f56e8f96)
 (cd $GOPATH/src/github.com/marten-seemann/qtls && git checkout
 65ca381cd298d7e0aef0de8ba523a870ec5a96fe)
 for d in broker proxy-go server; do (cd $d && go build); done
}}}
 2. Run the broker.
{{{
 broker/broker --disable-tls --addr 127.0.0.1:8000
}}}
 3. Run a proxy.
{{{
 proxy-go/proxy-go --broker http://127.0.0.1:8000/ --relay
 ws://127.0.0.1:8080/
}}}
 4. Run the bridge. Create a file called '''torrc.server''' with the
 contents
{{{
 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
}}}
Then run the command
{{{
 tor -f torrc.server
}}}
 5. Unpack the Tor Browser package and edit the file
 '''Browser/TorBrowser/Data/Tor/torrc-defaults'''. Change the
 `ClientTransportPlugin snowflake` line to make it use the local broker:
{{{
 ClientTransportPlugin snowflake exec ./TorBrowser/Tor/PluggableTransports
 /snowflake-client -url http://127.0.0.1:8000/ -ice
 stun:stun.l.google.com:19302
}}}
 6. Run Tor Browser. Select '''Configure''', then '''Tor is censored in my
 country''', then '''Provide a bridge I know'''. In the box, enter
{{{
 snowflake 0.0.3.0:1
}}}
 7. Click '''Connect''' and everything should start working. Keep an eye on
 the proxy-go output to see if packets are flowing. The Turbo Tunnel
 feature means you should be able to leave the browser idle for hours and
 have it still be working later, in the worst case after a wait of 30
 seconds.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list

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

[Tor Bug Tracker & Wiki]

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

Comment (by cohosh):

 Replying to [comment:1 dcf]:
 > This is a commit for the triple-mode bridge as described. It works by
 creating two `QueuePacketConn`s, one for KCP and one for QUIC, and using
 separate [https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/61.html magic prefix tokens] to distinguish the two
 protocols.
 >
 
https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=turbotunnel=d5be0906ffe4ef8de8a9345690713bc362d3bcee
 >
 > I have made branches
 [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-
 kcp=874a11f6779429246263522fc751f1cc0d9c3af0 turbotunnel-kcp] and
 [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-
 quic=d5be0906ffe4ef8de8a9345690713bc362d3bcee turbotunnel-quic] for
 clients specialized to use one protocol or the other, and I've started Tor
 Browser builds with them.

 Cool, these look good! I am in support of this idea, and that now is a
 good time to do it.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

Comment (by cohosh):

 It will be useful here to understand what kind of feedback we would like
 or are expecting from testers. We've had really good feedback before, for
 example on #31971, on the performance of Snowflake on Windows. That led us
 to make some tests that allowed us to verify the performance problems.

 Perhaps along with asking for user feedback, we should run some of the
 tests we've made on the two versions. That way, if there's a difference in
 performance that's significant but too slight to be detected in a user
 interface we can have some data to back up our decision?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

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

[Tor Bug Tracker & Wiki]

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

Comment (by dcf):

 Replying to [ticket:6 dcf]:
 > 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.

 This is a commit for the triple-mode bridge as described. It works by
 creating two `QueuePacketConn`s, one for KCP and one for QUIC, and using
 separate [https://lists.torproject.org/pipermail/anti-censorship-
 team/2020-February/61.html magic prefix tokens] to distinguish the two
 protocols.
 
https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=turbotunnel=d5be0906ffe4ef8de8a9345690713bc362d3bcee

 I have made branches
 [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-
 kcp=874a11f6779429246263522fc751f1cc0d9c3af0 turbotunnel-kcp] and
 [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-
 quic=d5be0906ffe4ef8de8a9345690713bc362d3bcee turbotunnel-quic] for
 clients specialized to use one protocol or the other, and I've started Tor
 Browser builds with them.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs