Snowflake is known for using WebRTC, but there is a phase called rendezvous before the WebRTC phase. The rendezvous phase and the WebRTC may be attacked separately. In case the default rendezvous (based on domain fronting) is blocked, there is a backup. But there is no easy way to enable the backup: you have to edit a configuration file.
Open the Tor Browser folder and find the torrc-defaults file:
Snowflake, как известно, использует технологию WebRTC. Но перед фазой WebRTC есть фаза, которя называется rendezvous. Фазы rendezvous и WebRTC могут быть атакованы по отдельности. В случае, если rendezvous используемый по умолчанию (основанный на доменном прикрытии) будет заблокирован, есть запасной вариант. Но не существует простого способа включить резервный процесс: необходимо отредактировать файл конфигурации.
Для этого откройте папку Tor Browser и найдите используемый по умолчанию файл torrc:
Оставьте все остальные опции без изменений. Затем запустите Tor Browser и настройте его на использование Snowflake в качестве моста. Это можно сделать здесь: about:preferences#tor.
Вместо -front www.google.com вы можете использовать другие доменты Google.
Для получения дополнительной отладочной информации вы можете добавить в файл torrc следующий код -log snowflake.log -log-to-state-dir. Так логи будут сохраняться в файле с названием snowflake.log.
При автоматическом обновлении браузера Tor файл torrc будет перезаписан на вариант, который используется браузером по умолчанию, поэтому все описанные выше изменения нужно будет вносить снова.
Мне кажется, snowflake заблокировали или проблемы только у меня? Проверьте, если не трудно.
2022-07-18T18:23:46.259Z
anon94384997
А чего все молчат? По моим наблюдениям, заблокировали все-таки snowflake. На уровне dtls (webrtc) протокола. Версия свежая, под VPN соединяется, напрямую нет. Метод выше тоже пробовал. Siberia, Yota.
Tor:
10:10:28 Bootstrapped 1% (conn_pt): Connecting to pluggable transport
10:10:28 Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
10:10:28 Bootstrapped 10% (conn_done): Connected to a relay
10:10:36 snowflake-client: offer created
10:10:38 snowflake-client: broker rendezvous peer received
10:10:48 snowflake-client: connection failed timeout waiting for DataChannel.OnOpen
10:10:53 snowflake-client: offer created
10:10:54 snowflake-client: broker rendezvous peer received
10:11:04 snowflake-client: connection failed timeout waiting for DataChannel.OnOpen
10:11:09 snowflake-client: offer created
10:11:11 snowflake-client: broker rendezvous peer received
10:11:21 snowflake-client: connection failed timeout waiting for DataChannel.OnOpen
…
10:12:15 snowflake-client: offer created
10:12:16 snowflake-client: broker rendezvous peer received
10:12:26 snowflake-client: connection failed timeout waiting for DataChannel.OnOpen
10:12:28 Delaying directory fetches: No running bridges
…
10:15:28 Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (DONE; DONE; count 1; recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 192.0.2.3:1)
10:15:28 1 connections have failed:
10:15:28 1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
10:15:28 Pluggable Transport process terminated with status code 0
Оффтоп: Похоже, meek тоже заблокирован. Работает только самосборная standalone версия с нестандартными параметрами, конечно, очень медленно.
И Psiphon стал медленней работать (соединяется по HTTPS 443).
По tor metrics уменьшения числа пользователей snowflake в России не замечено. Наверное, это только на провайдерах с ТСПУ.
UDP packets matching the pattern ^\x16\xfe[\xfd\xff].{X}\x00\x1d\x00\x17\x00\x18 are getting blocked, where X is a small number of enumerated byte offsets, and \x00\x1d\x00\x17\x00\x18 is the supported_groups extension. One of the offsets happens to match where pion/dtls places the extension in its Client Hello.
Concise description of the current situation: snowflake connections are blocked when either peer in the connection is Pion-based (e.g. snowflake-client or proxy-go) and takes the role of the DTLS client.
Put another way, the connection is ok if: the proxy is a browser proxy (not proxy-go) and snowflake-client operates as a DTLS server, not client
Ростелеком+ТСПУ, прямо сейчас (2022-07-19T21:12:00Z) первый раз подключился медленно (около минуты), второй и третий разы уже быстро.
2022-07-19T21:14:22.366Z
anonymous50(anonymous50)
С тестовой сборкой snowflake-client?
2022-07-20T07:31:29.466Z
ValdikSS
Нет, с обычным Tor Browser 11.5.
2022-07-20T08:48:06.257Z
anonymous51(anonymous51)
Блокировку Сlient Hello убрали, теперь блокируют Hello Verify Request
Snowflake будет работать только если вашим пиром будет браузерная версия прокси и snowflake клиент будет DTLS Client’ом.
Брокер выдает пир с рестриктивным NAT’ом пиру с не рестриктивным.
Браузерную версию прокси чаще запускают за NAT’ом, а standalone на белом адресе.
Если ваш snowflake клиент за рестриктивным NAT’ом (им может оказаться даже ваш домашний маршрутизатор), вашим пиром с большей вероятностью будет standalone прокси.
2022-07-20T11:34:41.555Z
tango
Do you happen to know the specific fingerprint inside Hello Verify Request? Or just the fact that it is sent at all?
MacMillan et al. had reported the Hello Verify Request vulnerability:
Do not send the optional Client Hello and Hello Verify Request from the DTLS handshake
2022-07-21T18:09:11.208Z
anonymous53(anonymous53)
Directions: Both
Datagram size: 30h 16 FE [FD or FF] offset: 00h 03 offset: 0Dh
2022-07-21T18:23:30.375Z
ValdikSS
Can confirm, this pattern is filtered, thanks.
2022-07-21T19:42:36.414Z
oct21
snowflake странно работает. Подключение есть в дестктопной версии тор бразуера под windows. Но нет подключения в linux, если запустить тор службу через cli и настроить мост в torrc. Мой конфиг в torrc:
UseBridges 1
ClientTransportPlugin snowflake exec /opt/snowflake/client/client
Bridge snowflake 192.0.2.3:1 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
две строчки, которыми спами тор:
[notice] Managed proxy “/opt/snowflake/client/client”: broker failure dial tcp [scrubbed]: connect: no route to host
[notice] Managed proxy “/opt/snowflake/client/client”: offer created
служба застревает на 10%.
2022-07-24T19:39:14.320Z
anonymous55(anonymous55)
Зачем передавать аргументы динамически?
Лучше так:
no route to host
Нужно смотреть куда резольвит front и где маршрут обрывается.
2022-07-24T20:06:30.593Z
anon94384997
Я не уверен, что дело в этом, но не мешает ли вам apparmor? В случае использования debian, ubuntu или opensuse.
Я слышал, что в файл /etc/apparmor.d/abstractions/tor нужно добавить строчку /usr/bin/snowflake-client ix, и перезагрузиться.
Лично у меня нет ошибки no route to host на линуксе. Хотя, в последнее время запускаю tor не как службу, а от юзера. Просто бинарники из тор браузера достал и скопировал в ~/tor. Чтобы не следить за свежестью пакета.
Но когда tor и snowflake запускались системно, подобных ошибок тоже не было.
Кстати, blackberry и altar.com.pl недоступны в России. antisip и sonetel вроде тоже.
2022-07-24T20:54:19.120Z
anonymous56(anonymous56)
Терминология запутывает. Snowflake называет рестриктивными (в терминах snowflake) симмертичные (в терминах NAT), там где внешний адрес или порт будут разными для разных адресов назначения. Такое упрощение, например, делает невозможной связь симметричного и рестриктивного (в терминах NAT) пиров.
Мне не удалось воспроизвести успешного подключения даже при условии получение ответа от браузерной прокси (общее соотношение доступных сейчас webext и standalone прокси 1:12), браузер выбирает роль DTLS клиента. Что логично, иначе правила блокировки были бы другими.
2022-07-25T09:54:23.949Z
anon94384997
Как вообще надежней всего определить тип NAT? Разные проги показывают разные данные, в разных формулировках.
Вот snowflake-proxy (server на go) мне выдал, что у меня NAT type: restricted. А stun client (два вида пробовал): Endpoint Independent Mapping (Address and Port Dependent Filtering).
RetroShare: Full Cone NAT.
Но они везде так пишут. А входящие в торрентах есть, аська звонится (напрямую, собеседник тоже за NAT). Только у протона вроде подубовее.
2022-07-25T18:55:52.448Z
oct21
да, у меня дебиан, и в apparmor я заранее добавлял уже путь до снежинки, так что моя ошибка уже с добавленной строчкой. что такое front и как посмотреть путь пакетов? хотя я уже сомневаюсь что такие вопросы здесь релевантны, в конце концов это форум о блокировках, а не о посикс-системах для чайников(
2022-07-25T20:32:05.598Z
anonymous56(anonymous56)
Типы NAT можно отсортировать в крупные кучки, но на практике будут упрощения или уточнение тонкостей. Получится, что для разных сетевых случаев разные типы имеют похожее название. В том числе из-за ошибок.
Есть, как минимум, два сорта ПАК ТСПУ в установленном виде – одно работает, а второе для галочки. Синтетические тесты оно проходит, адреса и SNI блочит, а вот в реальных задачах окружающую среду только нагревает.
2022-07-26T08:39:42.784Z
anonymous58(anonymous58)
Усложнили правило блокировки для snowflake и других. Одиночным пакетом из приложения выявить паттерн теперь невозможно. Проверка многоуровневая – отдельная очередь для условного webrtc и уже в ней проверка. Похоже на оптимизацию под слабое железо, потратив такты на очередь выиграли окно под правило. Если это так, блокировка snowflake заденет теперь “всех”.
Новое правило: ClientHello запускает проверку на HelloVerifyRequest. Направление любое.
2022-08-06T08:43:41.359Z
tango
This observation agrees with OONI measurements I looked at in May 2022. Besides blackberry and altar, also stun.stunprotocol.org was not reachable.
In summary, 3 of the pool of 12 STUN servers are inaccessible in Russia. One of them is blocked by censorship in Russia, and the other two look like geoblocking of Russian clients by the STUN service.
stun.voip.blackberry.com and the IP address 178.239.90.248 are on the unified register of blocked sites, the entry dated 2017-04-28
stun.stunprotocol.org is not on the unified register as far as I can tell, nor are its IP addresses 18.191.223.12 and 2600:1f16:8c5:101::108. … the domain resolves incorrectly only in Russia and Ukraine:
stun.altar.com.pl is not on the unified register, nor is its IP address
176.119.42.11. Its failures only start on 2022-03-09. Its domain usually resolves correctly, but in Russia the actual STUN phase usually results in a timeout.
2022-09-01T23:42:31.549Z
tango
By the way, in recent versions of Tor Browser this is easier to do. You can can do it just by entering a custom bridge address in the normal about:preferences#connection interface:
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
There may still be a problem with the standalone (non-browser) proxies, as the Hello Verify Request mitigation hasn’t been applied to them yet.
2023-01-17T18:36:58.924Z
Shelikhoo(Shelikhoo (V2Fly, Way To Fly))
RE: It is not present in any release yet
I intend to release a new version and get the patch into Tor Browser in the immediate future.
RE: There may still be a problem with the standalone (non-browser) proxies
It would take some time to get all the standalone proxies to update(as evident in the case of distributed snowflake server support). But since the majority of the proxy are browser based, and snowflake client would retry automatically, it should connect eventually.
2023-01-17T22:26:47.092Z
tango
The Hello Verify Request change is released in Tor Browser 12.0.3. It may make Snowflake work in Russia, if it was not working before for you.
2023-02-16T15:30:09.312Z
sprite
А это просто в мануалах сами мейнтейнеры предлагали
Спасибо кстати за наводку на статические конфиги бриджа.
Погулив, нашел такой конфиг
И 1 из двух бриджей завелся.
2023-09-30T14:36:47.088Z
tango
Sorry about that. The snowflake-client README is outdated in that regard. It’s still documenting an older, deprecated way to set configuration options. The example torrc file is a better representative. I opened an issue to update the README:
2023-10-07T16:56:27.725Z
sprite
Спасибо, что сделали муналы и пример torrc болеее человеколюбивыми!
Немного оффтопик: верно ли понял, что к каждому бриджу до сих пор нужно прописывать параметры подключения вида
Или это уже можно вынести в (какую-либо?) общую часть конфига?
2023-11-30T23:39:40.868Z
tango
There are two ways to specify most settings: as a command-line argument in the ClientTransportPlugin line and as as a key=value parameter in the Bridge line. The key=value SOCKS parameters are the preferred form, but the command-line options still work. The command-line options will be global (not specific to a single Bridge line). If the same option is given on the command line and in a Bridge line, the Bridge line setting wins.
So yes, you can move one or more settings out of the Bridge line and into the ClientTransportPlugin line. For example, you can change