Мостов не настолько много, чтобы рота курсантов ФСБ не могла их в ручном режиме все высканить.
Да, посадят людей, дадут им всякие прокси/впски , сделают удобный инструмент и ручками ручками.
Хотя ИИ современный вполне способен распознавать такие капчи, как выдает tor browser, это не стоит усилий, проще людей запрячь.
Говорят в китае миллион китайцев сидит на слежке за китаенетом
Snowflake usage metrics have plummeted in Russia since 2022-01-11. Can anyone confirm whether Snowflake has stopped working again on the networks where it was previously blocked?
(from Users – Tor Metrics)
Snowflake works fine on both TSPU-enabled links for me.
It’s not only Russia, the worldwide Snowflake graph shows the same. I think it is just another instance of whatever caused the apparent dips on 2021-12-19 and 2021-12-29, perhaps #40088.
The relay search page for the bridge shows the client count going to zero on 2022-01-11 but back to normal on 2022-01-12.
https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6915AB06BFB7F
I’m not exactly sure what’s happening, but you can see the same kind of thing happen often in the meek graph.
A source wrote to me to report 8 relays that were accessible from AS12958 (T2 Mobile LLC) in Moscow. They add:
Likely with EcoFilter from RDP in place.
Lowered TTL, TLS fragmenting, and possibly fake packets with erroneous SQN/ACK are methods that seem to work for getting through, generally.
I have referred them to the Tor relay availability checker thread.
новый способ поддержки пользователей Tor – через Telegram
Команда по связям с общественностью проекта Tor рада объявить о запуске нового официального канала поддержки – в мессенджере Telegram: @TorProjectSupportBot. Этот способ поддержки добавлен в рамках усилий по борьбе с цензурой в отношении Tor в России.
Пользователи, у которых возникли проблемы с браузером Tor или которые не могут подключиться с помощью моста к Tor, могут связаться с нашей службой поддержки через Telegram. Этот новый экспериментальный канал поддержки ориентирован, в первую очередь, на помощь русскоязычным пользователям в подключении к сети Tor.
Пользователи, говорящие на английском и других языках, могут связаться с нашей службой поддержки, используя форум Tor: https://forum.torproject.net/, электронную почту frontdesk@torproject.org или используя Matrix.
Если вам нужен мост Tor, вы можете запросить его напрямую у нашего Telegram-бота: @GetBridgesBot.
Были репорты, что блочат даже приватные бриджи ?
Которые раздали роте курсантов множеству добровольцев
Я почти уверен, что выявление осуществляется по характерным признакам трафика. Проверю в ближайшее время.
obfs4 прокси же не детектятся, вроде. Они даже в Китае работают (приватные). И устойчивы к active probing (без сертификата не отвечают).
Но в Китае говорят, если много трафика на них идет, их блочат. Наверное, “на всякий случай”.
С момента начала блокировки Tor поднял около 5 мостов и несколько реле, все мосты публичные, блокировались только реле и то не очень активно
Поднятый в конце декабря этого года мост сначала перестал работать на мобильных операторах, сегодня отлетел и на проводном МГТС. Пингуется, но не более того.
Старый мост (три года) пока живет и здравствует.
Оба публичные, распространение через moat.
На декабрьском, правда, работал еще snowflake.
Вы правы и не правы одновременно. С одной стороны кажется, что meek больше не работает. Застревает на 20%
Feb 06 19:29:40.000 [notice] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
Feb 06 19:29:40.000 [notice] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
Feb 06 19:29:40.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Feb 06 19:29:52.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Feb 06 19:29:59.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Feb 06 19:29:59.000 [notice] Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
Feb 06 19:31:00.000 [notice] No circuits are opened. Relaxed timeout for circuit 1 (a General-purpose client 1-hop circuit in state doing handshakes with channel state open) to 60000ms. However, it appears the circuit has timed out anyway.
Feb 06 19:35:27.000 [notice] Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
Feb 06 19:45:27.000 (nothing)
В Wireshark красно-черные строчки. При этом коннект с cs22.wpc.v0cdn.net (155.199.19.160) по началу есть.
Один раз кое как добралось до 25% за 4 минуты в виде исключения.
Разбавление сторонней фоновой (обычно-браузерной) активностью не помогает.
Проверил 2-3 раза.
Провайдер мобильный.
snowflake работает.
Затем я переподключился к интернету и meek заработал.
Однако это довольно странно.
@wikusya Спасибо за команду. Пока что все работает с ней и без нее, но по разному. Понаблюдаю еще. Хочу заметить, что реализаций meek клиентов существует несколько.
Такой вопрос. Когда провайдеры (разных стран) блокируют доступ к запрещенным IP, они это делают только для исходящих соединений или для всех? То есть и для входящих незапрошенных?
Например, NordVPN заблокирован в России. Пользователь из Франции (с более свободным интернетом) подключается к NordVPN (чтобы не пришла жалоба от правообладателя) и запускает торрент клиент. Пользователь из России тоже запускает торрент клиент, но на провайдеровском IP. Французский пользователь хочет скачать раздачу с русского пользователя. Могут ли они соединиться (по торрент протоколу)? То есть, для русского пользователя соединение с запрещенным VPN будет входящим.
Я думаю, что если провайдер настраивает блокировки через iptables, то там будет только OUTPUT. А если какой-нибудь коммерческий файервол или железка, то кто знает.
Вот я дебил. Даже если входящий пакет дойдет (VPN > RU IP), исходящий ответ (RU IP > VPN) все равно заблочится.
Я вот тоже думаю, что раз у клиента “входящие незапрошенные” и “входящие ответные” по разному обрабатываются (первые не всегда доступны, хотя, здесь дело в NAT), то может быть “исходящие инициализированные” и “исходящие ответные” будут по разному обрабатываться файерволом провайдера. Например, сам ты инициализировать исходящее соединение с впновским ip не сможешь, но если на тебя свалится входящее от него, может быть тогда ответить и взаимодействовать будет позволено (когда инициатор не ты). Извиняюсь за свою терминологию.
В home интернете “входящие незапрошенные” это довольно экзотическое явление (в отличии от серверной среды, сервер без них жить не может). В home среде белый/внешний ip провайдер не обязан предоставлять и в большинстве случаев домашний пользователь без него обойдется.
Но как я говорил, различия во входящем трафике связаны с NAT, а в исходящем в блокировщике провайдера (который может вообще не разделять тип исходящего или это в принципе невозможно). Этот экзотический случай мало кто изучал, я думаю.
Вот, у тора раньше был мост flashproxy, где входная нода сама соединялась с юзером (по TCP протоколу на 9000 порту). Но сейчас на смену пришел более продвинутый snowflake, где используется WebRTC и можно даже обходить NAT + получение моста через meek, а не email.
Но мне кажется старые транспорты типа fte все еще представляют интерес (если самому развернуть мост на них). Ведь современный DPI специализируется совсем не на них (они как неуловимый Джо). Если только все старые наработки в DPI не забиты.
https://rutracker.org/forum/viewtopic.php?p=82734330#82734330
теперь часто в логах попадаются сообщения вида Tor WARN: Proxy Client: unable to connect OR connection (handshaking (proxy)) на разных этапах подключения к тору, при чем иногда не смотря на это получается подключиться а иногда нет используя один и тот же мост. какая то хитрая тактика от ростелекома?
Возможно это всего лишь ошибка в новой версии obfs4proxy.
Уже 3-й день как бьюсь над проблемой с неработающим webrtc (стрим с камеры на сервак) через хромоподобные браузеры.
Недолетает DTLS пакет с ClientHello. Однако в Firefox проблемы не наблюдается. Судя по Wireshark’у пакеты у хрома и лисы немного отличаются. Толи специально блочат, толи случайно.