Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2023-10-07T17:22:33Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40282Release tar.gz file is not available and "go build" possibly not work on armhf2023-10-07T17:22:33ZslrslrRelease tar.gz file is not available and "go build" possibly not work on armhfHello,
on 6.1.28+ armv7l GNU/Linux
$ cd /mnt/tmpfs;git clone https://git.torproject.org/pluggable-transports/snowflake.git && cd snowflake/proxy;go build
```
Cloning into 'snowflake'...
warning: redirecting to https://gitlab.torproject...Hello,
on 6.1.28+ armv7l GNU/Linux
$ cd /mnt/tmpfs;git clone https://git.torproject.org/pluggable-transports/snowflake.git && cd snowflake/proxy;go build
```
Cloning into 'snowflake'...
warning: redirecting to https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake.git/
remote: Enumerating objects: 6098, done.
remote: Counting objects: 100% (199/199), done.
remote: Compressing objects: 100% (114/114), done.
remote: Total 6098 (delta 83), reused 194 (delta 83), pack-reused 5899
Receiving objects: 100% (6098/6098), 2.64 MiB | 3.70 MiB/s, done.
Resolving deltas: 100% (4117/4117), done.
go: downloading github.com/prometheus/client_golang v1.16.0
...
go: downloading gopkg.in/yaml.v3 v3.0.1
/home/user/go/pkg/mod/golang.org/x/crypto@v0.10.0/curve25519/curve25519_go120.go:9:8: package crypto/ecdh is not in GOROOT (/usr/lib/go-1.15/src/crypto/ecdh)
```
user@host /mnt/tmpfs/snowflake/proxy $ ls
```
lib main.go README.md
```
And when i copy [latest release](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/releases) .tar.gz file link and try to download it:
$ cd /mnt/tmpfs/ && wget https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/jobs/295269/artifacts/file/snowflake-.tar.gz
```
...
HTTP request sent, awaiting response... 404 Not Found
```
Can you fix that 404 file please, or if you have idea how to allow build on mine mentioned system?
In the meantime, i have tried to "go built" on a different (also Debian based - 5.10.0-20-amd64 x86_64 GNU/Linux) computer and copied resulting "proxy" directory to 6.1.28+ armv7l GNU/Linux computer: scp -r ../proxy/ user@192.168.1.10:/home/user/snowflake/
Yet it does not launch it: /home/user/snowflake/proxy/proxy: cannot execute binary file: Exec format error
Building using "GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build" [mentioned in my previous issue](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40213#note_2845175) and copying to othr computer also end in "Exec format error".
On source, it launch ./proxy OK.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40281Umbrel Snowflake Tor Proxy down for days2023-08-09T10:41:18ZXiangcaiUmbrel Snowflake Tor Proxy down for days### Umbrel SnowFlake Log
```plaintext
snowflake
Attaching to snowflake_tor_server_1, snowflake_web_1, snowflake_app_proxy_1, snowflake_proxy_1
app_proxy_1 | [HPM] Client disconnected
app_proxy_1 | Validating token: 1b19614ff477 ......### Umbrel SnowFlake Log
```plaintext
snowflake
Attaching to snowflake_tor_server_1, snowflake_web_1, snowflake_app_proxy_1, snowflake_proxy_1
app_proxy_1 | [HPM] Client disconnected
app_proxy_1 | Validating token: 1b19614ff477 ...
app_proxy_1 | Validating token: 1b19614ff477 ...
app_proxy_1 | Validating token: 1b19614ff477 ...
app_proxy_1 | [HPM] Upgrading to WebSocket
app_proxy_1 | Validating token: 1b19614ff477 ...
app_proxy_1 | [HPM] Client disconnected
app_proxy_1 | Validating token: 1b19614ff477 ...
app_proxy_1 | [HPM] Upgrading to WebSocket
app_proxy_1 | [HPM] Client disconnected
proxy_1 | 2023/07/27 13:57:22 Timed out waiting for client to open data channel.
proxy_1 | 2023/07/27 13:57:23 sdp offer successfully received.
proxy_1 | 2023/07/27 13:57:23 Generating answer...
proxy_1 | 2023/07/27 13:57:49 Timed out waiting for client to open data channel.
proxy_1 | 2023/07/27 13:58:42 sdp offer successfully received.
proxy_1 | 2023/07/27 13:58:42 Generating answer...
proxy_1 | 2023/07/27 13:59:10 Timed out waiting for client to open data channel.
proxy_1 | 2023/07/27 14:01:44 sdp offer successfully received.
proxy_1 | 2023/07/27 14:01:44 Generating answer...
proxy_1 | 2023/07/27 14:02:10 Timed out waiting for client to open data channel.
web_1 | 2023/07/27 13:41:50 websocket: close 1001
web_1 | 2023/07/27 13:41:50 Connection closed: 10.21.0.8:59112, connections: 0
web_1 | 2023/07/27 13:41:50 Command exited for: 10.21.0.8:59112
web_1 | 2023/07/27 13:57:00 10.21.0.8:59760 200 GET /auth_token.js
web_1 | 2023/07/27 13:57:00 New client connected: 10.21.0.8:59764
web_1 | 2023/07/27 13:57:00 Command is running for client 10.21.0.8:59764 with PID 23 (args="-c tail -n 10000 -f /snowflake/snowflake.log | grep \"Traffic Relayed\""), connections: 1
web_1 | 2023/07/27 13:57:00 10.21.0.8:59764 101 GET /ws
web_1 | 2023/07/27 13:57:03 websocket: close 1001
web_1 | 2023/07/27 13:57:03 Command exited for: 10.21.0.8:59764
web_1 | 2023/07/27 13:57:03 Connection closed: 10.21.0.8:59764, connections: 0
```meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40280Remove proxy churn measurement from broker2023-10-16T14:33:23ZDavid Fifielddcf@torproject.orgRemove proxy churn measurement from broker#34075 and !95 added records to the broker
to estimate proxy churn.
We now have [done the analysis](https://github.com/turfed/snowflake-paper/tree/1c217201393bc15d2bf131b4be564f4bd00764af/figures/proxy-churn).
metrics-ip-salted.jsonl is ...#34075 and !95 added records to the broker
to estimate proxy churn.
We now have [done the analysis](https://github.com/turfed/snowflake-paper/tree/1c217201393bc15d2bf131b4be564f4bd00764af/figures/proxy-churn).
metrics-ip-salted.jsonl is now over 600 MB.
If we do not have plans for analyzing future measurements,
we should stop recording them.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2023-08-10https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40279Try reducing num-turbotunnel in server2024-01-22T15:19:37ZDavid Fifielddcf@torproject.orgTry reducing num-turbotunnel in server#40200 (and later #40246) caused snowflake-server to use multiple parallel KCP engines, which had an observable beneficial effect on performance. But those changes happened during the time between #40199 and #40262, and it may be that th...#40200 (and later #40246) caused snowflake-server to use multiple parallel KCP engines, which had an observable beneficial effect on performance. But those changes happened during the time between #40199 and #40262, and it may be that their apparent benefit was actually an accidental partial mitigation of #40260. (Partitioning clients over multiple KCP engines may have reduced the chance of packet corruption, which had its own negative effect on performance.)
I want to try reducing `num-turbotunnel` again, now that #40260 is fixed.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40278Snowflake failed to connect on Android 11 and above2024-01-10T16:06:45ZGedshSnowflake failed to connect on Android 11 and aboveThis issue causes Snowflake to be unable to establish a connection on Android 11 and above when the app's target SDK level is above 29.
It is related to the Go x/mobile issue https://github.com/golang/go/issues/40569
The problem is loc...This issue causes Snowflake to be unable to establish a connection on Android 11 and above when the app's target SDK level is above 29.
It is related to the Go x/mobile issue https://github.com/golang/go/issues/40569
The problem is located in the Pion library https://github.com/pion/ice/blob/214c86c5cfbc40fa9adbbea59081bd64c8b65d7c/agent.go#L327 which calls https://pkg.go.dev/github.com/mingyech/transport/v2/stdnet#Net.UpdateInterfaces which is forbidden on Android 11.
Snowflake log:
```go
2023/07/09 17:40:03 snowflake-client 2.5.1
2023/07/09 17:40:03 Started SOCKS listener at [scrubbed].
2023/07/09 17:40:17 SOCKS accepted: {[scrubbed] utls-imitate=hellorandomizedalpn map[utls-imitate:[hellorandomizedalpn]]}
2023/07/09 17:40:17
--- Starting Snowflake Client ---
2023/07/09 17:40:17 Using ICE servers:
2023/07/09 17:40:17 url: stun:stun.bluesip.net:3478
2023/07/09 17:40:17 url: stun:stun.epygi.com:3478
2023/07/09 17:40:17 url: stun:stun.stunprotocol.org:3478
2023/07/09 17:40:17 url: stun:stun.voys.nl:3478
2023/07/09 17:40:17 url: stun:stun.uls.co.za:3478
2023/07/09 17:40:17 url: stun:stun.sonetel.net:3478
2023/07/09 17:40:17 url: stun:stun.antisip.com:3478
2023/07/09 17:40:17 Rendezvous using Broker at: https://snowflake-broker.torproject.net.global.prod.fastly.net/
2023/07/09 17:40:17 Domain fronting using: cdn.sstatic.net
2023/07/09 17:40:17 ---- SnowflakeConn: begin collecting snowflakes ---
2023/07/09 17:40:17 ---- SnowflakeConn: starting a new session ---
2023/07/09 17:40:17 ---- SnowflakeConn: begin stream 3 ---
2023/07/09 17:40:17 redialing on same connection
2023/07/09 17:40:17 WebRTC: Collecting a new Snowflake. Currently at [0/1]
2023/07/09 17:40:17 snowflake-421fa3a84195d6e9 connecting...
2023/07/09 17:40:17 WebRTC: DataChannel created
2023/07/09 17:40:17 Failed to prepare offer failed to create network: route ip+net: netlinkrib: permission denied
2023/07/09 17:40:17 WebRTC: closing DataChannel
2023/07/09 17:40:17 WebRTC: closing PeerConnection
2023/07/09 17:40:17 WebRTC: Closing
2023/07/09 17:40:17 WebRTC: failed to create network: route ip+net: netlinkrib: permission denied Retrying...
2023/07/09 17:40:17 NAT Type: unrestricted
```Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoo2023-08-31https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40277Specialize ClientMap for ClientID2024-01-07T23:43:45ZDavid Fifielddcf@torproject.orgSpecialize ClientMap for ClientIDThe [`ClientMap.SendQueue`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/58c3121c6b3afe54ddb31edc5efca613142bbe4e/common/turbotunnel/clientmap.go#L56)
function is the first actual Snowflake func...The [`ClientMap.SendQueue`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/58c3121c6b3afe54ddb31edc5efca613142bbe4e/common/turbotunnel/clientmap.go#L56)
function is the first actual Snowflake function
that appears in a CPU profile of snowflake-server:
[snowflake-server.2023-06-28T10_47_29Z.cpu.prof](/uploads/7b0f409a90bdc95b4bba169df794649a/snowflake-server.2023-06-28T10_47_29Z.cpu.prof)
```
$ go tool pprof -text 'snowflake-server.2023-06-28T10:47:29Z.cpu.prof'
File: snowflake-server.20230628.c3e2f91b.prof
Type: cpu
Time: Jun 28, 2023 at 10:47am (UTC)
Duration: 1hrs, Total samples = 63696.55s (1769.24%)
Showing nodes accounting for 52749.47s, 82.81% of 63696.55s total
Dropped 1622 nodes (cum <= 318.48s)
flat flat% sum% cum cum%
17749.19s 27.87% 27.87% 17749.19s 27.87% runtime/internal/syscall.Syscall6
3813.60s 5.99% 33.85% 3813.60s 5.99% runtime.epollwait
2380.75s 3.74% 37.59% 8172.14s 12.83% runtime.selectgo
1915.76s 3.01% 40.60% 1915.76s 3.01% runtime.memmove
1770.22s 2.78% 43.38% 2580.39s 4.05% runtime.lock2
1269.98s 1.99% 45.37% 1341.07s 2.11% runtime.casgstatus
1046.43s 1.64% 47.01% 1291.14s 2.03% runtime.unlock2
998.18s 1.57% 48.58% 2658.96s 4.17% runtime.sellock
905.56s 1.42% 50.00% 3656.57s 5.74% runtime.mallocgc
867.74s 1.36% 51.36% 871.58s 1.37% runtime.(*waitq).dequeue (inline)
826.43s 1.30% 52.66% 826.43s 1.30% crypto/aes.gcmAesEnc
789.16s 1.24% 53.90% 2709.70s 4.25% github.com/xtaci/kcp-go/v5.(*KCP).flush
617.51s 0.97% 54.87% 7628.15s 11.98% runtime.schedule
572.20s 0.9% 55.77% 2542.47s 3.99% gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/v2/common/turbotunnel.(*ClientMap).SendQueue
538.09s 0.84% 56.61% 538.09s 0.84% runtime.futex
513.24s 0.81% 57.42% 513.24s 0.81% runtime.procyield
445.32s 0.7% 58.12% 466.23s 0.73% runtime.findObject
```
It only accounts for 1% of total CPU time,
or 4% if you count the cumulative contribution of the mutex lock/unlock
and the operations on the inner map,
but it's still a hot spot.
In the branch https://gitlab.torproject.org/dcf/snowflake/-/commits/sendqueue-clientid/
I have a change to make `ClientMap` assume it is always dealing with a `ClientID`,
not just any `net.Addr`.
The change makes `ClientMap.SendQueue` faster in `BenchmarkSendQueue`.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40276Try reducing allocations in encapsulation.ReadData2023-11-21T04:19:58ZDavid Fifielddcf@torproject.orgTry reducing allocations in encapsulation.ReadDataIn the branch https://gitlab.torproject.org/dcf/snowflake/-/commits/encapsulation-readdata-buffer
(commit https://gitlab.torproject.org/dcf/snowflake/-/commit/9ac64239b4bff07cb016d7c2609eae66a92483c8)
I have a patch to make `encapsulatio...In the branch https://gitlab.torproject.org/dcf/snowflake/-/commits/encapsulation-readdata-buffer
(commit https://gitlab.torproject.org/dcf/snowflake/-/commit/9ac64239b4bff07cb016d7c2609eae66a92483c8)
I have a patch to make `encapsulation.ReadData` fill a provided buffer rather than allocate a new buffer on every call.
This function is part of the hot read loop and is probably respondible
for a large part of garbage collection pressure.
I am going to test this change on a production bridge to see if it helps.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40274AVG blocked connection of Chrome+Snowflake due to "URL:Blacklist" threat2023-06-21T09:28:53ZcypherpunksAVG blocked connection of Chrome+Snowflake due to "URL:Blacklist" threatSnowflake 0.7.2 on Chrome was running in the background and I got a pop-up alert from AVG telling me that it had blocked a connection to https://02.snowflake.torproject.net/?client_ip=xxx.xxx.xxx.xxx
The IP listed in the actual URL belo...Snowflake 0.7.2 on Chrome was running in the background and I got a pop-up alert from AVG telling me that it had blocked a connection to https://02.snowflake.torproject.net/?client_ip=xxx.xxx.xxx.xxx
The IP listed in the actual URL belongs to a Russian telco, according to a whois query.
I tried searching for information about this but google was not helpful.
I thought I'd leave a comment here just in case.https://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/40271refactor: use Pion's `SetIPFilter` instead of our `StripLocalAddresses`2023-06-29T18:57:41ZWofWcawofwca@protonmail.comrefactor: use Pion's `SetIPFilter` instead of our `StripLocalAddresses`[`SetIPFilter`](https://pkg.go.dev/github.com/pion/webrtc/v3#SettingEngine.SetIPFilter) was [recently added](https://github.com/pion/webrtc/pull/2316) to Pion.
I'm not sure if this gives actual benefits, but to me it seems better if Pio...[`SetIPFilter`](https://pkg.go.dev/github.com/pion/webrtc/v3#SettingEngine.SetIPFilter) was [recently added](https://github.com/pion/webrtc/pull/2316) to Pion.
I'm not sure if this gives actual benefits, but to me it seems better if Pion would filter out addresses by itself, instead of us only stripping them off when sending the offer/answer (see 0fae4ee8ea487c3b4384217e193e5b9a9088e7de, 1867f89562fb25bf9a3c2172a7b6f0a198c81adb, https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/19026). It _might_ also solve [the problem (if it's a problem)](https://forum.torproject.net/t/ubuntu-snowflake-standalone-proxy-tries-to-access-private-lan/7485?u=wofwca) where if a client sends local addresses in its offer, the proxy will try to connect to these local addresses.
Also while we're at it, need to check whether it can be a proper way to solve https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40108.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/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/40263proxy: option to set IPv4 and IPv6 bind addresses2023-03-28T18:36:39Zbennyproxy: option to set IPv4 and IPv6 bind addressesfeature request:
On a system with multiple IPv4 & IPv6 addresses and services it would be very helpful to set one (or more) IPv4 and one (or more) IPv6 address for the tcp/udp sockets by proxy.
Different to --outbound-address it should...feature request:
On a system with multiple IPv4 & IPv6 addresses and services it would be very helpful to set one (or more) IPv4 and one (or more) IPv6 address for the tcp/udp sockets by proxy.
Different to --outbound-address it should not be a priority - it should be a fixed IP assignment.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/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/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.org