Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2023-10-25T15:42:23Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40273Automated Testing Script for Potential Domain Fronting Domains2023-10-25T15:42:23ZshelikhooAutomated Testing Script for Potential Domain Fronting DomainsIn order to make it easier to deal with blocking of domain fronting domains that is being observed in Iran, Russia, and possibly China, a [script](https://gist.github.com/xiaokangwang/3e6b7ca99a30b13f82ed5fe6bf8d8f43) was written to auto...In order to make it easier to deal with blocking of domain fronting domains that is being observed in Iran, Russia, and possibly China, a [script](https://gist.github.com/xiaokangwang/3e6b7ca99a30b13f82ed5fe6bf8d8f43) was written to automate the screening of domain name for domain fronting.
The following domain name was evaluated to be potentially useable for domain fronting. We should try to reduce solo reliance on cdn.sstatic.net with a fronting domain rotation system to reduce the chance any of them get blocked.
See also: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40068 , https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/123shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40272go snowflake picks 'restricted' but stun-nat-behaviour picked endpoint indepe...2023-05-16T18:32:06ZRoger Dingledinego snowflake picks 'restricted' but stun-nat-behaviour picked endpoint independentOn my new Debian bookworm-rc2, I installed the stun-nat-behaviour testing tool:
```
$ go install github.com/pion/stun/cmd/stun-nat-behaviour@latest
go: downloading github.com/pion/stun v0.5.2
go: downloading github.com/pion/dtls/v2 v2.2....On my new Debian bookworm-rc2, I installed the stun-nat-behaviour testing tool:
```
$ go install github.com/pion/stun/cmd/stun-nat-behaviour@latest
go: downloading github.com/pion/stun v0.5.2
go: downloading github.com/pion/dtls/v2 v2.2.6
go: downloading github.com/pion/transport/v2 v2.2.0
go: downloading golang.org/x/crypto v0.5.0
go: downloading github.com/pion/udp/v2 v2.0.1
$ cd go/bin/
$ ./stun-nat-behaviour
INFO: 2023/05/13 15:45:02 connecting to STUN server: stun.voip.blackberry.com:3478
INFO: 2023/05/13 15:45:02 Local address: 0.0.0.0:33731
INFO: 2023/05/13 15:45:02 Remote address: 20.15.169.7:3478
INFO: 2023/05/13 15:45:02 Mapping Test I: Regular binding request
INFO: 2023/05/13 15:45:02 Sending to 20.15.169.7:3478: (20 bytes)
INFO: 2023/05/13 15:45:03 Response from 20.15.169.7:3478: (92 bytes)
INFO: 2023/05/13 15:45:03 Error: NAT discovery feature not supported by this server
WARNING: 2023/05/13 15:45:03 NAT mapping behavior: inconclusive
INFO: 2023/05/13 15:45:03 connecting to STUN server: stun.voip.blackberry.com:3478
INFO: 2023/05/13 15:45:03 Local address: 0.0.0.0:60922
INFO: 2023/05/13 15:45:03 Remote address: 20.15.169.7:3478
INFO: 2023/05/13 15:45:03 Filtering Test I: Regular binding request
INFO: 2023/05/13 15:45:03 Sending to 20.15.169.7:3478: (20 bytes)
INFO: 2023/05/13 15:45:03 Response from 20.15.169.7:3478: (92 bytes)
WARNING: 2023/05/13 15:45:03 Error: NAT discovery feature not supported by this server
WARNING: 2023/05/13 15:45:03 NAT filtering behavior: inconclusive
$ ./stun-nat-behaviour -server stun.voipgate.com:3478
INFO: 2023/05/13 15:46:13 connecting to STUN server: stun.voipgate.com:3478
INFO: 2023/05/13 15:46:13 Local address: 0.0.0.0:52168
INFO: 2023/05/13 15:46:13 Remote address: 185.125.180.70:3478
INFO: 2023/05/13 15:46:13 Mapping Test I: Regular binding request
INFO: 2023/05/13 15:46:13 Sending to 185.125.180.70:3478: (20 bytes)
INFO: 2023/05/13 15:46:13 Response from 185.125.180.70:3478: (100 bytes)
INFO: 2023/05/13 15:46:13 Received XOR-MAPPED-ADDRESS: 173.56.90.221:52168
INFO: 2023/05/13 15:46:13 Mapping Test II: Send binding request to the other address but primary port
INFO: 2023/05/13 15:46:13 Sending to 185.125.180.71:3478: (20 bytes)
INFO: 2023/05/13 15:46:13 Response from 185.125.180.71:3478: (100 bytes)
INFO: 2023/05/13 15:46:13 Received XOR-MAPPED-ADDRESS: 173.56.90.221:52168
WARNING: 2023/05/13 15:46:13 => NAT mapping behavior: endpoint independent
INFO: 2023/05/13 15:46:13 connecting to STUN server: stun.voipgate.com:3478
INFO: 2023/05/13 15:46:13 Local address: 0.0.0.0:55735
INFO: 2023/05/13 15:46:13 Remote address: 185.125.180.70:3478
INFO: 2023/05/13 15:46:13 Filtering Test I: Regular binding request
INFO: 2023/05/13 15:46:13 Sending to 185.125.180.70:3478: (20 bytes)
INFO: 2023/05/13 15:46:14 Response from 185.125.180.70:3478: (100 bytes)
INFO: 2023/05/13 15:46:14 Filtering Test II: Request to change both IP and port
INFO: 2023/05/13 15:46:14 Sending to 185.125.180.70:3478: (28 bytes)
INFO: 2023/05/13 15:46:14 Response from 185.125.180.71:3479: (100 bytes)
WARNING: 2023/05/13 15:46:14 => NAT filtering behavior: endpoint independent
```
which sure makes me think that I successfully put my laptop in dmz mode behind my router. (As another data point, I can telnet in to services on this laptop from the outside).
But then running headless snowflake, I have
```
2023/05/13 19:57:49 snowflake-proxy 2.4.1
023/05/13 19:57:49 Proxy starting
2023/05/13 19:57:49 WebRTC: Created offer
2023/05/13 19:57:49 WebRTC: Set local description
2023/05/13 19:57:54 Offer: {"type":"offer","sdp":"v=0\r\no=- 4036211437389836707 1684007869 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 15:17:2D:41:43:C5:5D:D4:BD:B0:20:17:01:36:DB:0A:60:2B:E5:C4:A0:01:69:55:8F:77:71:17:72:F2:64:57\r\na=extmap-allow-mixed\r\na=group:BUNDLE 0\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 [scrubbed]\r\na=setup:actpass\r\na=mid:0\r\na=sendrecv\r\na=sctp-port:5000\r\na=ice-ufrag:TKUQqKORrkMnHIMw\r\na=ice-pwd:xLDVhUwJYEBnMGBjSgqOnluskGZjDVNg\r\na=candidate:1961522861 1 udp 2130706431 [scrubbed] 39181 typ host\r\na=candidate:1961522861 2 udp 2130706431 [scrubbed] 39181 typ host\r\na=end-of-candidates\r\n"}
2023/05/13 19:58:19 NAT Type measurement: unknown -> restricted = restricted
2023/05/13 19:58:19 NAT type: restricted
```
It sure looks like my snowflake is mistakenly calling me restricted when I'm not.
Did the newer go libs or something cause a regression where we think people like me are restricted?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40270Upgrade tor on snowflake-01 to 0.4.72024-01-22T15:19:37ZDavid Fifielddcf@torproject.orgUpgrade tor on snowflake-01 to 0.4.7snowflake-01 is currently running 0.4.5.16, which is end of life and may get removed from the network as early as next week:
* https://mastodon.social/@torproject/110256009579078954
* https://forum.torproject.net/t/tor-relays-psa-tor-0-4...snowflake-01 is currently running 0.4.5.16, which is end of life and may get removed from the network as early as next week:
* https://mastodon.social/@torproject/110256009579078954
* https://forum.torproject.net/t/tor-relays-psa-tor-0-4-5-reaches-end-of-life-eol-on-2023-02-15/6338
We need to upgrade to the 0.4.7 series.
This probably means switching to the [torproject.org deb repository](https://support.torproject.org/apt/)
rather than the Debian one.
But we need to be careful with this one and be ready to revert the upgrade quickly if necessary.
0.4.7.13 has new support for the [`IP_BIND_ADDRESS_NO_PORT`](https://forum.torproject.net/t/stable-release-0-4-5-16-and-0-4-7-13/6216)
socket option when using `OutboundBindAddress` in torrc.
(As [we currently do](tpo/anti-censorship/pluggable-transports/snowflake#40223)
as an attempted mitigation for anti-DDoS scripts at middle relays.)
Past analysis has shown that different processes interact badly with one another
when they bind sockets to a particular address and differ in whether they use `IP_BIND_ADDRESS_NO_PORT`:
a situation where everything uses the option is stable,
as is one where nothing uses the option;
but when one process uses `IP_BIND_ADDRESS_NO_PORT` and other do not,
the one that does may have its ephemeral ports "stolen" by those that do,
leading to `EADDRNOTAVAIL` errors.
It's why we
[force a source port range](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide?version_id=831f28b730b50c6656ada23ceee0abdad2a134db#haproxy)
in haproxy.cfg, because that has the side effect of disabling `IP_BIND_ADDRESS_NO_PORT` in haproxy.
If tor's new use of `IP_BIND_ADDRESS_NO_PORT` starts giving `EADDRNOTAVAIL`,
the immediate remedy is to downgrade to an old version.
Another possible quick fix is to remove `OutboundBindAddress` from the torrc files:
if the socket is not pre-bound, there's no problem.
The longer-term solution is to make the other programs on the system that bind to a source address
also use `EADDRNOTAVAIL`.
For haproxy it's easy, just remove the source port ranges from haproxy.cfg.
The other programs to worry about are
[snowflake-server](tpo/anti-censorship/pluggable-transports/snowflake!120)
and [extor-static-cookie](https://gitlab.torproject.org/dcf/extor-static-cookie/-/commit/61e0684e40f84aa57a032e3fa9b80d2d24986bde),
both of which
[bind to a random localhost IP address in a range](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide?version_id=831f28b730b50c6656ada23ceee0abdad2a134db#localhost-address-ranges)
to avoid running out of localhost 4-tuples
(which is a separate issue from the `IP_BIND_ADDRESS_NO_PORT` one).
Last time I checked, [`net.Dialer`](https://pkg.go.dev/net#Dialer)
with `LocalAddr` set did *not* use `IP_BIND_ADDRESS_NO_PORT`.
Background on the `IP_BIND_ADDRESS_NO_PORT` issue:
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40201#note_2868367
* https://forum.torproject.net/t/tor-relays-inet-csk-bind-conflict/5757/16
* https://blog.cloudflare.com/the-quantum-state-of-a-tcp-port/
snowflake-02 is already running 0.4.7.13 without any apparent ill effects,
though it is at only about 15% the clients of snowflake-01.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2023-05-10https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40269Snowflake web badge need 3rd-party cookies to run, which is unskilled in toda...2023-04-20T16:09:34ZsolidsSnowflake web badge need 3rd-party cookies to run, which is unskilled in today's most browsersToday most browser set the default setting to disable 3rd-party cookie, in Safari it's called "Prevent corss-site tracking", in Chromium-based browser it's called "Block third-party cookies". For example, the badge in website [relay.love...Today most browser set the default setting to disable 3rd-party cookie, in Safari it's called "Prevent corss-site tracking", in Chromium-based browser it's called "Block third-party cookies". For example, the badge in website [relay.love](https://relay.love) will show "Cookies are not enabled." in my browser and it's not possible to run without re-enabling 3rd-party cookies, which will allow tracking websites sneak in my privacy.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40268Restart snowflake bridges for haproxy CVE-2023-08362023-04-15T03:18:15ZDavid Fifielddcf@torproject.orgRestart snowflake bridges for haproxy CVE-2023-0836The vulnerability has to do with FastCGI, which we don't use.
https://security-tracker.debian.org/tracker/DSA-5388-1<br>
https://lists.debian.org/debian-security-announce/2023/msg00078.html
> An information leak vulnerability was disco...The vulnerability has to do with FastCGI, which we don't use.
https://security-tracker.debian.org/tracker/DSA-5388-1<br>
https://lists.debian.org/debian-security-announce/2023/msg00078.html
> An information leak vulnerability was discovered in HAProxy 2.1, 2.2 before 2.2.27, 2.3, 2.4 before 2.4.21, 2.5 before 2.5.11, 2.6 before 2.6.8, 2.7 before 2.7.1. There are 5 bytes left uninitialized in the connection buffer when encoding the FCGI_BEGIN_REQUEST record. Sensitive data may be disclosed to configured FastCGI backends in an unexpected way.
https://ubuntu.com/security/notices/USN-5994-1
> It was discovered that HAProxy incorrectly initialized certain connection
buffers. A remote attacker could possibly use this issue to obtain
sensitive information.
- [x] snowflake-01
- [x] snowflake-02
/cc @linus
Past haproxy upgrade issue: #40253.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2023-04-18https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40265Standalone proxy - error polling probe - 'certificate is not standards compli...2023-03-16T17:40:24ZMarkCStandalone proxy - error polling probe - 'certificate is not standards compliant'@meskio As requested.
Yesterday I updated one of my proxies after !136 completed. When I run the proxy it starts, then begins probetest, then immediately (and repeatedly) returns an error:
2023/03/16 00:45:47 error polling probe: x509:...@meskio As requested.
Yesterday I updated one of my proxies after !136 completed. When I run the proxy it starts, then begins probetest, then immediately (and repeatedly) returns an error:
2023/03/16 00:45:47 error polling probe: x509: “snowflake-broker.torproject.net” certificate is not standards compliant
2023/03/16 00:45:47 NAT type: unknown
2023/03/16 00:45:48 error polling broker: x509: “snowflake-broker.torproject.net” certificate is not standards compliant
2023/03/16 00:45:48 Error reading broker response: unexpected end of JSON input
2023/03/16 00:45:48 body:
2023/03/16 00:45:48 bad offer from broker
Here’s the log of the start up (note that the git pull in this sequence says 'already up to date' because I ran it a second time as a double check).
[proxy_error_polling_broker_-_03_15_23.txt](/uploads/e8d343dc26e784d66e59880530374774/proxy_error_polling_broker_-_03_15_23.txt)
On the previous build everything was functioning properly.
@itchyonion Might this result be caused by the bug you mentioned in #40108 yesterday?itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40264Add option to configure private snowflake proxy2023-03-28T18:36:08ZRendezvousPointAdd option to configure private snowflake proxyJust like obfs4 private bridges.Just like obfs4 private bridges.https://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/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/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/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/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/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/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.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40242Order of parameters may suppress other parameters2023-01-03T16:00:26Zn0tooseOrder of parameters may suppress other parameters### Steps to reproduce
- `snowflake-proxy -broker https://snowflake-broker.torproject.net/ -capacity 10 -nat-retest-interval 24h -relay wss://snowflake.bamsoftware.com/ -stun stun:stun.stunprotocol.org:3478 -summary-interval 1s -verbose...### Steps to reproduce
- `snowflake-proxy -broker https://snowflake-broker.torproject.net/ -capacity 10 -nat-retest-interval 24h -relay wss://snowflake.bamsoftware.com/ -stun stun:stun.stunprotocol.org:3478 -summary-interval 1s -verbose true -keep-local-addresses false` prints a summary once every second. Works fine.
- `snowflake-proxy -broker https://snowflake-broker.torproject.net/ -capacity 10 -keep-local-addresses false -nat-retest-interval 24h -relay wss://snowflake.bamsoftware.com/ -stun stun:stun.stunprotocol.org:3478 -summary-interval 1s -verbose true` prints a summary once every hour, ignoring the summary-interval argument. I wrote it that way, as that was the order in `snowflake-proxy -help`.
This was attempted in a Docker container running on Debian Bookworm.