Что случилось?
К середине июля 2026 года история со сбоем Delta Chat в России уже не выглядит рядовым техническим инцидентом. Началось всё 5 июня, когда у пользователей мессенджера в России одновременно перестали работать релеи Chatmail. Пользователь f7n5xmavu сообщил на форуме поддержки, что его собственный релей, развёрнутый в России, перестал работать именно в этот день: статус «connecting», сообщения не доставляются, создание нового профиля зависает на 60% с ошибкой тайм-аут. Разработчик link2xt подтвердил в том же треде: команда знает о проблеме, поступает много похожих сообщений с одинаковыми симптомами. Уже в этот день пользователь darkcat09 в комментариях предположил блокировку по TLS-отпечатку, а пользователь Gluek подтвердил, что паттерн DPI задевает и не-chatmail серверы. Показательная деталь: аккаунт с тем же именем, darkcat09, позже фигурирует среди ревьюеров PR #8313, исправившего проблему.
Жалобы не ограничились одной темой на форуме. Через несколько дней там же появилось обсуждение блокировки IMAP-доступа к внешним сервисам сразу в нескольких регионах, независимо от первого сообщения. Отдельный технический разбор зафиксировал те же сроки: почта Delta Chat на серверах Beget и Timeweb перестала работать именно 5 июня.
Обсуждение вышло и за пределы форума поддержки — в Mastodon, где 11 июня независимый исследователь Trickster опубликовал разбор с той же технической версией: библиотека Rustls, которую использует ядро Chatmail, отправляет уникальный TLS-отпечаток, и именно его начали отлавливать и блокировать. 13 июня пользователь VVVas предположил, что «это целенаправленная блокировка». О другой проблеме сообщил оператор релея в Казахстане: его сервер и ряд других, включая arcanechat.me, стали недоступны, из-за чего инфраструктуру пришлось перенести в Эстонию со сменой хостинг-провайдера.
Как мы выясняли причины недоступности DeltaChat
У Роскомнадзора давно претензии к DeltaChat, поэтому версия про блокировки валидна. В 2020 году ведомство потребовало от разработчиков доступ к данным пользователей и ключам шифрования. Заодно Роскомнадзор потребовал от DeltaChat зарегистрироваться в реестре организаторов распространения информации (ОРИ). В Delta Chat отказали Роскомнадзору, ссылаясь на отсутствие доступа к данным пользователей в силу особенностей архитектуры сервиса. В 2024 году Роскомнадзор уже по запросу ФСБ повторно потребовал регистрации, получил повторный отказ и в июле составил протокол о неисполнении обязанностей ОРИ, наложив штраф в 100 тысяч рублей.
Мы решили проверить, насколько версия о целенаправленной атаке государства на DeltaChat может быть правдива.
Шаг 1. Что делали и говорили разработчики?
Первым делом мы изучили, что делали в последнее время разработчики Delta Chat. 5 июня один из них открыл, а 6 июня выполнил слияние pull request, заменяющего криптографический бэкенд Rustls с библиотеки ring на aws-lc-rs. Ттекст pull request, однако, объясняет изменение иначе, чем последующие независимые разборы: автор пишет, что aws-lc-rs теперь дефолтный провайдер для Rustls, а ring использовали ради экономии на дублирующей зависимости из-за библиотеки iroh; попутно новый провайдер даёт поддержку постквантовой группы X25519MLKEM768 и явно включает поддержку TLS 1.2. Ни блокировка, ни ТСПУ, ни обход детекции в тексте pull request не упоминаются.
С одной стороны, публикация не подтверждает версию о целенаправленной атаке: разработчики не только не заявляют публично о блокировке, но даже не намекают на нее в техническом описании собственного патча. С другой стороны, само по себе отсутствие подтверждения не опровергает версию, а лишь означает, что атрибуция «патч как реакция на блокировку» принадлежит независимым разборам, а не самим разработчикам. При этом совпадение по времени точное: pull request открыт в день начала сбоев и слит на следующий день после того, как о проблеме стало массово известно.
Шаг 2. Что мы узнали из информации о сбоях DeltaChat и подобных сервисов?
Чтобы проверить, был ли инцидент направлен именно против Delta Chat, мы обратились к более широкой картине сбоев того же периода. Сам по себе сбой у Delta Chat не был единственным симптомом. В конце мая и начале июня 2026 года владельцы сайтов на крупных российских хостингах начали жаловаться на недоступность своих ресурсов.
Хостинг-провайдер Beget в официальном телеграм-канале сообщил, что часть ресурсов частично недоступна у части пользователей. При этом, по данным Beget, проблема носит «плавающий характер» и связана с обновлением настроек ТСПУ со стороны РКН.
Другой хостинг-провайдер, Timeweb, у себя телеграм-канале 4 июня называл вероятной причиной сбоя изменения настроек ТСПУ. По субъективному восприятию автора, лично разбиравшегося с проблемой на своей инфраструктуре, служба поддержки Timeweb на протяжении двух дней отрицала проблему в ответах на индивидуальные обращения пользователей и признала ее лишь 7 июня. Это наблюдение не подтверждено другими источниками независимо и может отражать конкретный опыт общения с поддержкой, а не общую политику компании; телеграм-канал сервиса упоминал ТСПУ.
6 июня инженер Пётр Осетров опубликовал технический разбор с реконструкцией нового алгоритма ограничений, основанной на воспроизводимом эксперименте: он поднял несколько параллельных профилей Google Chrome и показал, при каких условиях соединение замораживается. В этом посте Delta Chat не упоминается вовсе, разбор посвящён общему алгоритму фильтрации, что говорит скорее в пользу протокол-агностичной природы блокировки, чем в пользу версии о целенаправленности. Через несколько дней после публикации один из читателей сообщил в новостной заметке на Хабре, что статья стала недоступна с характерной заглушкой хостинга РКН устроил проблемы с доступом российским облачным сервисам и сайтам13. В комментариях к более позднему разбору эту ситуацию уточнили точнее: статья не удалена, а скрыта именно для российских IP-адресов кодом HTTP 451 «Недоступно по юридическим причинам», при этом она полностью доступна из любых других стран комментарии к «Заморозке по fingerprint»14. Это согласуется с задокументированной политикой самой платформы: получив предписание о блокировке материала на территории конкретной страны, Хабр накладывает гео-ограничение с этим кодом, определяя страну посетителя по базе регионального регистра адресов Хабр, «Географические ограничения»15. Из доступных источников не устанавливается, было ли это прямым предписанием регулятора или инициативой самой платформы в порядке модерации.
Связь между этим общим алгоритмом и конкретно кейсом Delta Chat есть в этом разборе на «Хабре» — TLS-отпечаток криптографической библиотеки ring, которую использовал Rust-движок Chatmail, совпал с признаками, которые новый алгоритм ТСПУ помечает как подозрительные, и почта Delta Chat легла на нескольких хостингах одновременно с другими сбоями 5 июня. Автор этого разбора помечает признание Timeweb 7 июня как факт, кросс-проверенный по трём независимым источникам, включая уже упомянутый allslava.com.
Сбой Delta Chat — это часть более крупного тренда. Пострадал не один мессенджер, а целый ряд сервисов и сайтов, а сам механизм блокировки не содержит признаков, направленных именно на email-протоколы или Chatmail.
Как устроены блокировки?
Три сигнала одного алгоритма
Реконструкция Осетрова описывает механизм как последовательную проверку трех условий при установке TLS-соединения:
- относится ли IP-адрес сервера к «подозрительной» подсети или автономной системе, в список которых попал ряд крупных российских дата-центров;
- является ли TLS-отпечаток клиента подозрительным (в среднем это касается отпечатков, имитирующих Chrome, Safari и iOS, тогда как Firefox, Android OkHttp, Edge и ряд других на момент публикации проходили проверку у большинства операторов);
- было ли зафиксировано более трех параллельных попыток TLS-соединения к одному SNI с интервалом менее 350–400 мс в течение последних 60 секунд.
Если все три условия выполняются, соединение замораживается на 120 секунд. Смена отпечатка клиента во время заморозки добавляла штрафной бан ещё на 600 секунд, независимо от нового отпечатка и SNI, хотя, по обновлению автора от 16 июня, этот дополнительный штраф впоследствии, судя по всему, убрали.
У Delta Chat не было цели обходить блокировки: обычный TLS-трафик почтового клиента совпал с сигналом 2 (подозрительный отпечаток) на фоне того, что сервер размещался на подсети, уже помеченной как подозрительная по сигналу 1. Это тот случай, который показывает: алгоритм не различает прокси и легитимный трафик, если совпадение по двум и более сигналам формально выполняется.
Хронология: от первых сигналов к июньской волне
Разбор darkisdark, который явно связал алгоритм с Delta Chat, восстанавливает и более длинную хронологию, предшествующую июньской волне:
- в ноябре и декабре 2025 года ТСПУ начала блокировать VLESS по косвенным признакам в нескольких регионах, сначала в Татарстане, Удмуртии и Нижегородской области, затем в Свердловской;
- 17 февраля 2026 года произошла масштабная блокировка связки VLESS+Reality поверх TCP у нескольких проводных операторов, с характерным паттерном заморозки после первых примерно 16 килобайт трафика;
- в конце мая начался тестовый запуск, а затем развертывание поведенческого модуля в Сибири и Москве, под которое попали VLESS, Xray, MTProto, WireGuard и gRPC, но не SSH.
Иначе говоря, случай Delta Chat 5 июня оказался не первым и не единственным проявлением перехода к поведенческой фильтрации, а одним из симптомов процесса, который готовился несколько месяцев.
Что кто говорит
Две гипотезы о причине
Технические данные и регуляторный контекст указывают на разные версии.
Сопутствующий ущерб. Волна 5 июня одновременно задела Delta Chat, хостинг-провайдеров и несколько VPN-протоколов. Логика alarm-условий (подсеть, отпечаток, частота хендшейков) не содержит ничего специфичного для мессенджеров или почты. Публичная риторика вокруг инцидента описывает происходящее как борьбу против современных протоколов, которые маскируются под легальный трафик, а не как атаку на конкретные сервисы.
Целенаправленная эскалация. Предположение опирается на реальный прецедент: задокументированные конфликты Delta Chat с РКН в 2020 и 2024 годах. Впрочем, пока связь трех инцидентов не подкрепляется техническими данными.
У этих двух гипотез есть еще один слой: сама позиция государства неоднородна и существует в двух версиях. Институционально фильтрация трафика в России развивается по долгосрочному плану, а не как реакция на конкретные события. Решение о порядке предоставления субсидии Главному радиочастотному центру №25-66883-01845-Р, подписанное 13 января 2025 года, задает целевые показатели: 92-процентную эффективность ограничения доступа к VPN к 2030 году и обработку 100% трафика российского сегмента интернета уже в 2026 году — мы делали отдельный разбор на эту тему. Сам документ впоследствии был удален с сайта Роскомнадзора.
Параллельно готовился и правовой сдвиг на уровне хостинг-провайдеров: поправки «Антифрод 2.0», обсуждавшиеся с апреля 2026 года, переводят хостеров из статуса технического посредника в статус контролера, обязывая их самостоятельно выявлять и отключать клиентов, использующих мощности для VPN, включая случаи с уже обфусцированным трафиком — и на эту тему у нас был разбор.
Еще один штрих к этой картине: собственная публичная оферта Beget уже к маю 2026 года запрещала клиентам размещать «массовые публичные почтовые сервисы, VPN-сервисы, прокси-сервисы». Прямой связи между этой формулировкой и июньским инцидентом нет, но очевидно: хостинг-провайдеры готовились к ужесточению контроля еще до июньской волны.
Оба документа возникли до всех событий июня 2026 года. И это довод в пользу того, что июньская волна была плановым этапом более широкой программы, а не спонтанным решением. Публичная же версия, которую озвучивают устами хостинг-провайдеров и профильных изданий, звучит проще: борьба против протоколов, маскирующихся под легальный трафик.
Позиции остальных сторон
Разработчики Delta Chat признают факт сбоя и дают практическую рекомендацию по обновлению клиента, но не атрибутируют причину публично и не связывают патч #8313 с блокировкой в собственных заявлениях. Независимые технические авторы расходятся во мнениях: Осетров описывает протокол-агностичный механизм без упоминания Delta Chat, darkisdark явно связывает этот механизм с кейсом мессенджера как показательным примером ложного срабатывания на легитимном трафике.
Что делать
Для более точных рекомендаций редакция Теплицы проводит дополнительные исследования, результаты которых будут опубликованы в ближайшее время.
Пока краткие рекомендации такие:
- выбор криптографического бэкенда и его влияние на TLS-отпечаток;
- снижение числа параллельных соединений там, где это возможно на уровне релея;
- выбор подсети хостинга с учётом того, что попадание в «подозрительный» список ASN не публикуется официально и может меняться.
Выводы
Сбой Delta Chat 5 июня 2026 года был зафиксирован и признан разработчиками как системная проблема. Проверка сигнала о возможной целенаправленности не подтвердила его: независимая техническая реконструкция связывает инцидент с более широким переходом ТСПУ от сигнатурной фильтрации к поведенческой. Этот переход начался в ноябре 2025 года и задел множество сервисов помимо Delta Chat. Патч, заменивший криптографический бэкенд, по времени совпадает с обнаружением проблемы, но сами разработчики не подтверждают связь публично.
Причина инцидента доподлинно неизвестна. Есть две версии: сопутствующий ущерб от общей эскалации фильтрации трафика (лучше подтвержднн технически и публичной риторикой регулятора) и целенаправленная эскалация на фоне многолетнего конфликта Delta Chat с РКН (подтверждена историческим контекстом, но не прямыми доказательствами применительно к 2026 году).