ТСПУ блокирует Delta Chat: как TLS-отпечаток ring сломал почту на Beget и Timeweb

5 июня 2026 года Delta Chat в России перестал отправлять и получать письма через почтовые серверы на базе Beget и Timeweb. Проблема оказалась вызвана оборудованием ТСПУ Роскомнадзора, которое блокирует TLS-соединения с нестандартным отпечатком. Разбираем, как JA3 fingerprint стал причиной сбоя, почему Thunderbird и Apple Mail работают, а Delta Chat — нет, и какие три решения существуют — от временного обхода до переноса на Яндекс 360.

Что случилось: хронология событий

Два дня поддержка Timeweb отрицала проблему, перекладывая вину на клиента. Только под угрозой публикации статьи на habr провайдер признал наличие проблем у клиентов из ТСПУ — но конкретно установку оборудования у себя не подтвердил.

Корневая причина: ТСПу и JA3 fingerprint

ТСПУ (Типовая схема построения сети Пользователя) — оборудование Роскомнадзора, устанавливаемое у провайдеров для глубокого анализа трафика и блокировки запрещённых ресурсов.

ТСПУ использует метод MITM (Man-in-the-Middle): он перехватывает TLS-соединение, подменяет сертификат сервера своим и продолжает инспекцию трафика. Но здесь возникает ключевой нюанс — ТСПУ определяет, как обрабатывать соединение, по JA3 fingerprint (отпечатку TLS ClientHello).

Как именно работает атака через ТСПУ

1. Delta Chat отправляет ClientHello с отпечатком криптопровайдера ring из библиотеки rustls
2. ТСПу видит «чужой» отпечаток → подменяет TLS-сертификат сервера своим
3. Delta Chat проверяет сертификат и отвергает подменный — соединение зависает на этапе TLS handshake
4. Таймаут через 60 секунд — письмо не отправлено

Почему другие почтовые клиенты работают

Delta Chat использует ring + rustls — это мощный, но уникальный стек. Для ТСПу он выглядит как «чужак», которого нужно перехватить и подменить сертификат. Стандартные клиенты используют системные криптобиблиотеки, которые ТСПУ считает «родными».

Почему за границей работает, а VPN не помог

Например во Вьетнаме нет ТСПУ — никто не делает MITM на TLS, поэтому соединение проходит нормально.

VPN не помог по двум причинам:

1. Если exit-нода VPN находится в России — трафик всё равно идёт через ТСПУ
2. Даже при зарубежной ноде — MITM происходит до того, как трафик попадает в VPN-туннель (на уровне SMTP/IMAP порта)

Что видит ТСПУ: логины, пароли и текст писем

Когда ТСПу подменяет сертификат, он получает полный доступ к каналу связи. Это означает:

• Логин и пароль от почтового аккаунта передаются в открытом виде (Basic Auth при SMTP/IMAP)
• Тема письма видна полностью
• Вложения — да, тоже, если не зашифрованы отдельно

Единственная защита — PGP-шифрование, встроенное в Delta Chat. Текст самого сообщения ТСПУ не увидит даже при подмене сертификата. Но метаданные (отправитель, получатель, тема, время) — доступны.

Если бы Timeweb сразу сказал: «Да, у нас стоит ТСПУ от Роскомнадзора» — можно было бы копать в эту сторону с первого дня. Вместо этого пришлось потратить почти три дня на диагностику.

Решение 1: временный обход (работает прямо сейчас)

В Delta Chat на всех устройствах включите настройку:

Настройки аккаунта → Сертификаты → «Принимать недействительные»

✅ Работает мгновенно
⚠️ ТСПУ сможет читать содержимое писем (кроме зашифрованных PGP)
⚠️ Логин и пароль передаются в открытом виде

Важно: включите настройку на всех устройствах (Linux, macOS, Android, iOS). Если хотя бы одно устройство будет с «Автоматически» — сообщения с этого устройства не будут доставляться.

Решение 2: фикс #8313 (через 1–2 недели)

Разработчики Delta Chat уже выпустили PR #8313, который заменяет криптопровайдер ring на aws-lc-rs. Новый провайдер генерирует TLS-отпечаток, который ТСПУ не считает «чужим» — и подмены сертификата не происходит.

Что делать:

1. Следите за релизами chatmail/core
2. Когда в release notes появится aws-lc-rs — обновите Delta Chat на всех устройствах
3. Верните настройку сертификатов на «Автоматически»
4. Проверьте отправку через Beget/Timeweb

Решение 3: долгосрочное — перенос на Яндекс

Если не хочется зависеть от ТСПУ провайдера вообще — перенесите почту на Яндекс:

1. IP-диапазоны Яндекса в белом списке ТСПУ — трафик не инспектируется
2. Никаких подмен сертификатов, никаких «недействительных»
3. В Delta Chat укажите imap.yandex.ru и smtp.yandex.ru
4. Beget/Timeweb оставьте только как DNS-хостинг

Issue #8314: расскажите разработчикам о своей проблеме

Если у вас аналогичная ситуация — добавьте свой кейс в issue #8314 на GitHub:

https://github.com/chatmail/core/issues/8314

Рекомендации:

• Подпишитесь (Watch) — будете получать уведомления о фиксе
• Напишите комментарий с вашим опытом: провайдер, хостинг, дата начала проблемы
• Приложите лог Delta Chat с таймаутами на SMTP 465

Что сказать Timeweb публично

Timeweb не управляет ТСПУ — оборудование устанавливается оператором связи. Но их IP-диапазоны попали под инспекцию, а поддержка два дня валила проблему на клиента вместо того, чтобы признать: «у нас проблемы с ТСПУ».

Аргументы:

• Проблема воспроизводится на 4 платформах (Linux, macOS, Android, iOS) и в разных сетях
• Стандартные клиенты (Thunderbird, Outlook) работают — не-Delta-Chat клиенты нет
• Лог Delta Chat показывает TCP-таймауты на SMTP 465 при валидном сертификате
• openssl-тест подтверждает: сертификат сервера корректен

Вывод: ТСПУ сужает аудиторию почтовых клиентов. Если вы используете Delta Chat — либо переносите почту на Яндекс/Mail.ru, либо включайте «Принимать недействительные сертификаты».

FAQ

Почему Delta Chat сломался, а Thunderbird работает?

Delta Chat использует криптопровайдер ring из библиотеки rustls, который генерирует уникальный TLS-отпечаток (JA3 fingerprint). ТСПУ определяет его как «чужой» и подменяет сертификат. Thunderbird использует Mozilla NSS — системный провайдер с «родным» отпечатком, который ТСПУ пропускает.

Что будет, если включить «Принимать недействительные сертификаты»?

Delta Chat перестанет проверять TLS-сертификат сервера и примет подменный сертификат от ТСПУ. ТСПУ сможет читать трафик между клиентом и сервером, включая логин и пароль. E2E-шифрование Delta Chat (PGP) между пользователями сохраняется — ТСПУ видит только «трубу».

Когда выйдет фикс и как его узнать?

Фикс (#8313) уже в main-ветке. Ожидаемый релиз — 1–2 недели с момента обнаружения проблемы (июнь 2026). Следите за релизами chatmail/core — ищите упоминание aws-lc-rs в release notes.

Поможет ли VPN?

Не всегда. Если exit-нода VPN находится в России — трафик всё равно пройдёт через ТСПУ. Даже при зарубежной ноде MITM-подмена сертификата происходит на уровне SMTP/IMAP до входа в VPN-туннель.

Стоит ли переносить почту на Яндекс?

Если вы активно используете Delta Chat и не хотите включать «Принимать недействительные» — да, стоит. IP-диапазоны Яндекса в белом списке ТСПУ, подмены сертификатов нет. Beget/Timeweb можно оставить как DNS-хостинг.

Заключение

История с Delta Chat и ТСПУ — наглядный пример того, как государственная цензура влияет не на все почтовые клиенты одинаково. TLS fingerprinting через JA3 стал новым фильтром в интернете, и разработчикам приходится адаптироваться.

Что делать прямо сейчас:

1. Включите «Принимать недействительные сертификаты» на всех устройствах с Delta Chat
2. Подпишитесь на issue #8314 для отслеживания фикса
3. Рассмотрите перенос почты на Яндекс 360 как долгосрочное решение

Статья основана на реальном кейсе диагностики проблемы с Delta Chat, Beget и Timeweb в июне 2026 года. Если у вас похожая ситуация — поделитесь опытом в issue #8314.