Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2024-02-14T14:59:35Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25593Broker needs better resilience against DoS2024-02-14T14:59:35ZArlo BreaultBroker needs better resilience against DoSMigrated from https://github.com/keroserene/snowflake/issues/25Migrated from https://github.com/keroserene/snowflake/issues/25Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25595Test suite for Snowflake on various NAT topologies2023-08-01T23:45:54ZArlo BreaultTest suite for Snowflake on various NAT topologiesMigrated from https://github.com/keroserene/snowflake/issues/20Migrated from https://github.com/keroserene/snowflake/issues/20max-bmax-bhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25594Broker: investigate non-domain-fronting secure client / proxy registrations2024-02-27T18:55:26ZArlo BreaultBroker: investigate non-domain-fronting secure client / proxy registrations> Pasting discussion from email,
>
>> in the Flashproxy case, registration wasn't
>> bidi, and I think they imagined using insecure
>> channels to register like OSSes. In Snowflake,
>> the client is making TLS connections with the
>> bro...> Pasting discussion from email,
>
>> in the Flashproxy case, registration wasn't
>> bidi, and I think they imagined using insecure
>> channels to register like OSSes. In Snowflake,
>> the client is making TLS connections with the
>> broker, which amounts to the same thing as
>> encrypting the payload with the facilitator's
>> public key.
>
> Also,
>
>> There's also the case where an adversary DOSes the facilitator with a
>> bunch of fake client or proxy registrations and things like that.
>
> This is now legacy/trac#25593
>
>> Also, there is the potential that in the future we might need some
>> sort of non-domain-fronting rendezvous. It seems that right now we
>> have an ecosystem of tools growing that assumes domain-fronting will
>> always be available & effective. May be worth considering how to
>> prepare for regions where this might not work as well in the future.
>
> So this ticket should probably be for that.
\\ Migrated from https://github.com/keroserene/snowflake/issues/13
Ideas that have been proposed or done:
* #25985 AMP cache
* #25874 DNS
* #26151 Amazon SQSDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40015Investigate high retransmission rate of Snowflake2022-03-01T19:17:35ZCecylia BocovichInvestigate high retransmission rate of SnowflakeThe recent report on Snowflake distinguishability caught the fact that Snowflake has a very high rate of retransmissions during the handshake: https://arxiv.org/pdf/2008.03254.pdf
This was reported to cause latency and it sounds like a ...The recent report on Snowflake distinguishability caught the fact that Snowflake has a very high rate of retransmissions during the handshake: https://arxiv.org/pdf/2008.03254.pdf
This was reported to cause latency and it sounds like a bug. It could also apply to the rest of the connection after the handshake. We should look into this.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30498Proxy-go is receiving a lot of client timeouts2023-08-01T23:44:35ZCecylia BocovichProxy-go is receiving a lot of client timeoutsSome proxy-go instances are experiencing what seems like an unusually high number of client timeout errors.Some proxy-go instances are experiencing what seems like an unusually high number of client timeout errors.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25681Defend against flooding of the broker by low bandwidth snowflakes2024-02-14T14:59:36ZcypherpunksDefend against flooding of the broker by low bandwidth snowflakesAn adversary may attempt to flood the broker by thousands of low bandwidth snowflakes, as a result users will have a higher chance of happening on them thereby deteriorating their experience.
Maybe there should be some way to ensure tha...An adversary may attempt to flood the broker by thousands of low bandwidth snowflakes, as a result users will have a higher chance of happening on them thereby deteriorating their experience.
Maybe there should be some way to ensure that their bandwidth is higher than some level before they can be distributed by the broker.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31661Run multiple snowflake bridges and optimize for least latency most throughput...2022-07-25T17:59:44ZcypherpunksRun multiple snowflake bridges and optimize for least latency most throughput by GeoIP based route selectionAfter the publication of this [article](https://gigazine.net/news/20190812-tor-snowflake/) hundreds of Japanese people started installing the Snowflake WebExt (yay!), but despite having an Internet service that's orders of magnitudes bet...After the publication of this [article](https://gigazine.net/news/20190812-tor-snowflake/) hundreds of Japanese people started installing the Snowflake WebExt (yay!), but despite having an Internet service that's orders of magnitudes better than the average American household, the distance between then and the `nl` snowflake bridge seriously impacts the throughput, so much that some snowflake proxies from Japan - despite having more than 20MB/s upload/download - can't offer a download speed bigger than 150KiB/s. What if there were for instance 5 snowflake bridges in different geographical locations in the world and the broker associated with each snowflake proxy the nearest snowflake bridge and sent this information to the user (based on GeoIP, of course, not perfect but better than the status quo)?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40071Increase of "unknown" NAT assignments by probetest since 2021-10-252023-06-20T18:24:54ZDavid Fifielddcf@torproject.orgIncrease of "unknown" NAT assignments by probetest since 2021-10-25https://lists.torproject.org/pipermail/anti-censorship-team/2021-October/000197.html
> ...looking into the broker graphs there is something weird since 2 days. The number of proxies with 'unknown' type of nat has rised heavily at the sam...https://lists.torproject.org/pipermail/anti-censorship-team/2021-October/000197.html
> ...looking into the broker graphs there is something weird since 2 days. The number of proxies with 'unknown' type of nat has rised heavily at the same time the 'restricted' nat has gone down. There are long periods without idle proxies and many requests being denied of nat type uknown. It doesn't look like the proxy capacity has gone down, can it be something broken on the way we test the nat type?
It seems that something is going wrong with probetest. A past problem we had with probetest not functioning properly was #40039. Currently the probetest process is again using 100% CPU.
It is possible this is some kind of slow resource exhaustion, or it's possible that probetest is simply overloaded with the number of proxies we have currently. At the [2021-10-28 anti-censorship team meeting](http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-10-28-16.00.log.html#l-51) we decided to restart probetest and watch it to see how quickly it returns to its failure state, in order to distinguish these two possibilities.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25723Multiplex - one client splits traffic across multiple proxies2024-02-27T18:57:33ZDavid Fifielddcf@torproject.orgMultiplex - one client splits traffic across multiple proxiesThis is the dual of legacy/trac#25601.
It would be a great feature if a client could be connected to multiple snowflake proxies at once, and split traffic across all of them. Like the [Conflux](http://cacr.uwaterloo.ca/techreports/2013/...This is the dual of legacy/trac#25601.
It would be a great feature if a client could be connected to multiple snowflake proxies at once, and split traffic across all of them. Like the [Conflux](http://cacr.uwaterloo.ca/techreports/2013/cacr2013-16.pdf) proposal for Tor. It would be a hedge against getting assigned a single slow proxy.
This would require interposing some kind of sequencing and reliability layer, with possible retransmissions.
A potential benefit for privacy is that an individual snowflake proxy only sees a subset of a client's traffic flow.
However, instantly making _N_ WebRTC connections is a tell for traffic classification.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31847Expand contribution guidelines for snowflake2022-03-01T15:55:52ZCecylia BocovichExpand contribution guidelines for snowflakeWe're getting more contributors to the project, we should expand CONTRIBUTING.md with some more basic guidelines like
- formatting of commit messages
- creating tickets for each pull request
- make sure the changes in the commit adhere t...We're getting more contributors to the project, we should expand CONTRIBUTING.md with some more basic guidelines like
- formatting of commit messages
- creating tickets for each pull request
- make sure the changes in the commit adhere to the commit message and the corresponding tickethttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40057A weird issue about domain name resolution2022-03-01T15:55:27Zdebug996A weird issue about domain name resolutionDevelopers of Snowflake,
I have trouble to use the snowflake bridge to connect to Tor. To find out the main issue, I managed to collect the log of snowflake. (attached below)
It can be seen that the snowflake program tries to resolve h...Developers of Snowflake,
I have trouble to use the snowflake bridge to connect to Tor. To find out the main issue, I managed to collect the log of snowflake. (attached below)
It can be seen that the snowflake program tries to resolve host names from [::1]:53, but there is no dns server listening, nor is there a statement for [::1]:53 in /etc/resolv.conf .
```
--- Starting Snowflake Client ---
2021/07/24 07:12:11 Using ICE servers:
2021/07/24 07:12:11 url: stun:stun.sonetel.com:3478
2021/07/24 07:12:11 url: stun:stun.stunprotocol.org:3478
2021/07/24 07:12:11 url: stun:stun.dus.net:3478
2021/07/24 07:12:11 url: stun:stun.uls.co.za:3478
2021/07/24 07:12:11 url: stun:stun.voip.blackberry.com:3478
2021/07/24 07:12:11 url: stun:stun.sonetel.net:3478
2021/07/24 07:12:11 url: stun:stun.bluesip.net:3478
2021/07/24 07:12:11 Rendezvous using Broker at: https://snowflake-broker.torproject.net.global.prod.fastly.net/
2021/07/24 07:12:11 Domain fronting using: cdn.sstatic.net
2021/07/24 07:12:11 Started SOCKS listener at 127.0.0.1:39363.
2021/07/24 07:12:11 Error resolving address: lookup stun.sonetel.com on [::1]:53: read udp [::1]:60448->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error creating STUN connection: lookup stun.sonetel.com on [::1]:53: read udp [::1]:60448->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error resolving address: lookup stun.stunprotocol.org on [::1]:53: read udp [::1]:46030->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error creating STUN connection: lookup stun.stunprotocol.org on [::1]:53: read udp [::1]:46030->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error resolving address: lookup stun.dus.net on [::1]:53: read udp [::1]:46841->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error creating STUN connection: lookup stun.dus.net on [::1]:53: read udp [::1]:46841->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error resolving address: lookup stun.uls.co.za on [::1]:53: read udp [::1]:51689->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error creating STUN connection: lookup stun.uls.co.za on [::1]:53: read udp [::1]:51689->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error resolving address: lookup stun.voip.blackberry.com on [::1]:53: read udp [::1]:51608->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error creating STUN connection: lookup stun.voip.blackberry.com on [::1]:53: read udp [::1]:51608->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error resolving address: lookup stun.sonetel.net on [::1]:53: read udp [::1]:35863->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error creating STUN connection: lookup stun.sonetel.net on [::1]:53: read udp [::1]:35863->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error resolving address: lookup stun.bluesip.net on [::1]:53: read udp [::1]:42763->[::1]:53: read: connection refused
2021/07/24 07:12:11 Error creating STUN connection: lookup stun.bluesip.net on [::1]:53: read udp [::1]:42763->[::1]:53: read: connection refused
2021/07/24 07:12:11 NAT Type: unknown
2021/07/24 07:12:11 SOCKS accepted: {192.0.2.3:1 map[]}
2021/07/24 07:12:11 ---- SnowflakeConn: begin collecting snowflakes ---
2021/07/24 07:12:11 ---- SnowflakeConn: starting a new session ---
2021/07/24 07:12:11 ---- SnowflakeConn: begin stream 3 ---
2021/07/24 07:12:11 redialing on same connection
2021/07/24 07:12:11 WebRTC: Collecting a new Snowflake. Currently at [0/1]
2021/07/24 07:12:11 snowflake-c33c6e11b0e8bdf9 connecting...
2021/07/24 07:12:11 WebRTC: DataChannel created.
2021/07/24 07:12:11 WebRTC: Created offer
2021/07/24 07:12:11 WebRTC: Set local description
2021/07/24 07:12:11 WebRTC: PeerConnection created.
2021/07/24 07:12:11 Negotiating via BrokerChannel...
Target URL: snowflake-broker.torproject.net.global.prod.fastly.net
Front URL: cdn.sstatic.net
2021/07/24 07:12:11 WebRTC: closing DataChannel
2021/07/24 07:12:11 WebRTC: closing PeerConnection
2021/07/24 07:12:11 WebRTC: Closing
2021/07/24 07:12:11 WebRTC: dial tcp: lookup cdn.sstatic.net on [::1]:53: read udp [::1]:41939->[::1]:53: read: connection refused Retrying...
2021/07/24 07:12:21 WebRTC: Collecting a new Snowflake. Currently at [0/1]
2021/07/24 07:12:21 snowflake-07b5e298791ef573 connecting...
2021/07/24 07:12:21 WebRTC: DataChannel created.
2021/07/24 07:12:21 WebRTC: Created offer
2021/07/24 07:12:21 WebRTC: Set local description
2021/07/24 07:12:21 WebRTC: PeerConnection created.
2021/07/24 07:12:21 Negotiating via BrokerChannel...
Target URL: snowflake-broker.torproject.net.global.prod.fastly.net
Front URL: cdn.sstatic.net
2021/07/24 07:12:21 WebRTC: closing DataChannel
2021/07/24 07:12:21 WebRTC: closing PeerConnection
2021/07/24 07:12:21 WebRTC: Closing
2021/07/24 07:12:21 WebRTC: dial tcp: lookup cdn.sstatic.net on [::1]:53: read udp [::1]:40102->[::1]:53: read: connection refused Retrying...
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40064How to manage CPU saturation?2022-04-05T15:23:39ZJacobo NájeraHow to manage CPU saturation?Hi,
For several months I have been running various snowflake proxies with the standalone version. On two occasions I identified CPU saturation. I currently have a snowflake proxy that consumes between 90% and 100% CPU.
CPU usage
![Ca...Hi,
For several months I have been running various snowflake proxies with the standalone version. On two occasions I identified CPU saturation. I currently have a snowflake proxy that consumes between 90% and 100% CPU.
CPU usage
![Captura_de_pantalla_de_2021-08-29_22-08-45](/uploads/b6af9f8067d28e058559538e3d583c7e/Captura_de_pantalla_de_2021-08-29_22-08-45.png)
Connections
![Captura_de_pantalla_de_2021-08-30_23-28-50](/uploads/285a0f49645210e8beedb55b7e4d439d/Captura_de_pantalla_de_2021-08-30_23-28-50.png)
Software setup
- Docker image thetorproject/snowflake-proxy:latest
- Debian Buster
How to manage CPU saturation?
Thanks, Jacobohttps://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.