The Snowflake team has done a lot of work on “vertical” scaling of the snowflake-01 bridge, making the host capable of handling more concurrent users. They are also now doing “horizontal” scaling, by setting up a new snowflake-02 bridge to share the load. The second bridge is scheduled to be enabled in the next Tor Browser alpha release, 12.0a5, but you can test it yourself now, by entering a bridge line manually.

Short instructions: take any working Snowflake bridge line, and change the fingerprint 2B280B23E1107BB62ABFC40DDCC8824814F80A72 to 8838024498816A039FCBBAB14E6F40A0843051FA. There are two places where you need to change the fingerprint.

Longer instructions:

• In Tor Browser for desktop, go to ≡ (hamburger menu) → Settings → Connection → Bridges, then click the Add a Bridge Manually… button.
• In Tor Browser for Android, go to (settings) → Config Bridge. Toggle Use a Bridge to “on” and tap Provide a Bridge I know.
• Paste in the bridge line
  snowflake 192.0.2.4:80 8838024498816A039FCBBAB14E6F40A0843051FA fingerprint=8838024498816A039FCBBAB14E6F40A0843051FA url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ front=cdn.sstatic.net ice=stun:stun.l.google.com:19302,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=hellorandomizedalpn

To check if it’s working, you can check the Tor log for a new bridge descriptor line. flakeyN is the snowflake-01 bridge; crustyN is the snowflake-02 bridge.

[NOTICE] new bridge descriptor 'crusty3' (fresh): $8838024498816A039FCBBAB14E6F40A0843051FA~crusty3 [tO9nYvNCAdAh9lPoEEv2pZ9BJq+YzmPAMY6pxoFrLuk] at 192.0.2.4

The purpose of the second bridge is to increase capacity. It will not have any effect on blocking resistance. It does not change anything about broker interaction or the way the Snowflake client interacts with proxies.

We will likely need to restart the snowflake-02 bridge multiple times over the coming days for upgrades and configuration changes, so be aware there may be some disruption in availability.

The second Snowflake bridge is now part of the stable release 12.0.

To use it, you just have to select Snowflake from the Built-in Bridges menu. How it works is: both the snowflake-01 and snowflake-02 bridges will be activated when you choose Snowflake under “Select a Built-In Bridge…”. You can tell which bridge is being used for a circuit (in the URL bar). If the IP address is 192.0.2.3, it is the snowflake-01 bridge. If the IP address is 192.0.2.4, it is the snowflake-02 bridge. The IP addresses are just placeholder labels (the browser is not really connecting to those IP addresses).

Не работает на моем мобильном провайдере (и уже давно), у которого есть ТСПУ и DPI. Ждал 10 минут.

Я пробовал такие параметры:

ClientTransportPlugin snowflake exec snowflake-client -log snowflake-client.log -log-to-state-dir -unsafe-logging
Bridge snowflake 192.0.2.5:80 8838024498816A039FCBBAB14E6F40A0843051FA fingerprint=8838024498816A039FCBBAB14E6F40A0843051FA url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ front=cdn.sstatic.net ice=stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.stunprotocol.org:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478,stun:stun.l.google.com:19302 utls-imitate=hellorandomizedalpn

И такие:

ClientTransportPlugin snowflake exec snowflake-client -log snowflake-client.log -log-to-state-dir -unsafe-logging
Bridge snowflake 192.0.2.6:80 8838024498816A039FCBBAB14E6F40A0843051FA fingerprint=8838024498816A039FCBBAB14E6F40A0843051FA url=https://snowflake-broker.torproject.net/ ampcache=https://cdn.ampproject.org/ front=www.google.com ice=stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.stunprotocol.org:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478,stun:stun.l.google.com:19302 utls-imitate=hellorandomizedalpn

В логе тора много таких строк:

offer created
broker rendezvous peer received
timeout waiting for DataChannel.OnOpen

Один раз:

[warn] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (DONE; DONE; count 1; recommendation warn; host 8838024498816A039FCBBAB14E6F40A0843051FA at 192.0.2.5:80)
[warn] 1 connections have failed:
[warn] 1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE

В Wireshark много Binding request user

Лог snowflake-client.log https://pastebin.com/raw/CsW94rTr (где amp cache)

Под VPN всё это работает.

Почему не работает на моем провайдере? Блочится handshake, проблемы с NAT? Специалисты, подскажите. В snowflake-client.log должен же быть ответ.

Поскольку я указывал utls-imitate=hellorandomizedalpn, то может быть дело не в детекте отпечатков TLS, а проблема с NAT?
Но несколько месяцев назад на этом же провайдере snowflake работал.

UPD: Версия бинарников последняя, из Tor Browser 12.0. Система Linux.

Lately there has been some discussion that Snowflake may be partially blocked in Russia. But I have not really looked into it yet.

• [tor-project] Anti-censorship team meeting notes, 2022-12-15
• #tor-meeting log
  IRC log

  16:08:46 <ggus> meskio: shelikhoo: do you know what's the status of snowflake test on logcollector? hackerncoder was checking and it seems there was some issue in the russian vantage point?
  16:08:47 <shelikhoo> oh no... iran vps's connection to cloudflare is not working i/o timeout
  16:09:13 <cece[m]> meskio: same here
  16:09:14 <shelikhoo> I think it is the iran one that is having issue
  16:09:18 <meskio> shelikhoo: maybe cloudflare is censored in Iran :P
  16:09:38 <shelikhoo> and snowflake in russia is down as well
  16:09:41 <shelikhoo> oooo
  16:10:14 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/bridgestatus/-/blob/dcd157e608be92294a1bc3dd51c9bdbf444edb0f/recentResult_russia
  16:11:12 <meskio> I was looking at metrics.tpo and there doesn't seem to be much users of snowflake in russia
  16:11:18 <meskio> or maybe 0
  16:11:38 <meskio> but the number of tor users haven't gone down at all
  16:11:59 <meskio> so everybody have their own way to find bridges
  16:12:29 <meskio> circumvention settings is recommending snowflake in russia, I wonder if we should change that
  16:12:47 <shelikhoo> yes, but we should try to find a way to fix this in the near future
  16:12:59 <shelikhoo> before they find a way to block obfs4...
  16:13:07 <ggus> i think that during the protests in iran, many users in russia migrated from snowflake to obsf4, because the bridge was too overloaded/slow
  16:13:35 <ggus> meskio: +1
  16:14:05 <meskio> cool, I'll make the change
  16:14:18 <itchyonion> What does the second column (number) represent in the bridgestatus lines? Success rate?
  16:14:30 <meskio> yes, we should investigate if snowflake is blocked in russia, but not sure if we can realistically do that before january
  16:14:33 <shelikhoo> it is bootstrap percentage
  16:14:42 <itchyonion> ah ok
  16:14:46 <shelikhoo> should be 100 when tor works
  16:16:38 <meskio> BTW, there are still more than double of users connecting to Tor directly than over a bridge
  16:16:50 <meskio> ~100k direct connections, ~40k bridges, ...
  16:16:56 <meskio> I mean in russia
  16:18:05 <shelikhoo> yes. I think one of the reason for that they only block tor on residential network
  16:18:14 <shelikhoo> not on IDC network
  16:18:18 <meskio> yep
  16:18:23 <ggus> it depends on where they deployed tspu
  16:19:36 <ggus> fyi: today the tor project lost the appeal to 'unblock tor' in russia. rks lawyers will appeal again: https://roskomsvoboda.org/post/tor-ne-proshel-apelliatsiyu/ (in RU)
  16:21:05 <meskio> does unblock tor mean the website?
  16:21:22 <meskio> or are did we manage to ask legally to unblock the tor network?
  16:23:39 <meskio> ggus: -^?
  16:24:43 <ggus> meskio: we didn't manage to ask legally to unblock the tor network because they never confirmed doing that. the process is about tor website and app stores
  16:26:00 <ggus> sooo gettor may get more russian users in the nearby future
  16:26:11 <shelikhoo> I think this is mostly a
  16:26:19 <meskio> uff, I see
  16:26:37 <meskio> the snowflake block might be https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030
  16:26:56 <shelikhoo> I think this is mostly a symbolic legal flight?
  16:27:12 <shelikhoo> but it should worth it
  16:28:48 <meskio> +1
  16:28:56 <itchyonion> Anything else on this topic?
  16:29:08 <ggus> meskio: shelikhoo: i think i will close this ticket: https://gitlab.torproject.org/tpo/community/support/-/issues/40050 and then we can open a new again about the snowflake block in russia? or should we keep it open until we defeat tor censorship in russia like a historical artifact? :D
  16:30:16 <shelikhoo> I think we could add the date or a year to ticket and create a ticket for next round of censorship
  

I can see that there are still connections from Russia. It is #4 ranked by number of users still. But it could be that it was blocked in some but not all ISPs in Russia, and with the giant number of users in Iran we did not notice.

dirreq-stats-end 2022-12-18 07:00:35 (86400 s)
dirreq-v3-reqs ir=38168,us=11000,??=4544,ru=1504,cn=968,de=368,mu=240,...

@anon94384997 it looks like in your case, Snowflake is blocked by DTLS, which is how it was done in December 2021. See also IRC Tip about Signature used to block Snowflake in Russia, 2022-May-16 (#40030) · Issues · The Tor Project / Anti-censorship / censorship-analysis · GitLab.

There are several steps to a Snowflake connection:

1. Contact STUN server and construct offer. (Working for you.)
2. Send offer to broker and receive answer using TLS domain fronting / AMP cache. (Working for you.)
3. Peer-to-peer DTLS connection with proxy. (This is probably the step that is not working for you.)

The evidence that (1) is working is WebRTC: Created offer. The evidence that (2) is working is Received answer: {"answer":… The evidence that (3) is not working is WebRTC: timeout waiting for DataChannel.OnOpen.

Спасибо за инфу.
На моем провайдере (Yota) snowflake был заблокирован где-то между 8 Feb 2022 и 19 Jul 2022.
По моим наблюдениям, 7 Feb 2022 snowflake работал. 19 Jul 2022 уже не работал. В эти промежутки в основном работал.
Значит, это не исправить теперь?

Конечно, большинство провайдеров не такие продвинутые, как мобильные.

19 Jul roughly agrees with the date that @anonymous51 reported problems caused by HelloVerifyRequest (2022-07-20).

• In case Snowflake rendezvous gets blocked - #9 by anonymous51
• IRC Tip about Signature used to block Snowflake in Russia, 2022-May-16 (#40030) · Issues · The Tor Project / Anti-censorship / censorship-analysis · GitLab

Indeed it seems the team has been neglecting this. What it will take is a change in pion/dtls, like the ones we did earlier:

• Do not include IP addresses as SNI values by cohosh · Pull Request #407 · pion/dtls · GitHub
• Only include supported_groups extension in ClientHello by cohosh · Pull Request #410 · pion/dtls · GitHub
• Shuffle Elliptic Curves in ClientHello to circumvent Russian censorship by ValdikSS · Pull Request #474 · pion/dtls · GitHub

Возможно в мобильном трафике нет столько сессий, которые надо сопровождать в ожидании байт похожих на snowflake. И еще мобильные сети были приоритетным направлением для блокировок, а значит там есть оперативный запас мощностей.

Сейчас наблюдается оптимизация блокировок по диапазонам IP адресов, вплоть до динамического отключения/ограничения трекинга сессий. Поведение похожее на перегруз в прошлом, но теперь рукотворный и управляемый.

Pion останется белой вороной.
С другой стороны, переход обратно на libwebrtc в официальном приложении все равно приведет в финале к блокировке webrtc целиком или по частям.

Today, @Shelikhoo merged a change to stop sending Hello Verify Request. This may overcome Snowflake blocking by DTLS fingerprint in some ISPs in Russia.

It is not present in any release yet, but you can test it manually. You need commit 10fd00068528fd6309bbb49f9dd0fea38f1ac5ef or later. The expected output is Bootstrapped 100% (done).

$ git clone https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake.git
$ cd snowflake/client
$ go build
$ tor -f torrc

Thank you for your work.
I was only able to connect once. The next time there were problems.

I used 2B280B23E1107BB62ABFC40DDCC8824814F80A72 (not new 8838024498816A039FCBBAB14E6F40A0843051FA), without option utls-imitate=hellorandomizedalpn and clear Tor cache (data folder) before each startup.

GOOD:
tor log https://pastebin.com/raw/sQMm0zwR
snowflake log https://pastebin.com/raw/q6v8ix9J

BAD:
tor log https://pastebin.com/raw/aKr4aYLR
snowlake log https://pastebin.com/raw/tRMgT3ag

Under VPN it works.

UPD1: With 8838024498816A039FCBBBB14E6F40A0843051FA and utls-imitate=hellorandomizedalpn the same errors.
UPD2: I compiled and tested the new version, not the old one.

@anon94384997 Thanks for testing. It appears there was a problem with commit 10fd00068528fd6309bbb49f9dd0fea38f1ac5ef that prevented the intended commit from working. Please try again with commit 7b77001eaa90e09d41172a2b170dabd3f1922b4a or later (tag v2.5.1).

Yes, it works now. Finally. Tried 4 times. snowlake last git. Thanks.

1. https://pastebin.com/raw/WZW0Dqnr
2. https://pastebin.com/raw/wAyK9Uu9
3. https://pastebin.com/raw/eS7F8AZK

The fix is now released in Tor Browser 12.0.3. Please try it if you are in Russia and Snowflake was not working for you.

Ремонт занял 9 месяцев. Проработает месяц, в лучшем случае.