Я вчера открыла очередной бриф, где безопасность переписки подаётся как магический щит, через который не пройдёт ни одна слежка, — и поняла: пора разложить эту механику на пальцах. Без криптотреша, без конспирологии, без сказок про «полную анонимность». Только то, что реально происходит с вашими сообщениями, когда в диалоге горит заветный замочек.
Сквозное шифрование в мессенджерах — это архитектура, при которой ключ для расшифровки есть только на устройствах собеседников. Сервер-доставщик работает как глухой курьер: таскает пакеты между адресатами, но внутрь не заглядывает. Звучит красиво. Но дальше начинаются детали, в которых обычно и прячется вся дрянь — от облачных чатов Telegram до бизнес-аккаунтов WhatsApp, где «шифрование» есть, а приватности нет.
Механика E2EE: от протокола Signal до алгоритма Double Ratchet
Когда вы нажимаете «отправить» в Signal, ваше сообщение не просто шифруется паролем — оно прогоняется через многослойную криптографическую машину. В основе лежит протокол X3DH (Extended Triple Diffie-Hellman): он согласует общий секрет между двумя сторонами ещё до первого сообщения, используя связку из долгосрочных и одноразовых ключей. Стороны взаимно аутентифицируются по открытым ключам, и даже если злоумышленник перехватил начальный handshake, расшифровать последующий поток он не сможет — благодаря свойству forward secrecy («прямая секретность»): компрометация одного ключа не обрушивает всю предыдущую переписку.
Поверх X3DH работает алгоритм Double Ratchet («двойная храповик-трещотка»). Название неслучайно: каждый переданный ключ обновляется, как шестерёнка в механизме часов, которая проворачивается только в одну сторону. Для каждого сообщения выводится новый ключ, стороны передают значения открытого ключа Diffie-Hellman, а результаты DH-вычислений примешиваются к производным ключам. Эта схема даёт защиту от двух противоположных сценариев:
- Ранняя компрометация — когда атакующий успел стянуть текущий ключ.
- Поздняя компрометация — когда ключ утечёт через час, день или месяц.
В каждом из этих случаев часть сообщений останется под бронёй. Неприятно для атакующего, привычно для нас с вами — мы-то как раз и хотим, чтобы утечка одного пароля не превращалась в слив всего чата.
E2EE — это не кнопка «сделать безопасно». Это инженерный контракт: ключ расшифровки хранится только на устройствах участников. Всё остальное — частный случай, исключение или маркетинг.
Масштабируемость защиты: стандарт MLS и будущее групповых чатов
До 2023 года у сквозного шифрования была одна большая проблема: группы. Личные чаты закрывались легко — двое, один общий секрет, обновление ключей по цепочке. Но стоило собрать рабочий чат на пятьдесят человек — или на пятьсот, как в больших корпоративных беседах, — математика начинала кричать. Обновление ключей в больших группах на классических схемах быстро становилось тяжёлым: чем больше участников, тем больше операций на каждое изменение состава, тем заметнее задержки и нагрузка на клиент. Особенно это чувствовалось в чатах, где люди постоянно заходят и выходят, меняют устройства, отваливаются от сети на сутки, а потом возвращаются с вопросом «а почему у меня не отправляется?»
В июле 2023 года IETF опубликовала RFC 9420 — стандарт Messaging Layer Security (MLS). Его суть: древовидная схема управления ключами, где обновление общего группового ключа обходится логарифмически — то есть с ростом группы затраты растут не линейно и не квадратично, а как логарифм от числа участников. Протокол рассчитан на асинхронные сценарии: участник может быть офлайн, появляться через неделю, переключаться между устройствами — и всё равно получать актуальные ключи при следующем заходе.
MLS явно таргетирован на группы размером от двух человек до «тысяч участников» — именно так сформулировано в RFC. Это меняет расклад для всех мессенджеров, которые до сих пор использовали собственные костыли для шифрования больших бесед. Signal продолжает работать с собственной схемой для групп на базе Sender Keys с регулярной ротацией, а индустрия в целом движется в сторону MLS как общего знаменателя. Если вы работаете с B2B-коммуникациями в Telegram-чатах на сотни человек — обратите внимание: ваша «защищённая» беседа, скорее всего, до сих пор работает по старой схеме, и шифрование там опционально.
| Параметр | Signal (X3DH + Double Ratchet) | MLS (RFC 9420) |
|---|---|---|
| Типовая модель | Личный чат или малая группа | Группа от 2 до тысяч участников |
| Обновление ключей | Линейно по числу участников | Логарифмически по размеру группы |
| Готовность индустрии | Зрелый, проверен годами | Стандарт с 2023 года, активное внедрение |
| Forward / post-compromise secrecy | Да | Да, по дизайну протокола |
Различия в реализации: почему облачные чаты Telegram — это не E2EE
Теперь к главной боли русскоязычного SMM-сообщества. Telegram — отличная платформа с кучей фичей, сторис-функционалом, чат-ботами и личными каналами. Но когда мне говорят «у нас же всё зашифровано, мы же в Телеге», хочется снять с полки документацию и потыкать в неё пальцем.
В Telegram сквозное шифрование — это исключение для Secret Chats. Это личные чаты один на один, где ключ хранится только у участников и сервер доставки его не видит. Для всех остальных чатов — обычных личных переписок, групповых бесед, каналов — работает другая схема: сервер Telegram имеет техническую возможность получить доступ к содержимому сообщений, иначе не работали бы синхронизация между устройствами и облачная история. В технической документации Telegram на это указывает напрямую: MTProto — протокол клиент-серверного шифрования с серверными ключами.
Ключевой нюанс, о котором не пишут в промо: для Secret Chats в Telegram действуют конкретные правила ротации ключей. После использования ключа для шифрования и расшифровки более ста сообщений либо после более чем недели использования при наличии хотя бы одного зашифрованного сообщения запускается повторное согласование ключа. Это нормальная практика, но она же напоминание: один ключ — не навсегда. Если вы держите в Secret Chat архив переписки и ни разу не обновляли клиент, ваш ключ может быть старше, чем кажется.
«У нас сквозное шифрование» в маркетинге мессенджера ≠ «все мои чаты защищены сквозным шифрованием». Это два разных высказывания, и второе почти всегда ложь.
Бизнес-аккаунты и резервные копии: где рвётся цепь безопасности
WhatsApp — один из немногих мессенджеров, который по умолчанию включает E2EE во все личные чаты. Но мы работаем с клиентами, а клиенты работают с клиентами, и тут начинается совсем другая история.
Meta прямо указывает: переписка с бизнесом в WhatsApp остаётся сквозно зашифрованной, если бизнес использует WhatsApp Messenger, WhatsApp Business или самостоятельно размещённый WhatsApp Business API. Стоит бизнесу подключить стороннего поставщика (а таких провайдеров в России и СНГ — десятки: Wazzup, Chat2Desk, Radist, интеграторы amoCRM), как цепочка безопасности рвётся. Meta формулирует это без двусмысленностей: при таком сценарии переписка не считается сквозно зашифрованной, потому что поставщик получает доступ к сообщениям.
Что это значит для SMM-стратега, который ведёт бизнес-аккаунт клиента через сервис рассылок? Каждое ваше «Здравствуйте, чем помочь?» хранится на серверах третьей стороны. Это не ужас-ужас, но это важно знать до того, как вы обещаете клиенту «абсолютную приватность всех коммуникаций». В кринжовых SMM-брифах это всплывает регулярно — когда в колонке «защита данных» стоит «WhatsApp», а в реальности клиент общается через интегратор, который видит всю переписку в админке.
Вторая дыра — резервные копии. Чат в WhatsApp зашифрован сквозным шифрованием, отлично. Но как только вы делаете бэкап в iCloud или Google Drive, вы выводите переписку за пределы криптографического контура. Резервное копирование — отдельный канал защиты, и по умолчанию он может быть не зашифрован. 30 октября 2025 года Meta объявила о поэтапном внедрении сквозного шифрования резервных копий с возможностью использовать passkey — отпечаток пальца, распознавание лица или код разблокировки устройства — вместо классического 64-значного ключа, который никто никогда не запоминал. Звучит красиво. Но фактическая доступность функции — другая история: поэтапное внедрение означает, что у вас её может ещё не быть, и проверять нужно в каждом конкретном случае.
Кстати, о запоминании: даже 64-значный ключ — не гарантия защиты. Если он лежит в заметках на том же телефоне, который защищён вашим же отпечатком, мы снова вернулись к человеческому фактору.
Человеческий фактор: почему шифрование не спасает от социальной инженерии
Самая раздражающая часть моей работы — момент, когда клиент с идеальной архитектурой безопасности умудряется слить всё сам. Никакой X3DH не спасёт вас, если вы:
- Пересылаете код подтверждения из «службы безопасности банка» в личку.
- Кликаете по ссылке из «письма от Dropbox», которое на самом деле фишинг.
- Читаете QR-код для «входа в WhatsApp», потому что «коллега скинул».
Signal — разработчик одного из самых защищённых протоколов на планете — прямо предупреждает в своей документации: сквозное шифрование не защищает от фишинга, выдачи себя за доверенный контакт или сервис, от заражённого устройства или от сознательной пересылки сообщения получателем. Это не баг протокола — это фундаментальное свойство любой системы: её безопасность определяется самым слабым звеном, а самое слабое звено почти всегда сидит за экраном.
В моей практике самый частый факап — не взлом протокола, а скомпрометированный аккаунт через подбор пароля или через SIM-своп. У вас может быть идеально настроенный Signal с включённой блокировкой экрана и PIN-кодом регистрации — но если ваш аккаунт в Telegram угнали через перехват SMS, никакие технические красоты криптографии уже не спасут. Сервер доставки выдаст ваш аккаунт тому, кто контролирует SIM-карту, а содержимое облачных чатов послушно подъедет к нему в комплекте.
Что на практике работает как страховка:
1. Двухфакторная аутентификация везде, где она есть, — отдельный пароль плюс аппаратный ключ, а не только SMS.
2. Минимальный пароль на резервную копию — и хранить его в менеджере паролей, а не в голове и не на стикере.
3. Проверка кодовой фразы в Signal (safety number) при каждом значимом контакте — если ваш собеседник переустановил приложение или сменил устройство, фраза изменится, и это повод перезвонить голосом и убедиться, что вы общаетесь с тем, с кем надо.
4. Разделение каналов: рабочие чаты — в одном мессенджере, личные — в другом, чувствительные переписки — в третьем, желательно с E2EE по умолчанию и минимальным облачным следом.
Протокол защищает переписку. Человек защищает протокол. Если вы лично готовы игнорировать обновления безопасности, переходить по ссылкам от «курьера СДЭК» и шарить QR-код входа с кем попало, то хоть X3DH с двойной храповик-трещоткой не поможет.
Что в итоге: позиция по существу, без маркетингового дыма
Сквозное шифрование в мессенджерах — это не магический амулет, а конкретная инженерная договорённость: ключ расшифровки хранится на устройствах участников, и сервер доставки его не видит. Когда эта договорённость соблюдается (Signal, WhatsApp в личных чатах, MLS-совместимые группы), переписка действительно защищена от перехвата на промежуточных узлах. Когда она не соблюдается — а это все облачные чаты Telegram, переписка с бизнесом через сторонние API и незащищённые резервные копии — замочек в интерфейсе рисуется скорее для красоты.
В 2026 году у нас есть рабочий MLS-стандарт для больших групп, есть Telegram с честным разделением на Secret Chats и облачные чаты, есть WhatsApp с попытками закрыть дыру в резервных копиях через passkey. Осталось, чтобы эти знания дошли до тех, кто продаёт «безопасность переписки в Telegram и WhatsApp» в составе коммерческого предложения. Технический прогресс уже случился — вопрос в том, отстанет ли от него индустрия, которая любит красивые лозунги больше, чем скучные таблицы ротации ключей.
