A post was split to a new topic: Tor relays to help censored users
Thanks for running a proxy. There were a few hours when the bridge was not working because it was running out of memory. We have deployed some optimizations that have the situation under control for now.
Ichi on the Work:v:t3:
Is there any stats to show which method of obfd4 proxy distribution (Moat, https, etc…) is more accessible to Iranians? I can change the distribution method of all my bridges to that method.
Is there any way to dedicate a bunch of bridges exclusively to the Iranian population?
My understanding is that due to the massive demonstrations against the regime that are ongoing in Iran for the past 12 days, the government shuts down all mobile Internet and severely restricts home Internet connections at around 12:30 UTC (16:00 IRDT) every day to prevent people from organizing their gatherings which usually start at around 17:00 IRDT and to stop all communications between protesters.
More than 1200 people have been arrested and over 50 people have been killed during these protests. Providing the Internet access for Iranians right now is of the utmost importance to make sure the news and videos of the atrocities of the regime can get out and be distributed.
In recent days a few of my friends have tried using the Snowflake bridge mostly to no avail, few times they succeeded in connecting, the speed was unusably slow. I initially thought it might be an issue with rendezvous process (since the technical write up on Snowflake indicates using google’s domain fronting, and at times even access to google is blocked in Iran), but testing myself (in Germany) I also got exceedingly slow speeds.
Is the slow speed related to number of active Snowflake proxies? I.e. if a lot more people were to run the Snowflake WebExtension, would it alleviate the speed issue?
Are there ways to overcome the potential issues with the rendezvous process as well? For example it might be possible to acquire servers in Iran with less restricted access and utilise them on this front, I suspect if the traffic they consume is low (which, for the rendezvous process it should be theoretically) it might be possible to keep them running under the radar.
The slow speed has mainly to do with resource overload at the bridge, which the anti-censorship team is working on. There is also a little bit of a problem with having sufficient proxies with unrestricted NATs.
At Graphs of user counts from Iran since the onset of shutdowns you can see how the number of Snowflake users has increased in the last few days. In the below graph you can see how bandwidth at the bridge has increased. The blue lines show where the server was restarted for upgrades; you can see what specifically happened at the Metrics Timeline. If you test during the times when the bridge is not overloaded, around 02:00 UTC, you will find that speeds are faster.
Here is more information about the work that has been done and the work that is in progress to keep the bridge running under the greatly increased load:
- [anti-censorship-team] Need to increase number of tor instances on snowflake-01 bridge, increased usage since yesterday and other messages in the thread
- Profile snowflake-server and attempt to reduce CPU and heap usage
- Increase number of tor instances from 4 to 8 on snowflake-01 bridge
- Deploy snowflake-server performance improvements 2022-09-23
- Deploy further snowflake-server performance improvements 2022-09-24
- Increase number of tor instances from 8 to 12 on snowflake-01 bridge
- snowflake-01 planned hardware maintenance (installed more RAM)
- Handle unknown client NAT type better to reduce load on restricted proxy pool
- Reduce turbotunnel queueSize from 2048 to 512
- snowflake-01: Connect the other NIC and move wireguard and sshd to it
Update: A Turkish version of the post.
2 posts were split to a new topic: How can I use Snowflake with tor (service)?
There is evidence that Snowflake is being partially blocked in Iran by its TLS fingerprint. Not all TLS fingerprints are blocked: the fingerprint most commonly used on desktop versions of Tor Browser works, but the fingerprint most commonly used on mobile versions is blocked.
The recently released Tor Browser 11.5.4 has support for disguising the TLS fingerprint of Snowflake. The support is not enabled by default, and there is no simple or automatic way to enable it: you have to edit a bridge line. You can help us by testing uTLS fingerprints in Tor Browser for Android and reporting whether they work. We will use the test results to make enabling uTLS easier and more automatic in future releases, and make it work in Orbot as well.
The change you are making to the default bridge line is adding
Get Tor Browser 11.5.4. There are instructions earlier in the thread.
If you have trouble downloading, you can contact
Go to where Tor Browser lets you enter a bridge address ( Settings icon → Config Bridge → Use a Bridge → Provide a Bridge I know). Copy and paste the following bridge line:
snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ front=cdn.sstatic.net ice=stun:stun.voip.blackberry.com:3478,stun:stun.altar.com.pl:3478,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.sonetel.net:3478,stun:stun.stunprotocol.org:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478 utls-imitate=hellochrome_auto
Click OK and go back to the main browser screen.
Now Tor Browser should connect over Snowflake. If it works, within about a minute the normal browser interface will appear. If it fails, the Settings screen will show “Is Tor Ready: No” and “State: Connecting”, and the Tor log (swipe left on the main screen) will say “general SOCKS server failure”.
You can experiment with different settings of
utls-imitate in the bridge line:
There is also a
hellofirefox_auto setting, but it did not work for me in Android on ARM: the Tor log says “server selected unsupported group”.
EDIT 2022-10-17: Fixed the bridge line in step 2. It originally specified the alternative Azure domain front in addition to the
utls-imitate change. It was meant to only have the
Does enabling uTLS have any performance impact?
I don’t know if performance impact has ever been measured. It’s not the kind of thing I would expect to affect performance. I suppose it could cause the selection of ciphersuites that are less optimized for a given platform.
All three are working with no errors - TB for Mac
10/18/22, 04:43:45.786 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
10/18/22, 04:43:45.790 [NOTICE] Opening Socks listener on 127.0.0.1:9150
10/18/22, 04:43:45.790 [NOTICE] Opened Socks listener connection (ready) on 127.0.0.1:9150
10/18/22, 04:43:46.793 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
10/18/22, 04:43:46.794 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
10/18/22, 04:43:46.795 [NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
10/18/22, 04:43:47.262 [NOTICE] Managed proxy “PluggableTransports/snowflake-client”: offer created
10/18/22, 04:43:48.188 [NOTICE] Managed proxy “PluggableTransports/snowflake-client”: broker rendezvous peer received
10/18/22, 04:43:49.856 [NOTICE] Managed proxy “PluggableTransports/snowflake-client”: connected
10/18/22, 04:43:50.860 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay
10/18/22, 04:43:50.312 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done
10/18/22, 04:43:50.313 [NOTICE] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
10/18/22, 04:43:50.313 [NOTICE] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
10/18/22, 04:43:51.298 [NOTICE] Bootstrapped 100% (done): Done
10/18/22, 04:43:51.355 [NOTICE] New control connection opened from 127.0.0.1.
10/18/22, 04:43:58.248 [NOTICE] New control connection opened from 127.0.0.1.
10/18/22, 05:10:34.398 [NOTICE] New control connection opened from 127.0.0.1.
10/18/22, 05:10:42.827 [NOTICE] New control connection opened from 127.0.0.1.
10/18/22, 05:13:45.674 [NOTICE] New control connection opened from 127.0.0.1.
A beta release of Orbot for Android enables TLS camouflage. This may be enough to unblock Orbot in Iran.
To try it, download and install the APK, tap Use Bridges on the main screen, then Connect through other Tor users using Snowflake (Method 1 or Method 2), then go back to the main screen, and Start. There is no separate step needed to enable uTLS.
This release also makes it possible to see the snowflake-client log. If there’s a failure to connect, it will help us figure out what is going wrong. Enable Settings → Debug Log, then go back to the main screen and Start. Tap on a status message to show the tor log, then tap the snowflake icon to view the snowflake-client log.
Tor browser 11.0.14 was working perfectly but after update to latest version today it stop to connect to any bridges. i had a backup of old version i installed old one and it connect normally. but latest version not connect at all. whats problem with new version ?
Os: Linux mint 64
@xrad, have you been using snowflake? This might be related to the issue preventing Snowflake from connecting in Tor Browser 11.5.5, see: New Release: Tor Browser 11.5.5 (Android, Windows, macOS, Linux) - #3 by championquizzer
Please upgrade to 11.5.6.
update to 11.5.6 solved the problem. tnx
A post was split to a new topic: Snowflake proxies for Iran