Билайн Москва (проводной и мобильный).
Со вчерашнего вечера опять начались блокировки VPN (OpenVPN, Wireguard).
А теперь - внимание, новинка!
Помимо протоколов VPN, заблокировали также протокол… Jabber.
Да, я им пользуюсь в 2023 году для личной переписки, и у меня есть свой личный сервер. Эдакий семейный мессенджер у меня.
Методика блокировки очевидно такая же - через DPI по сигнатурам.
Если используется STARTTLS, то после отправки клиентом пакета об установке шифрованного соединения, ответный пакет сервера блокируется, а клиенту вместо него прилетает RST пакет.
Если же STARTTLS отключен и используется нешифрованное соединение, то после отправки клиентом пакета response с данными для аутентификации, блокируется ответный пакет сервера, сообщающий о результате аутентификации, а клиенту так же вместо него прилетает RST пакет.
Блокировка (VPN и Jabber’а) наблюдается только на Билайне (провод и моб).
МТС (моб), Мегафон (моб), Йота (моб), Ростелеком (провод) - блокировки нет.
Интересно, что блокируется доступ к моему личному jabber-серверу, расположенному на VPS в OVH. При этом доступ, например, к jabber.ru (находящемуся в Хетцнере) - работает нормально.

Да, забыла уточнить. Тут точно так же как и с блокировкой VPN. Можно поставить любой порт, но смена порта от блокировки не помогает, блокировка все равно работает, порт не имеет значения.

RST прилетает в ответ на STARTTLS или Client Hello?

RST прилетает в ответ на Client Hello.

Значит число исходящих пакетов, с содержимым, после которых прилетает RST, совпадает для обоих сценариев (со STARTTLS и без)?

Проверила дампы, получается что именно так. 3 пакета от клиента, 3 пакета от сервера, 4-й пакет от сервера блокируется.

Возможно это чужая блокировка которая задела подсеть или хостера целиком. (Пример). Блокировать могут после определенного числа пакетов, с любым содержимым, но возможно действительно смотрят протокол. Этот вариант легко проверить запуском чего-то другого на проблемном порту.

OVH на предмет блокировки XMPP можно проверить на чужом сервере, например xmpp.tilde.team (это сервер комьюнити Tilde.team), или найти другой. Для проверки вашей блокировки не нужен рабочий аккаунт.

Попробуйте CURL’ом. Возможно, заблокировали TLS Fingerprint XMPP-клиента.
Или напишите IP-адрес, чтобы не гадать.

Проверила tilde.team - блокируется.

Проверила также других хостеров.
Сервер в Scaleway - блокируется
Сервер в Латвии у ITLDC - блокируется
Сервер в РФ у российского хостера - не блокируется

HTTP/HTTPS - работает. XMPP - блокируется. OpenVPN - блокируется.
Еще, номер порта не имеет значения. Хоть 5222, хоть 443, хоть произвольный нестандартный порт - подключение блокируется на любом порту. То есть все точно так же, как и с блокировками VPN - там тоже смена порта не помогает.

Нет, блокировка же наступает даже при незашифрованном соединении.
А curl не проходит, потому что там STARTTLS. Сервер ожидает начало обмена данными обычным текстом и только потом по специальной команде переход в режим TLS.

$ openssl s_client -host tilde.team -port 5222 -servername tilde.team -starttls xmpp < /dev/null &>/dev/null && echo ok || echo fail

$ openssl s_client -4 -host tilde.team -port 5222 -servername tilde.team -starttls xmpp < /dev/null &>/dev/null && echo ok || echo fail
fail

Beeline/Corbina AS8402 Moscow

Если XMPP блокируют как VPN протокол, почему jabber.ru работает. Хетцнер врядли в белом списке.
Работает ли Direct TLS с ALPN?

Утром эта команда выдавала ок, сейчас вечером fail.
Провайдер Подряд. Владивосток.
При этом телнетом порт открывается. С vps Нидерланды выдает ок.
jabber.ru доступен с россии и Нидерландов.

PS. openvpn тоже работает

Direct TLS с ALPN - работает.
Похоже, в ALPN они вообще не смотрят, что подтверждает тест с openssl s_client, который не передает ALPN, а STARTTLS соединение все равно блокируется.

Возможно досматривают содержимое STREAM (исходящее и/или входящее), а потом просто считают пакеты и дропают подключение после N. Так блокируют WireGuard и IKE по исходящему от клиента. Скорее всего что-то похожее на это.

Подключение к tilde.team:5222 со STARTTLS из AS8369 (Интерсвязь is74).
xmpp_tilde.team_5222_starttls_block_Intersvyaz.pcapng (6.4 KB)

Подключение к OVH Германия (сервер АнтиЗапрета 51.38.124.100), настроенный на перенаправление трафика к xmpp.jp:5222
xmpp_ovhde_5222_starttls_block_Intersvyaz.pcapng (2.7 KB)

Как минимум, регионы GRA и WAW OVH подобной фильтрации не подвергаются.

Всё, на моих каналах перестали блокировать 2023-10-15T15:05:00Z
Опять началось 2023-10-15T15:11:00Z

Буквально час назад началась блокировка на Ростелеком (Онлайм) Москва.

Причем, как и в случае с VPN, фильтрации подвергается только IPv4. На IPv6 блокировок нет.

В этих дампах нет SNI в ClientHello. Может это не нравится ?
типа jabber.ru православный, а другие непонятно какие нарушают закон о мессенджерах ?

Тестят.
На 3 spb провайдерах и теле2 блокировки нет.

Не забываем, что у жаббера есть старый вариант без starttls. На tilde.team порт 5223 отвечает, можно попробовать через него без starttls

Нет, дело не в этом.
xmpp_tilde_team_servername_5222_starttls_block_Intersvyaz.pcap (4.1 KB)

MTS HOME(MGTS) GPON москва
openssl s_client -host tilde.team -port 5222 -servername tilde.team -starttls xmpp < /dev/null &>/dev/null && echo ok || echo fail
fail

На текущий момент tilde.team XMPP недоступен c Интерсвязь is74 AS8369 и Dom.ru AS50544.

tilde.team:5222 XMPP STARTTLS блокируется на провайдере sknt.ru , только на части подключений (1 из 2 точек работает, другая нет), только по ipv4

при этом

подключение со SNI tilde.team к другому серверу - в порядке
tilde.team:5223 XMPP без STARTTLS в порядке
другие XMPP STARTTLS в порядке
еще 2 провайдера в спб - в порядке

тренируются ?

Ждет два входящих stream. Парсит (как минимум, наличие: id, version, xml:lang, xmlns:stream, from). С одним входящим stream: не заблокирует (stream:features должны прилетать отдельным пакетом). Затем ждет 2 любых исходящих и блокирует сессию (заменяет на RST входящие). Счетчики и направление возможно применяют разные. Блокируемые диапазоны неизвестны, рандом для наблюдателя.

По другой версии ограничено суммарное число сегментов для XMPP сессии. Или более сложное правило, вырождаемое для отдельных случаев в 2 исходящих. Наблюдалось 3, 1 (все заканчивалось на STARTTLS). Возможно дело просто в latency блокировщика.

Все не так.

Рабочие сэмплы.
Client:

stream:stream xmlns:stream=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Server:

stream:stream id=xxxxxxxxxxxxxxxxxxxxxx version=xxxxx xml:lang=xxxxx xmlns:stream=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx from=xxxxxxxxxx

где x – любой символ, кроме space, например x

Послать Client и принять Client не работает. Послать Server и принять Server не работает. Послать Client и принять Server работает.

При этом можно bidirectional. Например, только посылать комбинацию, и далее через N-даты будет блок. Но сэмпл нужно передать дважды: Client+Client, Client+Server, Server+Server.

У Hetzner блокируют XMPP меньше чем у OVH. jabber.ru находится в неблокируемом диапазоне, но вот conversations.im попал.

https://www.opennet.ru/opennews/art.shtml?num=59965

Неужели это всё из-за торговли? Осторожнее надо быть обычным пользователям с непопулярными мессенджерами. Я бы даже тестить боялся теперь этот jabber.
https://notes.valdikss.org.ru/jabber.ru-mitm/

5 posts were merged into an existing topic: Выбор мессенджера

Доброго всем, извиняюсь за некропостинг, но по теме.
Держу семейный мини-jabber/xmpp сервер дома на одноплатнике и белом IP, так вот пару дней назад перестали проходить исходящие к некоторым xmpp-серверам, замечены аномалии с:
quicksy.im, tigase.org, jabb3r.org, возможно и больше… 5269 startTLS

Провайдер проводной - Maryno.net. Также пробовал по проводному билайну и мобильному теле2 - xmpp-dns тест работает ОК.
Послушал wireshark’ом, результаты прикладываю:

1. Марьино.нет, соединения нет
   ws_quicksy_srv_rst.pcapng (11,3 КБ)
2. Tele2 мобильный, соединение есть
   ws_quicksy_srv_ok.pcapng (25,6 КБ)

Подскажите пожалуйста, это вообще что, блокировка? И что дальше делать, пинать/менять провайдера, или кого ещё, или перевозить сервер куда-нибудь на VPS?..

Да, похоже на блокировку, вероятно, по какому-то особому признаку. Предполагаю, что по ответу сервера, т.к. изменение домена и параметров в ClientHello не помогает.

openssl s_client -starttls xmpp-server -host xmpp.quicksy.im -port 5269 -xmpphost quicksy.im -servername quicksy.im </dev/null &>/dev/null && echo ok || echo fail

Спасибо большое за инфу, пойду думать дальше…

Можно zapret-ом поиграться. nfqws fake, split и wssize и с ограничителем по IP
Если, конечно, они не рубят по IP

Блокировки вернулись, как уже заметили. Правило и блокируемые диапазоны адресов изменились. Активируют счетчик блокировки по исходящему, содержимое входящих не проверяют. Парсер упростился, тригернуть можно строкой:

strea stream stream xmlns

Порядок не важен, проверяют наличие двух stream, одного xmlns и strea (полный stream тоже работает).
Далее считают исходящие с любым содержимым и по небольшому рандому блокируют подключение, подменив входящие RST’ом.

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

На моём ISP (AS39709) на данный момент перестало блокироваться…

Проблема сохраняется, добавил свежий тест.

Правило изменили, добавив проверку на starttls. Подробности бесполезны, детали блокировки меняются быстрей сообщений на форуме.

Роскомнадзор, оказывается, направлял письмо в conversations.im 24 сентября 2024, о том, что по закону о связи мессенджерам нужно идентифицировать пользователей по номеру телефона, а гос. орган не обнаружил договоров с мобильными операторами РФ для осуществления идентификации. Домен блокируется, в выгрузках до сих пор отсутствует.

Conversations до этого значился в реестре организаторов распространения информации. Роскомнадзор 2 года назад запросил юридическую информацию у сервиса, те её предоставили.