Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2023-07-18T00:47:30Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40262Deploy snowflake-server for QueuePacketConn buffer reuse fix (#40260)2023-07-18T00:47:30ZDavid Fifielddcf@torproject.orgDeploy snowflake-server for QueuePacketConn buffer reuse fix (#40260)#40260 describes a buffer reuse error in `QueuePacketConn` resulting from #40199.
!140 promises to fix it.
After merging !140, deploy to the bridges and restart.
- [x] snowflake-01
- [x] snowflake-02
/cc @cohosh @linus#40260 describes a buffer reuse error in `QueuePacketConn` resulting from #40199.
!140 promises to fix it.
After merging !140, deploy to the bridges and restart.
- [x] snowflake-01
- [x] snowflake-02
/cc @cohosh @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40261Standalone proxy: use standard notation of "inbound" and "outbound"2023-06-28T09:21:33ZitchyonionStandalone proxy: use standard notation of "inbound" and "outbound"Right now, the standalone proxy increment the "outbound" count when it [receives messages from SF client](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L414) and incre...Right now, the standalone proxy increment the "outbound" count when it [receives messages from SF client](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L414) and increment the "inbound" count when it [writes to the relay](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L296). It will be better to use the standard "inbound" and "outbound" notation to include everything regardless of traffic logic because:
1. proxy runners might have a limit of inbound/outbound traffic imposed by their ISP or hosting service provider, and they will be using the standard way to count
2. it's less confusing and more consistent with everything else
3. traffic logic shouldn't matter to proxy runnershttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40260Weird KCP packets received by the client2023-09-25T19:36:14ZCecylia BocovichWeird KCP packets received by the clientWe were notified by @hazae41 of some suspicious looking kcp traffic traffic arriving at the client. This traffic looks like it belongs to KCP sessions that do not correspond to the client's own KCP sessions.
I'm in the process of trying...We were notified by @hazae41 of some suspicious looking kcp traffic traffic arriving at the client. This traffic looks like it belongs to KCP sessions that do not correspond to the client's own KCP sessions.
I'm in the process of trying to reproduce this. Here is the patch they used to see the contents of the KCP packets:
<details>
<summary> kcp library logging patch </summary>
```diff
diff --git a/readloop.go b/readloop.go
index 697395a..1d8e17b 100644
--- a/readloop.go
+++ b/readloop.go
@@ -1,6 +1,7 @@
package kcp
import (
+ "log"
"sync/atomic"
"github.com/pkg/errors"
@@ -11,6 +12,7 @@ func (s *UDPSession) defaultReadLoop() {
var src string
for {
if n, addr, err := s.conn.ReadFrom(buf); err == nil {
+ log.Println("kcp <- ", buf)
// make sure the packet is from the same source
if src == "" { // set source address
src = addr.String()
```
</details>
and the following smux patch:
<details>
<summary> smux library logging patch </summary>
```diff
diff --git a/session.go b/session.go
index bc56066..1fe1122 100644
--- a/session.go
+++ b/session.go
@@ -96,7 +96,7 @@ func newSession(config *Config, conn io.ReadWriteCloser, client bool) *Session {
s.chProtoError = make(chan struct{})
if client {
- s.nextStreamID = 1
+ s.nextStreamID = 5
} else {
s.nextStreamID = 0
}
```
</details>
They report seeing smux headers that have a streamid of 3 regardless of the above change that starts stream ids at 5, and seeing kcp headers that do not contain recognizable kcp conv ids followed by a stream id of 3 and a TLS application packet (despite the fact that new KCP sessions should always contain a TLS handshake first since they represent a new OR conn).Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40259Make nf_conntrack changes persistent2023-04-25T15:13:40ZDavid Fifielddcf@torproject.orgMake nf_conntrack changes persistentInvestigating the [loss of users from Iran](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115#note_2883298)
and the [increase of users from Russia that only affected snowflake-02](https://gitlab.torproject.org/tpo/anti-...Investigating the [loss of users from Iran](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115#note_2883298)
and the [increase of users from Russia that only affected snowflake-02](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/131#note_2883300)
that happened in the second half of February 2023,
I discovered that the [increased nf_conntrack table size](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide?version_id=a7bcf0502102bd8d820f590bc9856a0a738a2225#general-system-setup)
from #40239 had not taken effect since
the bridges were rebooted on 2023-02-16 for #40253.
```
root@snowflake-01:~# date -u --iso=sec
2023-03-04T07:13:32+00:00
root@snowflake-01:~# cat /proc/sys/net/netfilter/nf_conntrack_{count,max,buckets}
186671
262144
65536
```
```
root@snowflake-02:~# date -u --iso=sec
2023-03-04T07:36:45+00:00
root@snowflake-02:~# cat /proc/sys/net/netfilter/nf_conntrack_{count,max,buckets}
21155
262144
65536
```
The default settings were supposed to be overridden
by /etc/sysctl.d/nf_conntrack.conf, which is loaded during boot by sysctl:
```
root@snowflake-01:~# cat /etc/sysctl.d/nf_conntrack.conf
net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_buckets = 524288
```
I think the problem is that the sysctl settings are made
before the nf_conntrack module is first loaded, so they have no effect,
as the [sysctl.d(5)](https://manpages.debian.org/bullseye/systemd/sysctl.d.5.en.html#CONFIGURATION_FORMAT)
man page cautions:
> Many sysctl parameters only become available when certain kernel modules are loaded. Modules are usually loaded on demand, e.g. when certain hardware is plugged in or network brought up. This means that [systemd-sysctl.service(8)](https://manpages.debian.org/bullseye/systemd/systemd-sysctl.service.8.en.html) which runs during early boot will not configure such parameters if they become available after it has run. To set such parameters, it is recommended to add an [udev(7)](https://manpages.debian.org/bullseye/udev/udev.7.en.html) rule to set those parameters when they become available. Alternatively, a slightly simpler and less efficient option is to add the module to [modules-load.d(5)](https://manpages.debian.org/bullseye/systemd/modules-load.d.5.en.html), causing it to be loaded statically before sysctl settings are applied (see example below).
The workaround, as the man page suggests,
is to add `nf_conntrack` to /etc/modules to make it be loaded earlier in the boot sequence,
or add a udev rule to re-load the `net.netfilter` sysctl settings
when nf_conntrack is loaded.
* https://github.com/systemd/systemd/issues/1113#issuecomment-138051408
* https://serverfault.com/a/676721
* https://github.com/coreos/bugs/issues/785
I've re-started the [conntrack.sh script](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40239#note_2864515)
to track `nf_conntrack_count` over time.
I will let it run for a couple of days to get a baseline,
then I will increase the nf_conntrack limits again
to see if it has an effect on usership.
Then, I will try one of the above workarounds to make the change actually persistent this time.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40258Resynchronization with Upsteamed Remove HelloVerify countermeasure2023-04-06T13:05:39ZshelikhooResynchronization with Upsteamed Remove HelloVerify countermeasureAs of https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249, we have finished upstreaming Remove HelloVerify countermeasure changes to upstream.
We should try to resynchronize our dependency wit...As of https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249, we have finished upstreaming Remove HelloVerify countermeasure changes to upstream.
We should try to resynchronize our dependency with upstream.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40257Client: add config option to filter out IP address used for ICE2023-06-21T09:14:52ZitchyonionClient: add config option to filter out IP address used for ICEFrom https://www.rfc-editor.org/rfc/rfc8445#section-19.1
> ICE implementations where
such issues can arise are RECOMMENDED to provide a programmatic or
user interface that provides control over which network interfaces
are used ...From https://www.rfc-editor.org/rfc/rfc8445#section-19.1
> ICE implementations where
such issues can arise are RECOMMENDED to provide a programmatic or
user interface that provides control over which network interfaces
are used to generate candidates.
In some cases, providing an IP address as candidate could also save one STUN connection. While we still use STUN servers to determinte NAT type on the client side, this could be helpful when [censors are targeting STUN servers](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40024#note_2829127).
This came up as I was researching https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40108https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40256Standalone Snowflake proxy for Microsoft Windows2023-03-07T14:55:51ZRahim RollinsStandalone Snowflake proxy for Microsoft Windows> If you would like to run a command-line version of the Snowflake proxy on your **desktop** or server, see our guide for running a Snowflake standalone proxy.
[The "Standalone Snowflake proxy" page](https://community.torproject.org/rel...> If you would like to run a command-line version of the Snowflake proxy on your **desktop** or server, see our guide for running a Snowflake standalone proxy.
[The "Standalone Snowflake proxy" page](https://community.torproject.org/relay/setup/snowflake/standalone/) provides instructions for installing and configuring the CLI version of Snowflake proxy on Debian, Fedora, Arch Linux, FreeBSD and Ubuntu. However, most users (working on Windows) would be able to help other users bypass censorship without having to keep the browser running. Now this possibility is impossible for them. At least for such volunteers there is not even an instruction, unlike users of the operating systems listed above.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40255snowflake-02: increase number of tor instances from 4 to 122023-02-17T03:15:20ZDavid Fifielddcf@torproject.orgsnowflake-02: increase number of tor instances from 4 to 12The idea is that snowflake-02 will soon be handling a roughly equal amount of traffic as snowflake-01, which currently runs 12 instances.The idea is that snowflake-02 will soon be handling a roughly equal amount of traffic as snowflake-01, which currently runs 12 instances.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40254Nil Pointer Crash when Initializing Snowflake Proxy2023-03-07T15:49:08ZbimNil Pointer Crash when Initializing Snowflake Proxyhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L568
Line 568 ought to be moved below 589 - if the event dispatcher isn't set the proxy will crash. I came across this b...https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L568
Line 568 ought to be moved below 589 - if the event dispatcher isn't set the proxy will crash. I came across this bumping snowflake to the the latest release in Orbot via our IPtProxy wrapper library.
https://github.com/tladesignz/IPtProxy/issues/39
For now, we simply just init'd our own event dispatcher instance to sidestep the crash.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40253Restart snowflake bridges for haproxy CVE-2023-0056, CVE-2023-257252023-05-25T15:04:32ZDavid Fifielddcf@torproject.orgRestart snowflake bridges for haproxy CVE-2023-0056, CVE-2023-25725https://security-tracker.debian.org/tracker/DSA-5348-1
https://lists.debian.org/debian-security-announce/2023/msg00037.html
> Two vulnerabilities were discovered in HAProxy, a fast and reliable load
> balancing reverse proxy, which may ...https://security-tracker.debian.org/tracker/DSA-5348-1
https://lists.debian.org/debian-security-announce/2023/msg00037.html
> Two vulnerabilities were discovered in HAProxy, a fast and reliable load
> balancing reverse proxy, which may result in denial of service, or
> bypass of access controls and routing rules via specially crafted
> requests.
>
> For the stable distribution (bullseye), these problems have been fixed in
> version 2.2.9-2+deb11u4.
>
> We recommend that you upgrade your haproxy packages.
https://ubuntu.com/security/notices/USN-5869-1
> HAProxy could allow unintended access to network services.
>
> The problem can be corrected by updating your system to the following package versions:
>
> Ubuntu 20.04
>
> [haproxy - 2.0.29-0ubuntu1.3](https://launchpad.net/ubuntu/+source/haproxy/2.0.29-0ubuntu1.3)
- [x] snowflake-01
- [x] snowflake-02
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40252Standalone proxy probetest Wiki inconsistency and implementation details2023-03-07T18:13:49ZitchyonionStandalone proxy probetest Wiki inconsistency and implementation details1. Our [Wiki](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/NAT-matching#determining-nat-behaviour) states that:
> We determine the NAT behaviour of clients by using the tricks in [RFC 5780](ht...1. Our [Wiki](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/NAT-matching#determining-nat-behaviour) states that:
> We determine the NAT behaviour of clients by using the tricks in [RFC 5780](https://tools.ietf.org/html/rfc5780) ... For standalone proxies written in Go, we use the same method.
Which is not true since we switched to probetest https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/commit/00f8f85f412878c2066fcb5d3f4739e50912a925
Cecylia linked the issue for the change: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40013. I will update the Wiki.
2. Right now we are [logging the SDP offer](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L676) used for probetest, which might be misleading because before looking into this in detail I always thought we were logging the SDP candidates used for WebRTC connection. Does this help the user in any way or is simplying logging the resultant NAT type enough? Some options to consider:
- keep the same logging, but made it extra clear that this is only used for probetest, not peer connection
- log SDP candidates for WebRTC. I think this would be helpful for debugging, but could produce much more logs
- log both
- [x] Update Wiki with reason to use probetest
- [x] Research on whether we should respect proxy options in probetest
- [x] Decide what to logitchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40251Analysis of speed deficiency of Snowflake in China, 2023 Q12024-03-21T20:45:13ZshelikhooAnalysis of speed deficiency of Snowflake in China, 2023 Q1We are currently observing an increase of snowflake bootstrap failure. This ticket document our investigation of this incident.
As we can observe from the vantage point test [result](https://gitlab.torproject.org/tpo/anti-censorship/con...We are currently observing an increase of snowflake bootstrap failure. This ticket document our investigation of this incident.
As we can observe from the vantage point test [result](https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/bridgestatus/-/blob/39c4d2a143c2ce43ffb1cbf39bf18f26d7ba49c7/recentResult_cn), the bootstrap percentage is often more than 10 and less than 100 as a result of poor connection speed.
In order to measure the packet loss rate at the vantage points a few [scripts](https://gist.github.com/xiaokangwang/14ac48ef9fc2ce8dd04f92ed9c0928de) are used to calculate the packet loss rate from packet capture file, here is the result:
```
snowflake-probe-0-eth0.pcap:TOTAL 3027, RECV 2702, LOSS RATE .107
snowflake-probe-1-eth0.pcap:TOTAL 3406, RECV 3169, LOSS RATE .069
snowflake-probe-2-eth0.pcap:TOTAL 2896, RECV 2294, LOSS RATE .207
snowflake-probe-3-eth0.pcap:TOTAL 2883, RECV 2652, LOSS RATE .080
snowflake-probe-4-eth0.pcap:TOTAL 2696, RECV 2514, LOSS RATE .067
snowflake-probe-5-eth0.pcap:TOTAL 847, RECV 669, LOSS RATE .210
snowflake-probe-6-eth0.pcap:TOTAL 1855, RECV 1692, LOSS RATE .087
snowflake-probe-7-eth0.pcap:TOTAL 76, RECV 284, LOSS RATE -2.736 (invalid, more than one dtls connection)
snowflake-probe-8-eth0.pcap:TOTAL 1577, RECV 1255, LOSS RATE .204
snowflake-probe-9-eth0.pcap:TOTAL 1449, RECV 1166, LOSS RATE .195
```
As we can see snowflake's bootstrap percentage is regularly impacted by packet loss rate. We can either make snowflake more resistant to packet loss or improve matching process to reduce packet loss.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40250Broker side channel fallback mechanism2023-10-03T18:22:22Zmeskiomeskio@torproject.orgBroker side channel fallback mechanismCurrently we are using domain fronting as our main side channel to connect to the broker, but amp cache is also supported. When the domain fronting is blocked (like in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115) ...Currently we are using domain fronting as our main side channel to connect to the broker, but amp cache is also supported. When the domain fronting is blocked (like in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115) it will be useful to automatically fall back to amp cache.
This would be really nice to be encoded in the bridge line, but we are already near the limit on size for the bridge line.
The snowflake client could use the bridgeline provided side channel configuration and if that fails try to use the one provided by the flags passed to the binary on launch (by `ClientTransportPlugin`). This has the problem that those flags will not be distributed by Circumvention Settings and needs some coordination with the different tor applications to have the same defaults everywhere. We might need to think how snowflake library users will use this fallback (or if they need to implement it themselves).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249Upstreaming Remove HelloVerify countermeasure2023-03-03T11:45:36ZshelikhooUpstreaming Remove HelloVerify countermeasureWe have already released a version of snowflake with [Remove HelloVerify](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/134) [Orig](https://gitlab.torproject.org/tpo/anti-censorship/plu...We have already released a version of snowflake with [Remove HelloVerify](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/134) [Orig](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/131) countermeasure against Russia's censorship of snowflake. However, as we are currently applying the changes as a series of patch in the forked repo, this situation isn't ideal if that means we need to constantly rebase and maintain this fork.
Thus, we are currently seeking to upstream this change.
Changes to be upstreamed:
1. [DTLS](https://github.com/xiaokangwang/dtls/tree/dev-skiphelloverify) -> [Github Pull Request](https://github.com/pion/dtls/pull/513)
2. [WebRTC](https://github.com/xiaokangwang/webrtc/tree/dev-skiphelloverify) -> [Github Pull Request](https://github.com/pion/webrtc/pull/2407)
See Also: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/637shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248(More) Distributed servers2023-09-17T15:22:17ZWofWcawofwca@protonmail.com(More) Distributed serversStanding on the shoulders of #40129, I propose the following.
This should allow clients to connect to _any_ accordingly set-up bridge (or even a regular entry node) they choose (say, distributed through moat, or any other channels), eli...Standing on the shoulders of #40129, I propose the following.
This should allow clients to connect to _any_ accordingly set-up bridge (or even a regular entry node) they choose (say, distributed through moat, or any other channels), eliminating the need of maintaining several centralized, set-in-stone Snowflake servers (bridges), which, mind, [costs quite a bit to operate, upgrade](https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations) and optimize.
What the parties need to become capable of doing so all this can work:
* Severs (a.k.a. bridges (or relays)): set up a Tor bridge, and set up a Snowflake server coupled with it, with a dedicated port (say, `7901` see #40166)
* Proxies: set [allowed relay pattern](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/7db2568448fed6d883b33db11e3a497c69f1748f/proxy/main.go#L28) to `*:7901` (any host, at port `7901`, see #40166)
* Clients: choose a server (bridge) that is set up accordingly, set up the Snowflake client to forward connections to that server, then connect Tor to it as a bridge.
From what I see, it should be quite possible upgrade all the current bridges ([or better public relays](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248#note_2875147)) this way (maybe even by embedding a Snowflake server in the Tor relay package), or upgrade bridge distribution mechanisms with a way to filter bridges by whether they accept Snowflake connection (like it is with obfs4). At which point it should become possible to let the Tor client choose the entry node itself, not manually specify a bridge you want (ahh, just remembered that it needs to learn the addresses of the nodes first. Maybe it can connect to directory authorities through Snowflake as well).
This idea is a based on these other ideas: #40166, #40168.
A step further would be to combine the server (bridge) and the proxy on one machine, but I haven't thought about it enough (see #40165, for example).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40247Can't open tab/icon won't stay in menu bar (Chrome)2023-01-17T15:07:17ZcypherpunksCan't open tab/icon won't stay in menu bar (Chrome)I downloaded the extension into Chrome. The icon appears, but as soon as I click on the explanation box, the icon disappears from the menu bar, so I can't open a tab. This happens even though the extension shows as active on the extens...I downloaded the extension into Chrome. The icon appears, but as soon as I click on the explanation box, the icon disappears from the menu bar, so I can't open a tab. This happens even though the extension shows as active on the extensions page.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40246Restart snowflake-server on snowflake-01 with num-turbotunnel=42023-07-18T00:47:29ZDavid Fifielddcf@torproject.orgRestart snowflake-server on snowflake-01 with num-turbotunnel=4We are hitting a performance ceiling at about 475 MiB/s TX. The CPUs are not fully saturated: they are averaging about 87%. Currently we have `num-turbotunnel=2`. I want to try increasing this to `num-turbotunnel=4` to see if the KCP sta...We are hitting a performance ceiling at about 475 MiB/s TX. The CPUs are not fully saturated: they are averaging about 87%. Currently we have `num-turbotunnel=2`. I want to try increasing this to `num-turbotunnel=4` to see if the KCP state machines are again a bottleneck.
Cf. #40200/!119 which effectively changed from `num-turbotunnel=1` to `num-turbotunnel=2`.
/cc @linus
![snowflake-01 bandwidth at eno1](/uploads/e50170475883f71f3d3306118dcbd2cd/snowflake-01-bw-20230107.png)David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40245WebRTC, but obfs4 instead of DTLS2023-01-11T16:08:39ZWofWcawofwca@protonmail.comWebRTC, but obfs4 instead of DTLS...or any other protocol.
This is very similar to #40244, which I created while researching this topic.
As we know, WebRTC data channels works like this: SCTP transport inside DTLS transport, inside ICE transport. Now, why do we have t......or any other protocol.
This is very similar to #40244, which I created while researching this topic.
As we know, WebRTC data channels works like this: SCTP transport inside DTLS transport, inside ICE transport. Now, why do we have to constrain ourselves to DTLS when we can replace it with any other protocol? The Pion library is super modular and this seems very possible: https://pkg.go.dev/github.com/pion/ice .
Advantages (compared to regular Snowflake):
* As resistant to DPI as the protocol you choose (say, obfs4) (unlike DTLS, which some censors are willing to block ([1](https://matrix.to/#/!jRxGDjXjyTpKaJypgV:matrix.org/$xLK7T6CjV9ZKA4WdxbM2EefCzAWUT_ovIGblM3e2H54?via=matrix.org&via=freitrix.de&via=1312.media), [2](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030))).
Disadvantages:
* It's not actually WebRTC, so [the browser extension](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext) won't be able to implement it.
What it does NOT solve, compared to regular Snowflake:
* The blocking of STUN. IP-, port- and DPI-based.
TODO:
* Think if it's worth to implement based on what it doesn't solve.
* Research STUNS (STUN over TLS) (as a censorship-resistant version of regular STUN).
* Research if it can work with STUN completely blocked for the client.
The creator of Pion [said](https://gophers.slack.com/archives/CAK2124AG/p1671994856141969) that he can help sketch up such a protocol.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40244TLS instead of DTLS (TLS Candidates for ICE)2023-01-11T12:28:49ZWofWcawofwca@protonmail.comTLS instead of DTLS (TLS Candidates for ICE)I was thinking about censors blocking DTLS, partially or completely (e.g. https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030), making it impossible to initiate a WebRTC p2p connection, so I thought maybe...I was thinking about censors blocking DTLS, partially or completely (e.g. https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030), making it impossible to initiate a WebRTC p2p connection, so I thought maybe another protocol could be used. I reached out to the creator of the Pion library (the one that Snowflake uses) and he [told](https://gophers.slack.com/archives/CAK2124AG/p1671995560491059) me that [this draft](https://datatracker.ietf.org/doc/html/draft-martinsen-ice-tls-candidates-00) is probably what I want.
So, the idea: peers connect to each other with TLS, making DPI's job harder, because TLS is probably the last thing censors want to block, unlike DTLS, which offers relatively low collateral IMO.
Sean also said that it might already be implemented in libwebrtc, and that he's willing to add it to Pion.
So, I suggest to evaluate this idea and provide the Pion team the assistance we can offer, if we think that it's a good idea.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40243fix(proxy): memory leak2024-03-21T20:02:09ZWofWcawofwca@protonmail.comfix(proxy): memory leakAccording to [this forum post](https://forum.torproject.net/t/snowflake-proxy-connections-limit/4113/8?u=wofwca) and the one below it, Snowflake proxy appears to start at 100MB RAM consumption and goes up to 1.5GB.
A fix would be nice, ...According to [this forum post](https://forum.torproject.net/t/snowflake-proxy-connections-limit/4113/8?u=wofwca) and the one below it, Snowflake proxy appears to start at 100MB RAM consumption and goes up to 1.5GB.
A fix would be nice, but a catch-all alternative would be to automatically restart the proxy every so often. Maybe add the instructions here https://community.torproject.org/relay/setup/snowflake/standalone/.
UPD: It's probably a duplicate of #40154.