Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2023-06-28T11:15:43Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40222Inactive connections with 510 second duration2023-06-28T11:15:43ZVortInactive connections with 510 second durationAfter commit 1bc54948 (!108), I started to notice lots of connections in logs with similar duration (510s-512s), which were closed due to inactivity.
I see several possible reasons for such behaviour:
1. All such connections come from ...After commit 1bc54948 (!108), I started to notice lots of connections in logs with similar duration (510s-512s), which were closed due to inactivity.
I see several possible reasons for such behaviour:
1. All such connections come from non-standard clients.
2. Timeout value from !108 is too small.
3. Lots of connections broke because of high rate of UDP losses in my network.
```bash
$ grep -c "over 51[012]" log_crop2.txt && grep -c "Traffic throughput" log_crop2.txt
52
459
```
If connections are closed because of problems with my network (3), then, most likely, nothing should be done from snowflake side.
If this is a sign of attack or other bot activity (1), then it may need further investigation.
And, most importantly, if all of them are legit and my network is good enough for snowflake (2), it means losing >11% of user connections just because of bug, which I think is not acceptable.
```bash
$ grep "over 51[012]" log_crop2.txt | tail -20
2022/10/20 09:20:16 Traffic throughput (up|down): 1 MB|45 KB -- (209 OnMessages, 2641 Sends, over 510 seconds)
2022/10/20 09:49:23 Traffic throughput (up|down): 7 MB|367 KB -- (750 OnMessages, 6452 Sends, over 510 seconds)
2022/10/20 10:18:56 Traffic throughput (up|down): 184 KB|12 KB -- (53 OnMessages, 1236 Sends, over 510 seconds)
2022/10/20 11:05:02 Traffic throughput (up|down): 1 MB|26 KB -- (193 OnMessages, 1156 Sends, over 510 seconds)
2022/10/20 11:11:46 Traffic throughput (up|down): 51 KB|16 KB -- (93 OnMessages, 853 Sends, over 510 seconds)
2022/10/20 11:52:27 Traffic throughput (up|down): 11 MB|180 KB -- (428 OnMessages, 11799 Sends, over 510 seconds)
2022/10/20 12:16:46 Traffic throughput (up|down): 48 KB|13 KB -- (169 OnMessages, 334 Sends, over 510 seconds)
2022/10/20 12:30:28 Traffic throughput (up|down): 3 MB|353 KB -- (1053 OnMessages, 4517 Sends, over 510 seconds)
2022/10/20 12:31:58 Traffic throughput (up|down): 4 MB|47 KB -- (500 OnMessages, 3478 Sends, over 511 seconds)
2022/10/20 12:39:16 Traffic throughput (up|down): 27 KB|28 KB -- (58 OnMessages, 297 Sends, over 510 seconds)
2022/10/20 12:56:22 Traffic throughput (up|down): 1 MB|12 KB -- (72 OnMessages, 1206 Sends, over 510 seconds)
2022/10/20 13:16:58 Traffic throughput (up|down): 29 KB|5 KB -- (28 OnMessages, 224 Sends, over 510 seconds)
2022/10/20 13:29:10 Traffic throughput (up|down): 159 KB|4 KB -- (17 OnMessages, 1997 Sends, over 510 seconds)
2022/10/20 13:30:19 Traffic throughput (up|down): 244 KB|199 KB -- (444 OnMessages, 1257 Sends, over 510 seconds)
2022/10/20 13:52:30 Traffic throughput (up|down): 259 KB|77 KB -- (236 OnMessages, 1230 Sends, over 510 seconds)
2022/10/20 13:58:37 Traffic throughput (up|down): 33 KB|7 KB -- (39 OnMessages, 760 Sends, over 511 seconds)
2022/10/20 14:00:25 Traffic throughput (up|down): 23 KB|15 KB -- (89 OnMessages, 398 Sends, over 510 seconds)
2022/10/20 14:51:09 Traffic throughput (up|down): 102 KB|30 KB -- (344 OnMessages, 538 Sends, over 511 seconds)
2022/10/20 15:06:10 Traffic throughput (up|down): 132 KB|31 KB -- (87 OnMessages, 305 Sends, over 510 seconds)
2022/10/20 15:10:26 Traffic throughput (up|down): 161 KB|111 KB -- (194 OnMessages, 1157 Sends, over 510 seconds)
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40210Remove the pollInterval loop from SignalingServer.pollOffer in the standalone...2022-10-18T18:33:59ZDavid Fifielddcf@torproject.orgRemove the pollInterval loop from SignalingServer.pollOffer in the standalone proxyThe constant `pollInterval` is used in two places in the proxy code: in an [outer loop](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L636-648) that starts sessions, a...The constant `pollInterval` is used in two places in the proxy code: in an [outer loop](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L636-648) that starts sessions, and in an [inner loop](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L206-243) for each session that repeatedly polls.
The design does not make sense: there should be only one place where the `pollInterval` is enforced.
The inner loop, in the `SignalingServer.pollOffer` function,
is barely even a loop at all:
all its internal code paths lead to a `return`.
(The error case for `s.Post` lacks a `return`,
but an empty `resp` will cause the following `DecodePollResponse` check to return.)
The inner loop should be replaced with just one iteration of straight-line code.
I did some digging to find out how the code got to be this way.
Originally `pollInterval` only appeared in the inner loop.
The outer loop would run as soon as the inner loop returned,
so the speed of the whole process depended on the delay being enforced by the inner loop.
There was a bug (#40055) where the inner loop could return
without enforcing any delay (the same `s.Post` case I mentioned above).
The fix in !51 was to add a delay to the outer loop as well.
Looking at the code now, it appears that the right place for the delay all along
was in the outer loop,
and it should not be in the inner loop at all.
Before 7a0428e3b11ba437f27d09b1a9ad0fa820e54d24, the inner loop worked differently:
it was as if the `s.Post` error case had a `continue` rather than a `return`.
That is why there is a loop at all in the inner loop.
7a0428e3b11ba437f27d09b1a9ad0fa820e54d24 inadvertently changed it so that the inner loop
returned immediately, rather than enforcing a delay and running the loop again,
which was the actual cause of #40055, I think.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40204pion errors don't go into the log2022-12-03T13:45:30ZRoger Dingledinepion errors don't go into the logMy snowflake proxy tells me, I guess on either stdout or stderr,
```
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0...My snowflake proxy tells me, I guess on either stdout or stderr,
```
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
```
but I am using -log, and these lines don't show up in the log. It is unexpected that "error" category messages would be the ones that are transient and not captured for posterity.
(Also, the timestamps in the log seem to be utc, and the timestamps on my stdout/stderr appear to be local timezone. Not sure if that merits a separate ticket -- let me know if yes and I can open it.)Linus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40197nil pointer dereference in PeerConnection.PendingLocalDescription2022-10-03T11:53:14Zcypherpunksnil pointer dereference in PeerConnection.PendingLocalDescription```
info] {EDGE} connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
info] {EDGE} connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on...```
info] {EDGE} connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
info] {EDGE} connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
info] {NET} parse_socks_client(): SOCKS 5 client: continuing without authentication
info] {NET} connection_read_proxy_handshake(): Proxy Client: OR connection (handshaking (proxy)) with 192.0.2.3:80 ID=1zOHpg+FxqQfi/6jDLtCpHHqBTH8gjYmCKXkus1D5Ko RSA_ID=2B280B23E1107BB62ABFC40DDCC8824814F80A72 successful
info] {BTRACK} bto_update_best(): ORCONN BEST_ANY state 2->3 gid=4
notice] {CONTROL} Bootstrapped 10% (conn_done): Connected to a relay
info] {BTRACK} bto_update_best(): ORCONN BEST_AP state 2->3 gid=4
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: panic: runtime error: invalid memory address or nil pointer dereference
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: [signal 0xc0000005 code=0x0 addr=0x0 pc=0x5ed17d]
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error:
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: goroutine 53 [running]:
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: github.com/pion/webrtc.(*PeerConnection).PendingLocalDescription(0x0)
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/github.com/pion/webrtc/peerconnection.go:2026 +0x1d
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: github.com/pion/webrtc.(*PeerConnection).LocalDescription(0xc00034c000)
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/github.com/pion/webrtc/peerconnection.go:1007 +0x1e
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.(*WebRTCPeer).connect(0xc00034c000, 0x0, 0xc000345d48)
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/webrtc.go:150 +0xd8
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.NewWebRTCPeerWithEvents(0x35ee40, 0xc0000d6000, {0x223f8f30008, 0xc00022e220})
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/webrtc.go:73 +0x38b
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.WebRTCDialer.Catch(...)
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/rendezvous.go:172
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.(*Peers).Collect(0xc000234080)
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/peers.go:69 +0x223
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.connectLoop({0x846bd0, 0xc000234080})
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/snowflake.go:345 +0x56
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: created by git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.(*Transport).Dial
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/snowflake.go:170 +0x206
info] {NET} TLS error: <syscall error while handshaking> (errno=10054: Connection reset by peer [WSAECONNRESET ]; state=SSLv3/TLS write client hello)
info] {OR} connection_tls_continue_handshake(): tls error [connection reset]. breaking connection.
info] {CIRC} circuit_n_chan_done(): Channel failed; closing circ.
info] {GENERAL} circuit_mark_for_close_(): Circuit 0 (id: 1) marked for close at circuitbuild.c:687 (orig reason: 8, new reason: 0)
info] {HANDSHAKE} connection_or_note_state_when_broken(): Connection died in state 'handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE'
info] {BTRACK} bto_status_rcvr(): ORCONN DELETE gid=4 status=2 reason=4
warn] {CONTROL} Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (CONNECTRESET; CONNECTRESET; count 1; recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 192.0.2.3:80)
warn] {HANDSHAKE} 1 connections have failed:
warn] {HANDSHAKE} 1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
info] {OR} circuit_build_failed(): Our circuit 0 (id: 1) died before the first hop with no connection
info] {GUARD} entry_guards_note_guard_failure(): Recorded failure for primary guard $2B280B23E1107BB62ABFC40DDCC8824814F80A72 ($2B280B23E1107BB62ABFC40DDCC8824814F80A72)
info] {CIRC} circuit_free_(): Circuit 0 (id: 1) has been freed.
warn] {PT} Pluggable Transport process terminated with status code 2
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40178Handle unknown client NAT type better to reduce load on restricted proxy pool2022-10-12T18:01:31ZCecylia BocovichHandle unknown client NAT type better to reduce load on restricted proxy poolWe're seeing a large number of clientpolls with unknown NAT types:
![image](/uploads/af5a7125fb7f8168b2bf6d2637a2ebaf/image.png)
To be safe, we treat unknown client NATs the same as restricted client NATs, so they pull from the smaller...We're seeing a large number of clientpolls with unknown NAT types:
![image](/uploads/af5a7125fb7f8168b2bf6d2637a2ebaf/image.png)
To be safe, we treat unknown client NATs the same as restricted client NATs, so they pull from the smaller pool of proxies that are known to work with symmetrics NATs. It's possible we can relieve at least some of the pressure on this proxy pool by having unknown clients first try proxies from the unrestricted pool and then fall back to the restricted pool if there is a failure to connect.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40170Create a patch to remove Hello Verify Request in Snowflake's WebRTC2022-08-09T19:15:31ZshelikhooCreate a patch to remove Hello Verify Request in Snowflake's WebRTCThe Snowflake with [patched](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/83) supported_groups [don't](https://ntc.party/t/testing-invitation-for-tor-browser-with-supported-groups-patch-countermeasure-in-snowflake-to-e...The Snowflake with [patched](https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/83) supported_groups [don't](https://ntc.party/t/testing-invitation-for-tor-browser-with-supported-groups-patch-countermeasure-in-snowflake-to-evade-censorship-observed-in-russia/2837/2) work. It is suggested that Hello Verify Request is now the signature being targeted.
```
16:07:39 <shelikhoo> the patched version we produced is not working]
16:08:12 <shelikhoo> and one of the possible reason that that Hello Verify is now censored
16:08:24 <shelikhoo> and one of the possible reason is that that Hello Verify is now censored
16:08:34 <dcf1> Hello Verify Request: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030#note_2823140
16:08:50 <shelikhoo> we could patch it again and generate an binary again
16:11:21 <shelikhoo> do we have an existing patch for removing Hello Verify?
16:11:28 <shelikhoo> that we can just apply?
16:11:48 <dcf1> Not as far as I know
16:15:26 <shelikhoo> I can create a ticket to track this issue.
16:16:34 <shelikhoo> https://gist.github.com/xiaokangwang/5cd4437d087b0159146b0cb9d09aa9a5
16:16:55 <shelikhoo> I received such an patch, but I forgot the exact context I got it...
16:18:14 <shelikhoo> I think it changes whether the local will be client or server to avoid some censorship
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40169Update Snowflake Proxy in third party Distribution Channel: umbrel2023-07-27T15:19:55ZshelikhooUpdate Snowflake Proxy in third party Distribution Channel: umbrelSome users requested advise on updating snowflake proxy on umbrel, a server management software that have a software store.
We need to update this file to get it updated.
https://github.com/getumbrel/umbrel-apps/blob/master/snowflake/do...Some users requested advise on updating snowflake proxy on umbrel, a server management software that have a software store.
We need to update this file to get it updated.
https://github.com/getumbrel/umbrel-apps/blob/master/snowflake/docker-compose.ymlhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40166Dedicated Snowflake server port as a way to tell if host allows Snowflake con...2023-09-17T13:17:29ZWofWcawofwca@protonmail.comDedicated Snowflake server port as a way to tell if host allows Snowflake connectionsDisclaimer: I'm no networking / information security expert.
I was thinking about using Snowflake for non-Tor applications (like 1/2-hop VPN).
Currently Snowflake proxies are configured to only forward connections to certain domains / ...Disclaimer: I'm no networking / information security expert.
I was thinking about using Snowflake for non-Tor applications (like 1/2-hop VPN).
Currently Snowflake proxies are configured to only forward connections to certain domains / domain patterns (i.e. the Snowflake Tor relay), which constrains the usefulness of Snowflake network to Tor only. Not only that, but it also doesn't allow for truly distributed Snowflake relay network (#40129).
And I thought - how about we allow clients to ask proxies to connect to arbitrary addresses, but only to certain port(s)?
This should limit its use for malicious purposes as a botnet, like DDOS (from both malicious clients and malicious broker). For further DDOS protection, proxies could set a timeout for server / client if a connection is rejected by the server (port is closed, or port is open, but host rejected the protocol (either transport-level, or data-level (i.e. there is a Snowflake-specific handshake)), or rejected the client with this IP (if it's forwarded), maybe something else).
Also, as was said in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248#note_2869324, probably need to reject local addresses.
Of course, more thorough analysis is required.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40164perf: trickle ICE (don't wait for ICE gathering to complete before sending an...2023-01-26T18:29:49ZWofWcawofwca@protonmail.comperf: trickle ICE (don't wait for ICE gathering to complete before sending an offer/answer)...and keep sending new ICE candidates after.
I'm not a big expert on WebRTC but from what I've read (UPD: and [experienced](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/68#note_285066......and keep sending new ICE candidates after.
I'm not a big expert on WebRTC but from what I've read (UPD: and [experienced](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/68#note_2850662)), it can take a while for ICE gathering to complete, but a connection can be established before it does complete. [Here](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling#exchanging_ice_candidates) it says:
> Each peer sends candidates in the order they're discovered, and keeps sending candidates until it runs out of suggestions, even if media has already started streaming.
In JS there is `addIceCandidate` and `onicecandidate` (and `canTrickleIce`). In the Go version, there is [`pc.OnICECandidate`](https://github.com/pion/webrtc/tree/master/examples/trickle-ice).
I suspect that this waiting may be the reason why connections time out sometimes (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30498). Also there is ["How come some Snowflake bootstrap attempts are so slow?" in the wiki](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/Vision-for-the-Future).
I believe this will require updates to the broker API. Maybe for each proxy/client pair broker needs to make a WebSocket pair that will forward the ICE candidates between them. Or maybe a conventional HTTP request would suffice, as we already have IDs (e.g. see the `/answer` request). Or can they be exchanged through the P2P connection itself?
Code:
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/2c008d6589e37e77f01a364ab414d6a95218de36/client/lib/webrtc.go#L241-242
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/97dea533da7b6b3b2b1dfbffe7dca3a8350fab0b/proxy/lib/snowflake.go#L403-406
Some more resources about WebRTC:
* https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity#the_entire_exchange_in_a_complicated_diagram
* https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Perfect_negotiationhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40163client: don't timeout connection attempts until some connection succeeds2023-06-21T09:15:24ZWofWcawofwca@protonmail.comclient: don't timeout connection attempts until some connection succeedsSo when trying to connect, instead of dropping a connection, then starting a new one we could just start a new one in parallel, hoping that the old one will succeed. Then, when one (or however many we need) succeeds, drop the other ones....So when trying to connect, instead of dropping a connection, then starting a new one we could just start a new one in parallel, hoping that the old one will succeed. Then, when one (or however many we need) succeeds, drop the other ones.
We probably still need keep the timeout, but make it longer.
I am not sure if there is already code that does this. If there is, then I think `DataChannelTimeout` simply needs to be made greater than `ReconnectTimeout`.
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/c983c13a84554d0ba1ffcdd054491090c0eafc54/client/lib/snowflake.go#L47-57
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/c983c13a84554d0ba1ffcdd054491090c0eafc54/client/lib/webrtc.go#L174-182
Related:
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40025
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25723
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30498https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40159Make Snowflake recognize FascistFirewall2022-10-28T19:15:17ZcypherpunksMake Snowflake recognize FascistFirewallSnowflake takes a long time to start a connection when a firewall is blocking outgoing ports. If the tor daemon or Tor Browser is configured to connect only to certain ports, then Snowflake could recognize that setting and not take so lo...Snowflake takes a long time to start a connection when a firewall is blocking outgoing ports. If the tor daemon or Tor Browser is configured to connect only to certain ports, then Snowflake could recognize that setting and not take so long to start a connection. Right now, Snowflake stalls when that setting is enabled, regardless of a firewall.
In the tor daemon, the settings are `FascistFirewall` and `ReachableAddresses`. In Tor Browser, the setting is located at `Settings --> Connection --> Advanced --> "Configure how Tor Browser connects to the internet" (Settings... button) --> "This computer goes through a firewall that only allows connections to certain ports" (80,443)`.
Going further, Snowflake could assume after certain conditions also that Tor Project's [ReducedExitPolicy](https://gitlab.torproject.org/legacy/trac/-/wikis/doc/ReducedExitPolicy) is enabled in the firewall.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40156Multi-Pool Matching Support In Snowflake2023-03-15T06:56:41ZshelikhooMulti-Pool Matching Support In SnowflakeCurrently, there is only one matching pool for all snowflake proxies. The proxies either enter the pool and match with any clients, or if it is deemed ineligible rejected from the pool. This makes it difficult to serve more than one purp...Currently, there is only one matching pool for all snowflake proxies. The proxies either enter the pool and match with any clients, or if it is deemed ineligible rejected from the pool. This makes it difficult to serve more than one purpose as the client sharing a single pool cannot choose which set of servers it would like to relay traffic to.
To add multi-pool matching support into Snowflake:
- Add multi-pool support in the broker
- Add or expression in the domain matcher(Both Standalone and Browser Extension port)
- Add UI changes to the Browser Extension to support selective participationhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40155screenshots for translators2022-10-04T17:54:48Zmeskiomeskio@torproject.orgscreenshots for translators@emmapeel is asking if we can provide some screenshots for transifex so the translators get some context on the strings they are translating. The webextension strings are:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-trans...@emmapeel is asking if we can provide some screenshots for transifex so the translators get some context on the strings they are translating. The webextension strings are:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/blob/main/static/_locales/en_US/messages.json
I think some of those strings are only used in the webextension store, isn't it? we might need also screenshots of those.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40150Test Snowflake Client against different types of proxies2022-10-19T00:02:22ZshelikhooTest Snowflake Client against different types of proxiesDuring the discussion about the Russian ISP's block of snowflake based on supported_groups, @arma discussed the possibility of testing the snowflake client against different kinds of proxies to get more detailed info about connectivity.
...During the discussion about the Russian ISP's block of snowflake based on supported_groups, @arma discussed the possibility of testing the snowflake client against different kinds of proxies to get more detailed info about connectivity.
IRC:
```
[5:46:07 pm] <+arma2> shelikhoo: based on the dtls discussion above, it sure seems valuable to me to have a 'matrix of snowflake variants' regression test
[5:46:16 pm] <+arma2> where we try each client (mainly just snowflake-client) against each proxy type
[5:46:29 pm] <+arma2> and maybe do it periodically on our own, or before each release, or from censored places, etc
[5:46:58 pm] <+arma2> because right now we don't even know which combinations are *supposed* to work
[5:47:25 pm] <+arma2> (i mean, 'all of them' are supposed to work, but, you know what i mean :)
[5:48:50 pm] <+shelikhoo> yes, I think we will need to have a few brokers to handle each type of proxy
[5:49:29 pm] <+shelikhoo> and somewhere to run a browser...
[5:49:35 pm] <+arma2> maybe. or a way for the broker to know which proxy each volunteer is using, and a way to request a specific one
[5:50:03 pm] <+shelikhoo> yes. that would require more advanced matching logic
[5:50:07 pm] <+arma2> but yes, maybe a 'regression broker' which is a different broker you use just for this test
[5:50:18 pm] <+arma2> lots of options
[5:50:24 pm] <+arma2> the destination seems worthwhile though, however we get there
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40149Connection Result Feedback2022-06-22T18:55:40ZshelikhooConnection Result FeedbackCurrently, the broker does not receive feedback from the client about whether the Snowflake connection is successful. This means we do not receive feedback from real-world connection attempts. In the last team sync meeting, @arma and I d...Currently, the broker does not receive feedback from the client about whether the Snowflake connection is successful. This means we do not receive feedback from real-world connection attempts. In the last team sync meeting, @arma and I discussed receiving more automated feedback from clients. and one of the ways it could work is by receiving connection feedback info from clients.
IRC:
```
[5:51:16 pm] <+shelikhoo> yes. and better if the broker can track if the connection between proxy and client is actually successful or not
[5:51:29 pm] <+shelikhoo> so that we don't need run separate test
[5:51:42 pm] <+shelikhoo> just observe the real world data from users
[5:52:28 pm] <+arma2> hm! yes, now i want that too :)
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40147Move snowflake-broker to a systemd based setup2023-04-10T19:39:01ZshelikhooMove snowflake-broker to a systemd based setupCurrently snowflake-broker is using a [runit](http://manpages.ubuntu.com/manpages/trusty/man8/sv.8.html) based setup. It is simple and working but has some limitations.
We could consider moving to systemd to enable [auto](https://www.fr...Currently snowflake-broker is using a [runit](http://manpages.ubuntu.com/manpages/trusty/man8/sv.8.html) based setup. It is simple and working but has some limitations.
We could consider moving to systemd to enable [auto](https://www.freedesktop.org/software/systemd/man/systemd.service.html#RuntimeMaxSec=) restart.
Edit: remove incorrect info. Thanks @dcf .https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40137Automated LoadBalanced Tor Snowflake Server Deployment System2022-10-12T18:46:02ZshelikhooAutomated LoadBalanced Tor Snowflake Server Deployment SystemWe are currently using load-balanced tor + snowflake for our current Snowflake setup. However, it still requires significant skill and effort to setup it up manually.
It might be wise for us to create an automated way to set up things t...We are currently using load-balanced tor + snowflake for our current Snowflake setup. However, it still requires significant skill and effort to setup it up manually.
It might be wise for us to create an automated way to set up things to make it easier for other organizations to run the Snowflake server.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40132Discussion: libp2p expansion.2022-05-06T00:48:32ZcheakoDiscussion: libp2p expansion.I've always wanted to spin up my own p2p networks. Perhaps you don't agree that anyone should be able to share in one network with islands for each client program. I believe tor is mutually beneficial to this goal. I've studied arti a...I've always wanted to spin up my own p2p networks. Perhaps you don't agree that anyone should be able to share in one network with islands for each client program. I believe tor is mutually beneficial to this goal. I've studied arti and am sad that it doesn't yet support the full for protocol. It looks like there just may be enough there to leach off of tor bridges. That's not the kind of good-natured application I'm interested in.
The libp2p supporters seem uninterested in anything other than a software as a service model. They are uninterested in any p2p network that could stand on its own.
I've looked at snowflake and see that it doesn't currently meet my needs, but it's close.
The kind of application I would build is for playing cards/chess, message boards and sharing doom demo files/high scores. Users would try and be connected all the time, but some would connect for a few hours every day.
The problem tor solves is nat traversal. It would be nice if bootstrapping was also available. At the start of each network there is only one or two nodes. libp2p solves this problem with a "global" DHT, with each program supporting this DHT even if there is only one client connecting there will be nodes running a completely different program but they will serve out the DHT with data from a host that may be offline ATM.
I believe snowflake could be improved in two main ways. 1. Is for the broker to be generic enough for any application to use it. 2. Is for client to proxy connections to be build on top of libp2p.
I envision a future where libp2p clients expand tor DHT and network in exchange for being a rally point for beginner p2p networks.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40131Unix socket support.2023-01-05T17:20:17ZcheakoUnix socket support.I usually want to have nginx reverse proxy over Unix sockets. Otherwise, there are strange fw rules for "random" port numbers.
For both the websocket to tor server and the broker.I usually want to have nginx reverse proxy over Unix sockets. Otherwise, there are strange fw rules for "random" port numbers.
For both the websocket to tor server and the broker.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40128Give standalone snowflakes guidance on how best to set up their nat2023-03-31T16:56:08ZRoger DingledineGive standalone snowflakes guidance on how best to set up their natAccording to our current broker stats (https://snowflake-broker.torproject.net/debug), we have
```
current snowflakes available: 3021
standalone proxies: 2589
browser proxies: 5
webext proxies: 250
unknown proxies: 177
NAT Types avai...According to our current broker stats (https://snowflake-broker.torproject.net/debug), we have
```
current snowflakes available: 3021
standalone proxies: 2589
browser proxies: 5
webext proxies: 250
unknown proxies: 177
NAT Types available:
restricted: 2512
unrestricted: 386
unknown: 123
```
i.e. most of the snowflakes that we're giving out seem to be standalone ones as opposed to browser extension ones, and also most of the ones we have available to us are behind restricted nat.
It seems to me that the standalone ones are probably in a better position to be behind the good kind of nat (or no nat at all). But does our docker image impose the bad kind of nat on them by default? How come so many standalone proxies are behind restricted nat?
More generally: is there useful guidance we can give people, on setting themselves up with the right kind of nat, presuming they're on a VPS or otherwise on a 'real' internet connection?shelikhooshelikhoo