Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2023-10-03T18:22:22Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40250Broker side channel fallback mechanism2023-10-03T18:22:22Zmeskiomeskio@torproject.orgBroker side channel fallback mechanismCurrently we are using domain fronting as our main side channel to connect to the broker, but amp cache is also supported. When the domain fronting is blocked (like in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115) ...Currently we are using domain fronting as our main side channel to connect to the broker, but amp cache is also supported. When the domain fronting is blocked (like in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/115) it will be useful to automatically fall back to amp cache.
This would be really nice to be encoded in the bridge line, but we are already near the limit on size for the bridge line.
The snowflake client could use the bridgeline provided side channel configuration and if that fails try to use the one provided by the flags passed to the binary on launch (by `ClientTransportPlugin`). This has the problem that those flags will not be distributed by Circumvention Settings and needs some coordination with the different tor applications to have the same defaults everywhere. We might need to think how snowflake library users will use this fallback (or if they need to implement it themselves).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249Upstreaming Remove HelloVerify countermeasure2023-03-03T11:45:36ZshelikhooUpstreaming Remove HelloVerify countermeasureWe have already released a version of snowflake with [Remove HelloVerify](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/134) [Orig](https://gitlab.torproject.org/tpo/anti-censorship/plu...We have already released a version of snowflake with [Remove HelloVerify](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/134) [Orig](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/131) countermeasure against Russia's censorship of snowflake. However, as we are currently applying the changes as a series of patch in the forked repo, this situation isn't ideal if that means we need to constantly rebase and maintain this fork.
Thus, we are currently seeking to upstream this change.
Changes to be upstreamed:
1. [DTLS](https://github.com/xiaokangwang/dtls/tree/dev-skiphelloverify) -> [Github Pull Request](https://github.com/pion/dtls/pull/513)
2. [WebRTC](https://github.com/xiaokangwang/webrtc/tree/dev-skiphelloverify) -> [Github Pull Request](https://github.com/pion/webrtc/pull/2407)
See Also: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/637shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248(More) Distributed servers2023-09-17T15:22:17ZWofWcawofwca@protonmail.com(More) Distributed serversStanding on the shoulders of #40129, I propose the following.
This should allow clients to connect to _any_ accordingly set-up bridge (or even a regular entry node) they choose (say, distributed through moat, or any other channels), eli...Standing on the shoulders of #40129, I propose the following.
This should allow clients to connect to _any_ accordingly set-up bridge (or even a regular entry node) they choose (say, distributed through moat, or any other channels), eliminating the need of maintaining several centralized, set-in-stone Snowflake servers (bridges), which, mind, [costs quite a bit to operate, upgrade](https://opencollective.com/censorship-circumvention/projects/snowflake-daily-operations) and optimize.
What the parties need to become capable of doing so all this can work:
* Severs (a.k.a. bridges (or relays)): set up a Tor bridge, and set up a Snowflake server coupled with it, with a dedicated port (say, `7901` see #40166)
* Proxies: set [allowed relay pattern](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/7db2568448fed6d883b33db11e3a497c69f1748f/proxy/main.go#L28) to `*:7901` (any host, at port `7901`, see #40166)
* Clients: choose a server (bridge) that is set up accordingly, set up the Snowflake client to forward connections to that server, then connect Tor to it as a bridge.
From what I see, it should be quite possible upgrade all the current bridges ([or better public relays](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248#note_2875147)) this way (maybe even by embedding a Snowflake server in the Tor relay package), or upgrade bridge distribution mechanisms with a way to filter bridges by whether they accept Snowflake connection (like it is with obfs4). At which point it should become possible to let the Tor client choose the entry node itself, not manually specify a bridge you want (ahh, just remembered that it needs to learn the addresses of the nodes first. Maybe it can connect to directory authorities through Snowflake as well).
This idea is a based on these other ideas: #40166, #40168.
A step further would be to combine the server (bridge) and the proxy on one machine, but I haven't thought about it enough (see #40165, for example).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40247Can't open tab/icon won't stay in menu bar (Chrome)2023-01-17T15:07:17ZcypherpunksCan't open tab/icon won't stay in menu bar (Chrome)I downloaded the extension into Chrome. The icon appears, but as soon as I click on the explanation box, the icon disappears from the menu bar, so I can't open a tab. This happens even though the extension shows as active on the extens...I downloaded the extension into Chrome. The icon appears, but as soon as I click on the explanation box, the icon disappears from the menu bar, so I can't open a tab. This happens even though the extension shows as active on the extensions page.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40246Restart snowflake-server on snowflake-01 with num-turbotunnel=42023-07-18T00:47:29ZDavid Fifielddcf@torproject.orgRestart snowflake-server on snowflake-01 with num-turbotunnel=4We are hitting a performance ceiling at about 475 MiB/s TX. The CPUs are not fully saturated: they are averaging about 87%. Currently we have `num-turbotunnel=2`. I want to try increasing this to `num-turbotunnel=4` to see if the KCP sta...We are hitting a performance ceiling at about 475 MiB/s TX. The CPUs are not fully saturated: they are averaging about 87%. Currently we have `num-turbotunnel=2`. I want to try increasing this to `num-turbotunnel=4` to see if the KCP state machines are again a bottleneck.
Cf. #40200/!119 which effectively changed from `num-turbotunnel=1` to `num-turbotunnel=2`.
/cc @linus
![snowflake-01 bandwidth at eno1](/uploads/e50170475883f71f3d3306118dcbd2cd/snowflake-01-bw-20230107.png)David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40245WebRTC, but obfs4 instead of DTLS2023-01-11T16:08:39ZWofWcawofwca@protonmail.comWebRTC, but obfs4 instead of DTLS...or any other protocol.
This is very similar to #40244, which I created while researching this topic.
As we know, WebRTC data channels works like this: SCTP transport inside DTLS transport, inside ICE transport. Now, why do we have t......or any other protocol.
This is very similar to #40244, which I created while researching this topic.
As we know, WebRTC data channels works like this: SCTP transport inside DTLS transport, inside ICE transport. Now, why do we have to constrain ourselves to DTLS when we can replace it with any other protocol? The Pion library is super modular and this seems very possible: https://pkg.go.dev/github.com/pion/ice .
Advantages (compared to regular Snowflake):
* As resistant to DPI as the protocol you choose (say, obfs4) (unlike DTLS, which some censors are willing to block ([1](https://matrix.to/#/!jRxGDjXjyTpKaJypgV:matrix.org/$xLK7T6CjV9ZKA4WdxbM2EefCzAWUT_ovIGblM3e2H54?via=matrix.org&via=freitrix.de&via=1312.media), [2](https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030))).
Disadvantages:
* It's not actually WebRTC, so [the browser extension](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext) won't be able to implement it.
What it does NOT solve, compared to regular Snowflake:
* The blocking of STUN. IP-, port- and DPI-based.
TODO:
* Think if it's worth to implement based on what it doesn't solve.
* Research STUNS (STUN over TLS) (as a censorship-resistant version of regular STUN).
* Research if it can work with STUN completely blocked for the client.
The creator of Pion [said](https://gophers.slack.com/archives/CAK2124AG/p1671994856141969) that he can help sketch up such a protocol.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40244TLS instead of DTLS (TLS Candidates for ICE)2023-01-11T12:28:49ZWofWcawofwca@protonmail.comTLS instead of DTLS (TLS Candidates for ICE)I was thinking about censors blocking DTLS, partially or completely (e.g. https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030), making it impossible to initiate a WebRTC p2p connection, so I thought maybe...I was thinking about censors blocking DTLS, partially or completely (e.g. https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030), making it impossible to initiate a WebRTC p2p connection, so I thought maybe another protocol could be used. I reached out to the creator of the Pion library (the one that Snowflake uses) and he [told](https://gophers.slack.com/archives/CAK2124AG/p1671995560491059) me that [this draft](https://datatracker.ietf.org/doc/html/draft-martinsen-ice-tls-candidates-00) is probably what I want.
So, the idea: peers connect to each other with TLS, making DPI's job harder, because TLS is probably the last thing censors want to block, unlike DTLS, which offers relatively low collateral IMO.
Sean also said that it might already be implemented in libwebrtc, and that he's willing to add it to Pion.
So, I suggest to evaluate this idea and provide the Pion team the assistance we can offer, if we think that it's a good idea.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40243fix(proxy): memory leak2024-03-21T20:02:09ZWofWcawofwca@protonmail.comfix(proxy): memory leakAccording to [this forum post](https://forum.torproject.net/t/snowflake-proxy-connections-limit/4113/8?u=wofwca) and the one below it, Snowflake proxy appears to start at 100MB RAM consumption and goes up to 1.5GB.
A fix would be nice, ...According to [this forum post](https://forum.torproject.net/t/snowflake-proxy-connections-limit/4113/8?u=wofwca) and the one below it, Snowflake proxy appears to start at 100MB RAM consumption and goes up to 1.5GB.
A fix would be nice, but a catch-all alternative would be to automatically restart the proxy every so often. Maybe add the instructions here https://community.torproject.org/relay/setup/snowflake/standalone/.
UPD: It's probably a duplicate of #40154.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.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40241Remove stunprotocol.org as default for proxies and clients2023-05-24T16:51:53ZCecylia BocovichRemove stunprotocol.org as default for proxies and clientsThe STUN server we use as a default gets hit with millions of requests/day making it costly for the operator. Checklist for rolling out these changes:
- [x] Update the code (!129)
- [x] Update the default bridges in tor browser (tpo/app...The STUN server we use as a default gets hit with millions of requests/day making it costly for the operator. Checklist for rolling out these changes:
- [x] Update the code (!129)
- [x] Update the default bridges in tor browser (tpo/applications/tor-browser-build!617)
- [x] Update the suggested bridge lines given out by the circumvention settings API
- [x] Update the proxy docker container
- [x] Update the debian package
- [x] Update orbot bridge line (merged in https://github.com/guardianproject/orbot/commit/07e416d3a9475caf17ebb46bd437d235a440206f, but not shipped)meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40240Investigate if STUN over TCP/TLS is beneficial to us2023-03-26T18:19:13ZitchyonionInvestigate if STUN over TCP/TLS is beneficial to usFrom client [README:](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/client/README.md?plain=1#L48)
> `-ice` is a comma-separated list of ICE servers. These can be STUN or TURN servers.
This...From client [README:](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/client/README.md?plain=1#L48)
> `-ice` is a comma-separated list of ICE servers. These can be STUN or TURN servers.
This is not true, as right now only [STUN](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/client/lib/snowflake.go#L245) over [UDP](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/common/nat/nat.go#L147) is supported. We don't support any TURN servers, nor STUN over TLS (TCP).
We should clarify this in README, or implement support for those that are missing.
The STUN RFC contains a list of [attacks](https://www.rfc-editor.org/rfc/rfc5389#section-16.1) that can be mitigated by STUN over TLS. I'm not sure if these are relevant for Tor's usecase.itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40239Experiment with increasing conntrack table size on snowflake-012024-01-22T15:19:37ZDavid Fifielddcf@torproject.orgExperiment with increasing conntrack table size on snowflake-01During performance experimentation we (@linus and I) [disabled connection tracking](tpo/anti-censorship/pluggable-transports/snowflake#40189), suspecting it as a cause of high CPU use and because the conntrack table appeared to be danger...During performance experimentation we (@linus and I) [disabled connection tracking](tpo/anti-censorship/pluggable-transports/snowflake#40189), suspecting it as a cause of high CPU use and because the conntrack table appeared to be dangerously close to being full.
Let we [re-enabled connection tracking](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40203#note_2851633) to no apparent ill effect.
[Performance optimizations in snowflake-server](tpo/anti-censorship/pluggable-transports/snowflake!100) were enough to bring the CPU use under control.
The conntrack table still appears to be close to overflowing, but we are not actually seeing any "nf_conntrack: table full, dropping packet" kernel logs that would indicate an actual problem.
At this moment the conntrack table is 92% full (`nf_conntrack_count` / `nf_conntrack_max` = 240316 / 262144).
It could be that this is normal and nothing to worry about.
Let's try doubling the maximum number of entries and see if it reaches a new equilibrium.
Currently we have:
```
# cat /proc/sys/net/netfilter/nf_conntrack_{count,max,buckets}
240316
262144
65536
```
I'm going to do this:
```
echo 131072 > /proc/sys/net/netfilter/nf_conntrack_buckets
echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max
```
And meanwhile I'll run a tracking script to record `nf_conntrack_count` once per minute.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-12-21https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40238Server versionFlag duplicates -unsafe-logging option, causes immediate panic2022-12-14T17:20:49ZDavid Fifielddcf@torproject.orgServer versionFlag duplicates -unsafe-logging option, causes immediate panicRecent versions of the Snowflake server (e.g. 839d2218837dfbd1682ff39b375f45660b3974b5) panic immediately on startup:
```
snowflake/server$ ./server
./server flag redefined: unsafe-logging
panic: ./server flag redefined: unsafe-logging...Recent versions of the Snowflake server (e.g. 839d2218837dfbd1682ff39b375f45660b3974b5) panic immediately on startup:
```
snowflake/server$ ./server
./server flag redefined: unsafe-logging
panic: ./server flag redefined: unsafe-logging
```
The cause is a copy-paste error at https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/commit/33248f3dec5594c985cfd11e6c6143ddaa5613c0#2bfd4afce737f8dc3bb3ba69c068895274dac4e5_140_142,
which was part of !111.
The option name should have been `"version"`, but it duplicates `"unsafe-logging"` instead.
```go
flag.BoolVar(&unsafeLogging, "unsafe-logging", false, "prevent logs from being scrubbed")
flag.BoolVar(&versionFlag, "unsafe-logging", false, "display version info to stderr and quit")
```itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40237client suggested torrc does not suggest utls-imitate2022-12-09T23:08:29ZRoger Dingledineclient suggested torrc does not suggest utls-imitatehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/client/torrc
no longer matches the snowflake bridge line in Tor Browser.
In particular, the utls-imitate line in not present in the recommended...https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/client/torrc
no longer matches the snowflake bridge line in Tor Browser.
In particular, the utls-imitate line in not present in the recommended example torrc file.
[Discovered while helping a user in iran who was running snowflake + tor directly rather than inside Tor Browser]https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40236Make `test -z` more verbose so we can easily catch when it fails2022-11-17T16:28:34ZCecylia BocovichMake `test -z` more verbose so we can easily catch when it failsA few of the recent MRs have consistently failed *all* of their CI tests:
- https://gitlab.torproject.org/dcf/snowflake/-/pipelines/56708
- https://gitlab.torproject.org/dcf/snowflake/-/pipelines/56707
These MRs pass all go tests and ve...A few of the recent MRs have consistently failed *all* of their CI tests:
- https://gitlab.torproject.org/dcf/snowflake/-/pipelines/56708
- https://gitlab.torproject.org/dcf/snowflake/-/pipelines/56707
These MRs pass all go tests and vetting when run manually outside of the CI environment. It doesn't seem to matter which runner they are executed on.
Edit: figured out the problem here: `test -z "$(go fmt ./...)"` was failing, but it's silent on the CI output because it doesn't produce stderr or stdout output. Changing the purpose of this issue from debugging to making sure this doesn't confuse us again.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40235Help partner organizations to setup standalone snowflake proxies2023-03-03T17:00:16ZGabagaba@torproject.orgHelp partner organizations to setup standalone snowflake proxiesSnowflake works by creating a “flurry” of available proxies all around the world. Individuals who want to help people bypass censorship can install a Snowflake proxy into their web browser and become a temporary proxy as long as their br...Snowflake works by creating a “flurry” of available proxies all around the world. Individuals who want to help people bypass censorship can install a Snowflake proxy into their web browser and become a temporary proxy as long as their browser is open and online. This means that it’s extremely easy for many people to run proxies–we’ve seen an increase from about 30,000 to about 110,000 in the last month!
It’s also possible to set up standalone Snowflake proxies that run on their own machines or servers. While they are not as easy as a browser plugin to run, standalone Snowflake proxies have some benefits:
(1) standalone Snowflakes are connected 24/7 (instead of just when a user’s browser is on);
(2) they have a dedicated, fast, and stable connection in a data center; and
(3) they have unrestricted NAT–this is important because when using residential connections, modems and routers limit a lot of what can connect to an individual’s proxy.
In order to accommodate the amount of new traffic on the network, we need to increase the number of standalone Snowflake proxies.
In this activity, we will work with partner organizations and individuals to set up, host, and run standalone Snowflake proxies and offer them technical support. We also will help the operators monitor their proxies for blocking and respond when there are censorship events or changes so that these proxies remain available.Sponsor 139: Rapid Response IranHackerNCoderhackerncoder@encryptionin.spaceHackerNCoderhackerncoder@encryptionin.spacehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40234Signaling through TURN2023-08-24T18:14:07ZWofWcawofwca@protonmail.comSignaling through TURNThis one is an epic.
I was thinking about https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/22945#note_2823413 and #40164 and came up with an interesting idea.
How about we do signaling through a...This one is an epic.
I was thinking about https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/22945#note_2823413 and #40164 and came up with an interesting idea.
How about we do signaling through a WebRTC peer connection itself? In order to avoid [leaking the peers' private data](https://w3c.github.io/webrtc-pc/#revealing-ip-addresses), let's establish the peer connection through a TURN relay initially (with the help of `iceTransportPolicy: "relay"` WebRTC option), then set `iceTransportPolicy` to `"all"` (enabling STUN and true P2P) and `restartIce()` and continue signaling (ICE trickling).
Where do we get a TURN server, you might ask? Let's host it along with the broker, I say. Of course we'll probably need some gatekeeping for it (like limiting bandwidth, connection duration, only allowing peers that have communicated with the broker, rotating passwords) so that it doesn't get overloaded by outsiders. Conveniently, [Pion also offers a powerful TURN library](https://github.com/pion/turn) ([example](https://github.com/pion/turn/blob/v2.0.8/examples/turn-server/simple/main.go)).
Biggest problem - looks like the client has to tunnel the TURN traffic through a domain-fronting HTTPS (WSS?) tunnel (or some other censorship-resistant thing (#25594 )?) because the TURN server might be blocked. I'm not sure how hard it is to achieve, but here's [an example of traffic manipulation in Pion](https://github.com/pion/webrtc/blob/v3.1.47/examples/ice-single-port/main.go), so I guess it shouldn't be super hard.
So
Pros:
* Solves #22945
* Practically Solves #40164
* Solves the verification part of #40165 because it's not two different connections, it's the same one.
* Makes the broker more future-proof because it doesn't have to process data that the proxy and the client want to exchange, it simply passes it along.
* Can allow faster bootstrapping by relaying (non-signaling) proxy-to-client data initially, before true P2P has been established.
* (maybe, need to verify) better DPI resistance due to handshake being performed in a secure (domain-fronted) channel (see https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030).
Cons:
* The broker codebase needs a major overhaul.
[Some chat logs](https://matrix.to/#/!hNphRlWKcRVXnwAWJy:matrix.org/$EWgGZ38YotRK9zhqpMjBJo98wQo1HFapnLRXqzsBSCg?via=matrix.org&via=nitro.chat&via=systemli.org) (nothing particularly important).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40233package version 2.3 in debian2022-11-15T17:02:18Zmeskiomeskio@torproject.orgpackage version 2.3 in debianThe current version of snowflake-proxy in debian doesn't include the support for multiple bridges. It is only present in testing and sid, but people is complaining that their proxies are not working anymore. Let's upgrade the package.The current version of snowflake-proxy in debian doesn't include the support for multiple bridges. It is only present in testing and sid, but people is complaining that their proxies are not working anymore. Let's upgrade the package.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40232snowflake proxy README includes an old version of ./proxy --help2023-07-29T22:27:43ZRoger Dingledinesnowflake proxy README includes an old version of ./proxy --helpIn snowflake/proxy/README, we have this section:
```
The Snowflake proxy can be run with the following options:
Usage of ./proxy:
-broker string
broker URL (default "https://snowflake-broker.torproject.net/")
-capacity uint...In snowflake/proxy/README, we have this section:
```
The Snowflake proxy can be run with the following options:
Usage of ./proxy:
-broker string
broker URL (default "https://snowflake-broker.torproject.net/")
-capacity uint
maximum concurrent clients
-keep-local-addresses
keep local LAN address ICE candidates
-log string
log filename
-relay string
websocket relay URL (default "wss://snowflake.torproject.net/")
-stun string
stun URL (default "stun:stun.stunprotocol.org:3478")
-unsafe-logging
prevent logs from being scrubbed
```
but ./proxy --help now shows more options than that:
```
Usage of ./proxy:
-allow-non-tls-relay
allow relay without tls encryption
-allowed-relay-hostname-pattern string
a pattern to specify allowed hostname pattern for relay URL. (default "snowflake.torproject.net$")
-broker string
broker URL (default "https://snowflake-broker.torproject.net/")
-capacity uint
maximum concurrent clients
-ephemeral-ports-range string
ICE UDP ephemeral ports range (format:"<min>:<max>")
-keep-local-addresses
keep local LAN address ICE candidates
-log string
log filename
-nat-retest-interval duration
the time interval in second before NAT type is retested, 0s disables retest. Valid time units are "s", "m", "h". (default 24h0m0s)
-relay string
websocket relay URL (default "wss://snowflake.bamsoftware.com/")
-stun string
STUN URL (default "stun:stun.stunprotocol.org:3478")
-summary-interval duration
the time interval to output summary, 0s disables summaries. Valid time units are "s", "m", "h". (default 1h0m0s)
-unsafe-logging
prevent logs from being scrubbed
-verbose
increase log verbosity
```
The really simple fix would be to update the README with the newer text. The more robust approach would be to stop trying to maintain the same data in both places (because it's clearly not working), and change the README to teach you how to run ./proxy --help to get the usage, and/or change it to list just the most important options.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40231fix: client sometimes sends offer with no ICE candidates2024-03-21T20:25:28ZWofWcawofwca@protonmail.comfix: client sometimes sends offer with no ICE candidatesNot sure if it's normal.
This is what has been returned by the broker to a `/proxy` request:
```
{
"Status": "client match",
"Offer": "{\"type\":\"offer\",\"sdp\":\"v=0\\r\\no=- <SCRUBBED> <SCRUBBED> IN IP4 0.0.0.0\\r\\ns=-\\r\\nt=0...Not sure if it's normal.
This is what has been returned by the broker to a `/proxy` request:
```
{
"Status": "client match",
"Offer": "{\"type\":\"offer\",\"sdp\":\"v=0\\r\\no=- <SCRUBBED> <SCRUBBED> IN IP4 0.0.0.0\\r\\ns=-\\r\\nt=0 0\\r\\na=fingerprint:sha-256 <SCRUBBED>\\r\\na=extmap-allow-mixed\\r\\na=group:BUNDLE 0\\r\\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\\r\\nc=IN IP4 0.0.0.0\\r\\na=setup:actpass\\r\\na=mid:0\\r\\na=sendrecv\\r\\na=sctp-port:5000\\r\\na=ice-ufrag:<SCRUBBED>\\r\\na=ice-pwd:<SCRUBBED>\\r\\na=end-of-candidates\\r\\n\"}",
"NAT": "unrestricted",
"RelayURL": "wss://snowflake.torproject.net/"
}
```
Offer:
```
v=0
o=- <SCRUBBED> <SCRUBBED> IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 <SCRUBBED>
a=extmap-allow-mixed
a=group:BUNDLE 0
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=setup:actpass
a=mid:0
a=sendrecv
a=sctp-port:5000
a=ice-ufrag:<SCRUBBED>
a=ice-pwd:<SCRUBBED>
a=end-of-candidates
```
As you can see, it contains no ICE candidates. Also note the `a=end-of-candidates`. My Snowflake sent an answer but connection failed.
I have noticed this twice already.
Can this be due to the fact we're trying to filter out local network ICE candidates? And maybe STUN being blocked for the clients?itchyonionitchyonion