Как устроена блокировка Delta Chat? Разбор #17

Что это за рубрика

В рубрике «Разбор Теплицы» мы в режиме реального времени разбираемся в определённой проблеме, новостях интернет-цензуры и рассказываем:

• что происходит;
• как это устроено;
• как с этим можно бороться.

Материал дополняется

Что случилось?

К середине июля 2026 года история со сбоем Delta Chat в России уже не выглядит рядовым техническим инцидентом. Началось всё 5 июня, когда у пользователей мессенджера в России одновременно перестали работать релеи Chatmail. Один из пользователей сообщил на форуме поддержки, что его собственный релей, развёрнутый в России, перестал работать именно в этот день: статус «connecting», сообщения не доставляются, создание нового профиля зависает на 60% с ошибкой тайм-аут. Еще один разработчик подтвердил в том же треде: команда знает о проблеме, поступает много похожих сообщений с одинаковыми симптомами. Уже в этот день другой пользователь предположил блокировку по TLS-отпечатку, а пользователь Gluek подтвердил, что паттерн DPI задевает и не-chatmail серверы.

Жалобы не ограничились одной темой на форуме. Через несколько дней там же появилось обсуждение блокировки IMAP-доступа к внешним сервисам сразу в нескольких регионах, независимо от первого сообщения. Отдельный технический разбор зафиксировал те же сроки: почта Delta Chat на серверах Beget и Timeweb перестала работать именно 5 июня.

Как мы выясняли причины недоступности DeltaChat

В 2020 году Роскомнадзор потребовал от разработчиков доступ к данным пользователей и ключам шифрования. Заодно Роскомнадзор потребовал от DeltaChat зарегистрироваться в реестре организаторов распространения информации (ОРИ). В Delta Chat отказали Роскомнадзору, ссылаясь на отсутствие доступа к данным пользователей в силу особенностей архитектуры сервиса. В 2024 году Роскомнадзор уже по запросу ФСБ повторно потребовал регистрации, получил повторный отказ и в июле составил протокол о неисполнении обязанностей ОРИ, наложив штраф в 100 тысяч рублей.

В конце мая и начале июня 2026 года владельцы сайтов на крупных российских хостингах начали жаловаться на недоступность своих ресурсов. Хостинг-провайдер Beget в официальном телеграм-канале сообщил, что часть ресурсов частично недоступна у части пользователей. При этом, по данным Beget, проблема носит «плавающий характер» и связана с обновлением настроек ТСПУ со стороны РКН.

Другой хостинг-провайдер, Timeweb, у себя телеграм-канале 4 июня называл вероятной причиной сбоя изменения настроек ТСПУ. По субъективному восприятию автора, лично разбиравшегося с проблемой на своей инфраструктуре, служба поддержки Timeweb на протяжении двух дней отрицала проблему в ответах на индивидуальные обращения пользователей и признала ее лишь 7 июня. Это наблюдение не подтверждено другими источниками независимо и может отражать конкретный опыт общения с поддержкой, а не общую политику компании; телеграм-канал сервиса упоминал ТСПУ.

6 июня инженер Пётр Осетров опубликовал технический разбор с реконструкцией нового алгоритма ограничений, основанной на воспроизводимом эксперименте: он поднял несколько параллельных профилей Google Chrome и показал, при каких условиях соединение замораживается. В этом посте Delta Chat не упоминается вовсе, разбор посвящён общему алгоритму фильтрации, что говорит скорее в пользу протокол-агностичной природы блокировки, чем в пользу версии о целенаправленности.

Через несколько дней после публикации один из читателей сообщил в новостной заметке на Хабре, что статья стала недоступна с характерной заглушкой хостинга. В комментариях к более позднему разбору эту ситуацию уточнили точнее: статья не удалена, а скрыта именно для российских IP-адресов кодом HTTP 451 «Недоступно по юридическим причинам», при этом она полностью доступна из любых других стран.

Это согласуется с задокументированной политикой самой платформы: получив предписание о блокировке материала на территории конкретной страны, Хабр накладывает гео-ограничение с этим кодом, определяя страну посетителя по базе регионального регистра адресов. Из доступных источников не устанавливается, было ли это прямым предписанием регулятора или инициативой самой платформы в порядке модерации.

Как устроены блокировки?

Три сигнала одного алгоритма

Реконструкция Осетрова описывает механизм как последовательную проверку трех условий при установке TLS-соединения:

• относится ли IP-адрес сервера к «подозрительной» подсети или автономной системе, в список которых попал ряд крупных российских дата-центров;
• является ли TLS-отпечаток клиента подозрительным (в среднем это касается отпечатков, имитирующих Chrome, Safari и iOS, тогда как Firefox, Android OkHttp, Edge и ряд других на момент публикации проходили проверку у большинства операторов);
• было ли зафиксировано более трех параллельных попыток TLS-соединения к одному SNI с интервалом менее 350–400 мс в течение последних 60 секунд.

Если все три условия выполняются, соединение замораживается на 120 секунд. Смена отпечатка клиента во время заморозки добавляла штрафной бан ещё на 600 секунд, независимо от нового отпечатка и SNI, хотя, по обновлению автора от 16 июня, этот дополнительный штраф впоследствии, судя по всему, убрали.

У Delta Chat не было цели обходить блокировки: обычный TLS-трафик почтового клиента совпал с сигналом 2 (подозрительный отпечаток) на фоне того, что сервер размещался на подсети, уже помеченной как подозрительная по сигналу 1. Это тот случай, который показывает: алгоритм не различает прокси и легитимный трафик, если совпадение по двум и более сигналам формально выполняется.

Хронология: от первых сигналов к июньской волне

• в ноябре и декабре 2025 года ТСПУ начала блокировать VLESS по косвенным признакам в нескольких регионах, сначала в Татарстане, Удмуртии и Нижегородской области, затем в Свердловской;
• 17 февраля 2026 года произошла масштабная блокировка связки VLESS+Reality поверх TCP у нескольких проводных операторов, с характерным паттерном заморозки после первых примерно 16 килобайт трафика;
• в конце мая начался тестовый запуск, а затем развертывание поведенческого модуля в Сибири и Москве, под которое попали VLESS, Xray, MTProto, WireGuard и gRPC, но не SSH.

Что кто говорит

Две гипотезы о причине

Сопутствующий ущерб. Волна 5 июня одновременно задела Delta Chat, хостинг-провайдеров и несколько VPN-протоколов. Логика alarm-условий (подсеть, отпечаток, частота хендшейков) не содержит ничего специфичного для мессенджеров или почты. Публичная риторика вокруг инцидента описывает происходящее как борьбу против современных протоколов, которые маскируются под легальный трафик, а не как атаку на конкретные сервисы.

Целенаправленная эскалация. Предположение опирается на реальный прецедент: задокументированные конфликты Delta Chat с РКН в 2020 и 2024 годах. Впрочем, пока связь трех инцидентов не подкрепляется техническими данными.

Что делать

Для более точных рекомендаций редакция Теплицы проводит дополнительные исследования, результаты которых будут опубликованы в ближайшее время.

Пока краткие рекомендации такие:

• выбор криптографического бэкенда и его влияние на TLS-отпечаток;
• снижение числа параллельных соединений там, где это возможно на уровне релея;
• выбор подсети хостинга с учётом того, что попадание в «подозрительный» список ASN не публикуется официально и может меняться.