Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-06-01T19:48:57Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33745Merge a turbotunnel branch2022-06-01T19:48:57ZDavid Fifielddcf@torproject.orgMerge a turbotunnel branchSnowflake 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....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 [KCP](https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-kcp) and [QUIC branch](https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-quic).
* 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:
* [Turbo Tunnel in Snowflake](https://lists.torproject.org/pipermail/anti-censorship-team/2020-February/000059.html)
* [Second draft of Turbo Tunnel Snowflake packages](https://lists.torproject.org/pipermail/anti-censorship-team/2020-February/000074.html)
* [Third draft of Turbo Tunnel Snowflake packages](https://lists.torproject.org/pipermail/anti-censorship-team/2020-March/000075.html)
* [[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)]]David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33519Support multiple simultaneous SOCKS connections2022-06-01T19:46:43ZDavid Fifielddcf@torproject.orgSupport multiple simultaneous SOCKS connectionsThe Snowflake client accepts multiple simultaneous SOCKS connections from tor, but it only tries to collect one proxy at a time, and each proxy can service only one SOCKS connection (this is true in the turbotunnel branch as well). One o...The Snowflake client accepts multiple simultaneous SOCKS connections from tor, but it only tries to collect one proxy at a time, and each proxy can service only one SOCKS connection (this is true in the turbotunnel branch as well). One of the SOCKS connections gets the only available proxy, while the others starve.
I can think of a few ways to approach this.
1. Dynamically adjust the `max` parameter according to how many SOCKS connections there are currently. If there's one SOCKS connection, we need only one proxy. If there's another SOCKS connection, raise the limit to allow the proxy-collecting thread to pick up another one, and lower the limit again if the number of SOCKS connections drops back down.
2. Start up a separate proxy-collecting thread for each SOCKS connection, as suggested at comment:12:ticket:21314. Each SOCKS connection will make its own broker requests and collect its own proxies, not interacting with those of any other SOCKS connection. A downside of this is that the number of Snowflake proxies you are contacting leaks the number of SOCKS connections you have ongoing. (Which can also be seen as a benefit in that if there are zero SOCKS connections, you don't even bother to contact the broker.)
3. Make it possible for multiple SOCKS connections to share the same proxy. Continue using a global proxy-collecting thread, and make there be a single shared `RedialPacketConn` instead of a separate one for each SOCKS connection. As things work now, this would require tagging _every packet_ with the ClientID, instead of [sending the ClientID once](https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/snowflake.go?h=turbotunnel&id=47312dd1eccc8456652853bd66f8ed396e9ba6ec#n52) and letting it be the same implicitly for all packets that follow.
4. Make it possible for multiple SOCKS connections to share the same proxy, and use a single KCP/QUIC connection for all SOCKS connections. Separate SOCKS connections go into separate streams within the KCP/QUIC connection. In other words, rather than doing both `sess = kcp.NewConn2/quic.Dial` and `sess.OpenStream` in the SOCKS handler, we do `sess = kcp.NewConn2/quic.Dial` in `main` and then `sess.OpenStream` in the SOCKS handler. This way we could continue tagging the ClientID just once, because the program would only ever work with one ClientID at a time. However this way would make it harder to do the "stop using the network when not being used" of #21314, because that single KCP/QUIC connection would try to keep itself alive all the time and would contact the broker every time it needed a new proxy. Perhaps we could make it so that if there are zero streams, we close the KCP/QUIC connection, and lazily create a new one if and when we get another SOCKS connection.
| |= status quo=|= 1=|= 2=|= 3=|= 4=|
|---------------------------|--------------|--------------|--------------|--------------|--------------|
|= proxy-collecting threads=| one global| one global| one per SOCKS| one global| one global|
|= proxy limit per thread=| 1| # of SOCKS| 1| 1| 1|
|= proxies shared between SOCKSes?=| dedicated| dedicated| dedicated| shared| shared|
|= `PacketConn`s=| one per SOCKS| one per SOCKS| one per SOCKS| one global| one global|
|= KCP/QUIC connections=| one per SOCKS| one per SOCKS| one per SOCKS| one per SOCKS| one global|
|= KCP/QUIC streams=| one per SOCKS| one per SOCKS| one per SOCKS| one per SOCKS| one per SOCKS|
|= ClientID on every packet?=| no| no| no| yes| no|https://gitlab.torproject.org/legacy/trac/-/issues/33693snowflake's 0.0.3.0 dummy address means rate limits are skipped means BW cont...2020-06-16T01:11:59ZRoger Dingledinesnowflake's 0.0.3.0 dummy address means rate limits are skipped means BW controller events show no bandwidth usedSnowflake's default bridge pretends to be on 0.0.3.0. It's a dummy address since snowflake-client knows how to connect to the right bridge and ignores the address that Tor tells it.
But my Tor client still uses that bridge address to ma...Snowflake's default bridge pretends to be on 0.0.3.0. It's a dummy address since snowflake-client knows how to connect to the right bridge and ignores the address that Tor tells it.
But my Tor client still uses that bridge address to make decisions. For example, connection_is_rate_limited() decides "no, it isn't rate limited", because tor_addr_is_internal() says 0.0.3.0 is essentially part of localhost. And that choice has a cascading effect where when I attach my nyx to Tor Browser to graph bandwidth use (`nyx -i 9151`), the BW events all say "0 0" because my Tor hasn't sent or received any non-internal bytes.
The quick fix is to keep using a dummy address, but to pick one that isn't an internal address. I confirmed that if I change snowflake's dummy address to 11.0.3.0, then connection_is_rate_limited() decides it's external, my BW events work again, and nyx gives me graphs. That is, Tor is smart enough to know that even though the connection is from the Tor client to the localhost snowflake client, the connection is "really" to the (non-localhost) destination bridge address.
I confess that I don't know which "apparently routable but don't worry we won't actually connect to it, probably" address is the best choice here. :/
The longer term answer is to have some other way to signal that it's a dummy address, or to change the PT interface so we don't need the fake address. But I don't think we need to wait for the longer term answer here.
The reason I noticed this issue is because I am pondering lobbying for the Tor Browser folks to give me a tiny bandwidth graph (or activity spinner) somewhere in the browser, because I got a super slow snowflake, but I was still getting 5-10KBytes/s, and my page did load after like 90 seconds, but if I hadn't been staring at the
```
2020/03/23 09:33:05 Traffic Bytes (in|out): 9018 | 10981 -- (27 OnMessages, 24 Sends)
```
lines I would have assumed that it was wedged.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/30318Integrate snowflake into mobile Tor Browser alpha2020-06-16T01:02:54ZGeorg KoppenIntegrate snowflake into mobile Tor Browser alpha#28672 is dealing with reproducibly building snowflake. This ticket is for all the build-unrelated changes we need to make so that users can actually select snowflake in their mobile Tor Browser alpha and have it working there.#28672 is dealing with reproducibly building snowflake. This ticket is for all the build-unrelated changes we need to make so that users can actually select snowflake in their mobile Tor Browser alpha and have it working there.https://gitlab.torproject.org/legacy/trac/-/issues/33669"Pluggable Transport process terminated" but Tor keeps on going (and of cours...2020-06-13T18:21:52ZRoger Dingledine"Pluggable Transport process terminated" but Tor keeps on going (and of course doesn't work)In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
...In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
It still remains unclear whether snowflake had a bug that crashed it, or if Tor has a bug that made it close the socket to snowflake.
But either way, after this event Tor quietly cries to itself:
```
Feb 25 14:36:44.825 [warn] The connection to the SOCKS5 proxy server at 127.0.0.1:45527 just failed. Make sure that the proxy server is up and running.
```
and Tor Browser has no idea this is happening, or that trying to use Tor is now hopeless.
We should figure out something smarter that Tor should do in this situation. Perhaps it should exit, forcing the user to notice? Perhaps it should emit an event that Tor Browser picks up on? Maybe we have an even better idea?Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/33666Investigate Snowflake proxy failures2020-06-13T18:21:49ZCecylia BocovichInvestigate Snowflake proxy failuresSometimes a client will get a useless proxy from the broker. At times this happens occasionally, and at times more often. It could be a NAT problem.Sometimes a client will get a useless proxy from the broker. At times this happens occasionally, and at times more often. It could be a NAT problem.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/21314snowflake-client needs to stop using my network when I'm not giving it requests2020-06-13T18:21:44ZRoger Dingledinesnowflake-client needs to stop using my network when I'm not giving it requestsI started my Tor Browser, and told it to use snowflake, and it did. Then I changed my mind and told it to stop using snowflake. Now, apparently there's a bug in Tor where Tor is supposed to kill snowflake-client when there are no more br...I started my Tor Browser, and told it to use snowflake, and it did. Then I changed my mind and told it to stop using snowflake. Now, apparently there's a bug in Tor where Tor is supposed to kill snowflake-client when there are no more bridge lines in my torrc that want to use it. But ignoring that Tor bug, snowflake-client should also be defensive for me. Right now it is touching the broker every 10 seconds, looking for a snowflake, even though it is getting no requests. That can't be good for scalability or for the broker or for the users.https://gitlab.torproject.org/legacy/trac/-/issues/33336Trial deployment of Snowflake with Turbo Tunnel2020-06-13T18:21:37ZDavid Fifielddcf@torproject.orgTrial deployment of Snowflake with Turbo TunnelWe now have a [turbotunnel branch](https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel) of Snowflake that uses an inner transport protocol to migrate session across multiple proxies.
* https://lists.torproject.org/pi...We now have a [turbotunnel branch](https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel) 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 [backward-compatible](https://lists.torproject.org/pipermail/anti-censorship-team/2020-February/000062.html) 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 [basically equivalent in features](https://github.com/net4people/bbs/issues/14), I haven't done much to compare them as to performance. kcp-go is more mature and stable, while quic-go [adds fewer dependencies to the Tor Browser build](https://lists.torproject.org/pipermail/anti-censorship-team/2020-February/000069.html).
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.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25429Need something better than client's `checkForStaleness`2020-06-13T18:20:17ZArlo BreaultNeed something better than client's `checkForStaleness`If no message has been received on the datachannel on the client for `SnowflakeTimeout` (30 seconds), `checkForStaleness` closes the connection. The comment says this is to,
> // Prevent long-lived broken remotes.
but there's no hear...If no message has been received on the datachannel on the client for `SnowflakeTimeout` (30 seconds), `checkForStaleness` closes the connection. The comment says this is to,
> // Prevent long-lived broken remotes.
but there's no heartbeat at this level of abstraction so the connection is constantly being reset anytime the user pauses their activity (for example, to read a webpage).
This greatly exacerbated #21312Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/legacy/trac/-/issues/19569DataChannel-only libwebrtc2020-06-13T18:19:27ZArlo BreaultDataChannel-only libwebrtcEquivalently, https://github.com/keroserene/go-webrtc/issues/10
This is my first working patch,
https://gist.github.com/arlolra/f43b3e980e88a534b61c7a5ef3903124
It applies against f33698296719f956497d2dbff81b5080864a8804, which was HEA...Equivalently, https://github.com/keroserene/go-webrtc/issues/10
This is my first working patch,
https://gist.github.com/arlolra/f43b3e980e88a534b61c7a5ef3903124
It applies against f33698296719f956497d2dbff81b5080864a8804, which was HEAD of branch-heads/52 when I started, and the current build of go-webrtc (see https://github.com/keroserene/go-webrtc/pull/42)
To use it,
```
gclient sync -r f33698296719f956497d2dbff81b5080864a8804
cd src/
git am the.patch
GYP_DEFINES="include_tests=0 include_examples=0" python webrtc/build/gyp_webrtc webrtc/api/api.gyp
ninja -C out/Release
```
Then do the usual concatenating stuff. It's important to note here that the patch ifdefs in a few headers, so be sure to update those or you'll get some segfaults.
All the go-webrtc / snowflake tests passed, and I was able to bootstrap a tor client with it.
I was also able to make this change to `go-webrtc/webrtc-darwin-amd64.pc`,
```
- -framework AppKit \
- -framework CoreAudio \
- -framework AudioToolbox
+ -framework AppKit
```
This trimmed the build by about 10MB, and I assume with a little more work can be improved.Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/legacy/trac/-/issues/19315Include libwebrtc license files in bundle2020-06-13T18:19:27ZDavid Fifielddcf@torproject.orgInclude libwebrtc license files in bundleThere are a ton of licenses for all the chromium files; maybe we can copy from the [Debian copyright file](https://web.archive.org/web/20190516032310/https://metadata.ftp-master.debian.org/changelogs/main/c/chromium/chromium_74.0.3729.10...There are a ton of licenses for all the chromium files; maybe we can copy from the [Debian copyright file](https://web.archive.org/web/20190516032310/https://metadata.ftp-master.debian.org/changelogs/main/c/chromium/chromium_74.0.3729.108-1_copyright).https://gitlab.torproject.org/legacy/trac/-/issues/27827Reproducibility issue of the snowflake osx64 build2020-06-13T18:19:15ZboklmReproducibility issue of the snowflake osx64 buildThe build of Snowflake for MacOS is often producing the same result, but not always.
Arthur has been rebuilding Snowflake 8 times, with 4 different results:
https://gist.github.com/arthuredelstein/73860df088c565ea0b2ca6eef586063a
```
fi...The build of Snowflake for MacOS is often producing the same result, but not always.
Arthur has been rebuilding Snowflake 8 times, with 4 different results:
https://gist.github.com/arthuredelstein/73860df088c565ea0b2ca6eef586063a
```
fish script:
for x in (seq 8)
rm out/snowflake/snowflake-6077141f4aff-osx-x86_64-3b578d.tar.gz
./rbm/rbm build snowflake --target alpha --target torbrowser-osx-x86_64
tar xvf out/snowflake/snowflake-6077141f4aff-osx-x86_64-3b578d.tar.gz
echo (sha256sum ./Contents/MacOS/Tor/PluggableTransports/snowflake-client
end
Results:
b060b42cfd0c8fb2781dbb0fd45d42804dbb414473fec0597d9c2fb7d6d12aa8 ./Contents/MacOS/Tor/PluggableTransports/snowflake-client
1ee0dd2a0b228988e22c663d62b696b23a6ac48dc742a57dfa8f854aa3992bc3 ./Contents/MacOS/Tor/PluggableTransports/snowflake-client
22557c38d913e478e480dd3581efc00019fe2989c4273d9207f1719c34b6e399 ./Contents/MacOS/Tor/PluggableTransports/snowflake-client
22557c38d913e478e480dd3581efc00019fe2989c4273d9207f1719c34b6e399 ./Contents/MacOS/Tor/PluggableTransports/snowflake-client
1ee0dd2a0b228988e22c663d62b696b23a6ac48dc742a57dfa8f854aa3992bc3 ./Contents/MacOS/Tor/PluggableTransports/snowflake-client
1ee0dd2a0b228988e22c663d62b696b23a6ac48dc742a57dfa8f854aa3992bc3 ./Contents/MacOS/Tor/PluggableTransports/snowflake-client
1ee0dd2a0b228988e22c663d62b696b23a6ac48dc742a57dfa8f854aa3992bc3 ./Contents/MacOS/Tor/PluggableTransports/snowflake-client
6d008bc7d29e8543608491b67d4b11da7bd6589741d9f52ac5fd50dd39d84f29 ./Contents/MacOS/Tor/PluggableTransports/snowflake-client
```https://gitlab.torproject.org/legacy/trac/-/issues/25723Multiplex - one client splits traffic across multiple proxies2020-06-13T18:19:04ZDavid Fifielddcf@torproject.orgMultiplex - one client splits traffic across multiple proxiesThis is the dual of #25601.
It would be a great feature if a client could be connected to multiple snowflake proxies at once, and split traffic across all of them. Like the [Conflux](http://cacr.uwaterloo.ca/techreports/2013/cacr2013-16...This is the dual of #25601.
It would be a great feature if a client could be connected to multiple snowflake proxies at once, and split traffic across all of them. Like the [Conflux](http://cacr.uwaterloo.ca/techreports/2013/cacr2013-16.pdf) proposal for Tor. It would be a hedge against getting assigned a single slow proxy.
This would require interposing some kind of sequencing and reliability layer, with possible retransmissions.
A potential benefit for privacy is that an individual snowflake proxy only sees a subset of a client's traffic flow.
However, instantly making _N_ WebRTC connections is a tell for traffic classification.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25483Windows reproducible build of snowflake2020-06-13T18:18:51ZArlo BreaultWindows reproducible build of snowflakeBreaking this out from https://trac.torproject.org/projects/tor/ticket/19001#comment:36, where dcf wrote,
> I pushed some preliminary code for getting started with a windows reproducible build.
> https://gitweb.torproject.org/user/dcf...Breaking this out from https://trac.torproject.org/projects/tor/ticket/19001#comment:36, where dcf wrote,
> I pushed some preliminary code for getting started with a windows reproducible build.
> https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/log/?h=snowflake-windows&id=0f48dc9e1904fa0643576fc8dcf3db50a4d2f959
>
> It doesn't work yet; after `./mkbundle-windows.sh versions.alpha`, it eventually fails with:
> {{{
> + /home/ubuntu/build/webrtc/src/out_bootstrap/gn gen out/Release '--args= target_os="win" target_cpu="x86" is_debug=false treat_warnings_as_errors=false is_component_build=false is_clang=true use_sysroot=false clang_use_chrome_plugins=false clang_base_path="/home/ubuntu/build/clang" rtc_include_opus=false rtc_include_ilbc=false rtc_include_internal_audio_device=false rtc_include_tests=true'
> ERROR at //build/config/BUILDCONFIG.gn:239:3: Assertion failed.
> assert(target_os == host_os, "Win cross-compiles only work on win hosts.")
> ^-----
> Win cross-compiles only work on win hosts.
> }}}
> But at this point one can ssh into the build VM and start debugging the build failures.
Some further notes from what we've discovered so far.
* https://chromium.googlesource.com/chromium/src/+/master/docs/win_cross.md says that we need to add `target_os = ['win']` to our `.gclient` file before calling `gclient sync` to get some additional deps.
* https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/win_toolchain/README.md says that Googlers have access to the necessary toolchain, but we don't.
* https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/win_toolchain/package_from_installed.py points to a method of creating it from a fresh VM. Presumably we can use https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ and the community version of Visual Studio (steps to reproduce will follow)Cecylia BocovichCecylia Bocovich