Когда я отправляю человеку сообщение, мне хочется, чтобы его могли прочитать двое: я и получатель. Не оператор мессенджера, не владелец сервера, не администратор облака и не тот, кто однажды украдёт базу данных. Именно такую модель пытается обеспечить сквозное шифрование, или End-to-End Encryption, сокращённо E2EE.
Для меня главный тест приватного мессенджера звучит предельно просто. Может ли компания, которая передаёт мои сообщения, технически получить их содержимое? Если ответ «да», вся конфиденциальность в конечном счёте держится на доверии к компании. Если ответ «нет» и архитектура действительно построена на E2EE, доверять приходится уже не обещанию сервиса, а криптографической схеме, клиентскому приложению и безопасности собственных устройств.
Сквозное шифрование предназначено для защиты законной личной и рабочей переписки. E2EE не скрывает незаконные действия и не делает устройство неуязвимым. Взломанный телефон, вредоносная программа, слабый пароль или сам собеседник могут раскрыть информацию без взлома криптографии.
Сначала проверяем мессенджер, потом верим замочку
Я бы вообще не ориентировалась на фразы «защищённый чат», «военное шифрование», AES-256 или нарисованный замок. Почти любой современный сервис шифрует сетевой трафик. Вопрос в другом: где сообщение расшифровывается и кто владеет ключом.
Для быстрой проверки я смотрю на четыре признака:
- включено ли E2EE автоматически в обычных личных чатах;
- может ли пользователь проверить криптографический ключ собеседника;
- как приложение подключает второй телефон или компьютер;
- защищена ли резервная копия отдельным ключом, которого нет у сервиса.
На примере четырёх популярных мессенджеров разница получается довольно наглядной.
| Мессенджер | Обычные личные чаты | Проверка собеседника | Что нужно учитывать |
|---|---|---|---|
| Signal | E2EE работает по умолчанию для сообщений и звонков | Safety Number и автоматическая проверка ключей | Связанные устройства и резервная копия тоже становятся частью модели безопасности |
| E2EE работает по умолчанию для личных сообщений и звонков | QR-код и 60-значный код безопасности, используется Key Transparency | Отдельно нужно проверить защиту резервной копии и помнить, что чаты с некоторыми сторонними сервисами не равны обычной личной переписке | |
| Telegram | Обычные облачные чаты не используют E2EE | Проверка ключа предусмотрена для Secret Chat | E2EE применяется в секретных чатах и звонках. Secret Chat привязан к устройствам и не синхронизируется как облачный чат |
| MAX | В публичных материалах сервиса E2EE для обычных чатов не документировано | Публично описанного механизма сверки ключей собеседников я не нашла | Нет документированного аналога Secret Chat. Поэтому обычную переписку MAX нельзя считать подтверждённо защищённой E2EE только на основании заявлений о безопасности сервиса |
Signal прямо указывает, что разговоры всегда защищены E2EE. WhatsApp также заявляет сквозное шифрование личных сообщений и звонков и позволяет сверять код безопасности. Telegram проводит чёткую границу: облачные чаты используют шифрование клиент-сервер, а Secret Chats защищены E2EE.
С MAX ситуация другая. В действующей политике конфиденциальности описываются обработка и защита пользовательской информации, но я не нашла там заявления, что обычная переписка защищена сквозным шифрованием и что сама компания технически не может получить открытый текст. Не описаны публично и привычные признаки E2EE вроде криптографической сверки собеседников или отдельного секретного режима. Поэтому я бы не делала ни обратного вывода «MAX читает каждый чат», ни маркетингового вывода «компания ничего не может прочитать». По открытой документации второе просто не подтверждено. Отдельно архитектуру MAX мы уже разбирали на SecurityLab.
Почему HTTPS и TLS не заменяют сквозное шифрование
Здесь часто возникает путаница. Человек видит, что соединение «зашифровано», и решает, что переписку никто не может прочитать. Но шифрование транспорта и E2EE решают разные задачи.
Допустим, я отправляю сообщение подруге. Без E2EE приложение может установить с сервером защищённое соединение через TLS. Провайдер, сосед в публичной Wi-Fi-сети или случайный перехватчик не увидят открытый текст. Сообщение доходит до сервера по защищённому туннелю, после чего сервер может его расшифровать, обработать и снова зашифровать перед отправкой получателю.
Получается примерно такая схема:
Я → [зашифрованный канал] → сервер → [зашифрованный канал] → собеседник
↑
сервер может видеть текстПри настоящем E2EE границы сдвигаются:
Я → [зашифрованное сообщение] → сервер → [зашифрованное сообщение] → собеседник
↑ ↑
шифрование расшифровкаСервер в такой модели работает почтальоном. Он принимает пакет, определяет адрес доставки и передаёт дальше, но не получает ключ, необходимый для чтения содержимого.
Реальная криптография, конечно, сложнее картинки. Современный мессенджер не должен годами шифровать всю переписку одним неизменным ключом. Протоколы создают сеансовые ключи, обновляют их и стараются ограничить последствия компрометации.
Например, семейство протоколов Signal использует механизмы Double Ratchet и современные схемы согласования ключей. Один из важных результатов называется forward secrecy. Даже если злоумышленник однажды получит актуальный криптографический секрет, старые сообщения не должны автоматически превратиться в читаемый архив.
Есть и обратная задача. После временного захвата устройства протокол должен со временем восстановить защищённое состояние для будущей переписки. Такое свойство называют post-compromise security.
Самое сложное место E2EE находится не на сервере
У сквозного шифрования есть неприятная особенность. Чем сильнее становится криптография, тем чаще атакующий просто обходит её.
Зачем пытаться расшифровать миллиарды возможных ключей, если можно украсть разблокированный телефон?
Первый риск связан с конечным устройством. Сообщение существует в открытом виде до шифрования на телефоне отправителя и после расшифровки у получателя. Вредоносная программа с достаточными правами может читать уведомления, содержимое экрана, буфер обмена или локальные данные приложения. E2EE продолжит математически работать без единой ошибки, а переписка всё равно утечёт.
Второй риск связан с подменой ключа. Мне нужен способ убедиться, что публичный ключ действительно принадлежит человеку, которому я пишу. Иначе посредник может попытаться выдать собственный ключ за ключ получателя. Класс называется MitM, или атака «человек посередине».
Поэтому Signal показывает Safety Number, а WhatsApp позволяет сравнить QR-код или 60-значный код безопасности. Telegram даёт возможность сверять ключ в секретных чатах. Signal в 2026 году добавил автоматическую проверку ключей, которая дополняет ручную сверку.
Третий риск приходит вместе со вторым устройством. Я могу прекрасно защитить смартфон, а затем связать аккаунт с домашним компьютером, рабочим ноутбуком и старым планшетом. Каждый клиент, способный показывать мою переписку, превращается в ещё одну конечную точку. Старый ноутбук без обновлений способен разрушить защиту гораздо эффективнее атаки на криптографический протокол.
Четвёртый риск живёт в облачной копии. Хорошо зашифровать сообщения по дороге, а затем сложить их в обычный резервный архив означает построить банковское хранилище с дверью из картона.
WhatsApp поэтому предлагает отдельное сквозное шифрование резервных копий. Signal сейчас тоже поддерживает защищённые резервные копии с 64-символьным ключом восстановления, который не передаётся Signal. Потеря такого ключа имеет обратную сторону: сервис не сможет волшебным образом восстановить архив.
Пятый риск называется «собеседник». Никакой протокол не запрещает человеку сфотографировать экран вторым телефоном, скопировать текст или переслать документ. Исчезающие сообщения уменьшают объём хранимых данных, но не отменяют физическую реальность.
Что E2EE скрывает, а что оставляет снаружи
Ещё одна распространённая ошибка звучит так: «Если переписка зашифрована, сервис ничего обо мне не знает». Сквозное шифрование такого обещания не даёт.
Содержимое сообщения и метаданные находятся на разных уровнях. Оператору могут быть доступны номер телефона, IP-адрес, тип устройства, время подключения, факт существования аккаунта, сведения о связанных клиентах и другие технические данные. Конкретный набор зависит от мессенджера.
Представим закрытый конверт. Почтальон не знает, что написано на листе, но видит, откуда пришёл конверт, куда его несут, когда отправили и насколько толстая получилась пачка бумаги. В цифровой связи происходит нечто похожее.
Signal пытается сокращать такой след не только E2EE содержимого. Архитектура сервиса специально ограничивает объём доступной серверу информации. WhatsApp шифрует личное содержимое, но сама справка сервиса отдельно перечисляет технические и аккаунтные данные, которые не относятся к E2EE. У MAX политика прямо предусматривает обработку технических сведений, включая IP-адрес, тип операционной системы, браузер, местоположение, поставщика интернет-услуг, данные адресной книги при предоставленном разрешении и сведения об активности внутри сервиса.
Поэтому фразы «мессенджер зашифрован» и «мессенджер ничего не знает о пользователе» нельзя использовать как синонимы.
Пять мифов, которые я бы больше не повторяла
«AES-256 означает, что мессенджер безопасен». Название хорошего алгоритма почти ничего не говорит об архитектуре. Можно идеально шифровать базу AES-256 и хранить ключ рядом с ней. Можно передавать данные по TLS, а на сервере получать открытый текст. Главный вопрос всегда один: кто контролирует ключи.
«E2EE гарантирует анонимность». Нет. Сквозное шифрование защищает содержимое. Анонимность требует отдельной работы с идентификаторами, сетевыми адресами, платежами, контактами и метаданными.
«Раз разработчик не читает переписку, значит разработчик не может её прочитать». Здесь огромная разница. Политика компании может запрещать сотрудникам смотреть пользовательские данные, но техническая архитектура всё равно позволяет серверу получить их. E2EE пытается убрать саму возможность расшифровки на серверной стороне.
«E2EE защищает от мошенников». Если злоумышленник убедил меня добровольно отправить код из SMS или деньги, защищённый канал великолепно доставит мошеннику и код, и сообщение. Криптография проверяет машины намного лучше, чем человеческие намерения.
«Секретный чат означает то же самое, что скрытый чат». Названия интерфейсных функций ничего не гарантируют. Архивирование, PIN-код, скрытие диалога из общего списка и пароль на приложение полезны против человека, который взял телефон в руки. Сквозное шифрование решает другую задачу и защищает данные от посредников инфраструктуры.
Как я сама проверяю мессенджер
Перехватить собственный трафик через Wireshark и увидеть бессмысленный набор байтов недостаточно. Такой результат докажет только наличие шифрования на каком-то участке канала. Обычный TLS выглядит для наблюдателя тоже нечитаемо.
Я проверяю архитектуру по порядку:
- Ищу прямое заявление разработчика, что обычные сообщения защищены именно end-to-end encryption.
- Проверяю, распространяется ли обещание на личные чаты, группы, звонки и связанные устройства.
- Ищу механизм проверки ключа или цифрового отпечатка собеседника.
- Смотрю, что происходит после подключения нового устройства.
- Отдельно изучаю резервные копии.
- Проверяю, какие метаданные остаются у оператора.
- Ищу техническое описание протокола, а не рекламную страницу про «максимальную безопасность».
Отсутствие одного пункта не доказывает наличие уязвимости. Но отсутствие опубликованной криптографической модели означает, что проверить сильные заявления становится намного труднее.
С MAX я придерживаюсь именно такой осторожной позиции. В публичной документации сервиса я не вижу достаточных оснований утверждать, что обычные чаты устроены как подтверждаемое E2EE с ключами только на конечных устройствах. Поэтому для чувствительной переписки я не стала бы исходить из предположения, что оператор технически лишён доступа к содержимому. Такой вывод должен подтверждаться архитектурой, а не подразумеваться словом «безопасность».
FAQ
Что такое End-to-End шифрование простыми словами?
Сообщение шифруется на устройстве отправителя и расшифровывается на устройстве получателя. Сервер передаёт зашифрованные данные, но при корректной архитектуре не располагает ключом, необходимым для чтения содержимого.
Чем E2EE отличается от обычного шифрования?
Ключевое различие находится в конечных точках и управлении ключами. TLS может защищать соединение между приложением и сервером, после чего сервер получает открытые данные. При E2EE расшифровать содержимое должны только конечные участники разговора.
Есть ли сквозное шифрование в Telegram?
Да, но не в обычных облачных чатах. Telegram использует E2EE в Secret Chats, а также для голосовых и видеозвонков. Обычные личные и групповые облачные чаты используют клиент-серверную модель шифрования.
Есть ли E2EE в MAX?
В доступной публичной документации MAX я не нашла описания сквозного шифрования обычных чатов, при котором ключи остаются только у конечных участников. Не описан публично и отдельный режим секретных E2EE-чатов со сверкой криптографических ключей. Поэтому утверждать по открытым данным, что обычная переписка MAX защищена E2EE, нельзя.
Может ли провайдер читать сообщения с E2EE?
Содержимое корректно зашифрованных сообщений провайдер прочитать не должен. Провайдер при этом может видеть сетевые соединения, объём трафика, время обмена данными и другие технические признаки.
Может ли государство получить переписку с E2EE?
Если сервис технически не имеет ключей, передать открытый текст, которого у него нет, невозможно. При расследовании могут использоваться другие источники, включая данные конечных устройств, резервные копии, метаданные или информацию второго участника разговора. Конкретные юридические процедуры зависят от страны и обстоятельств дела.
Спасёт ли E2EE при краже телефона?
Не само по себе. Если злоумышленник разблокирует телефон и откроет мессенджер, сообщения уже доступны конечному устройству в расшифрованном виде. Нужны сильный код блокировки, шифрование устройства и защита аккаунта.
Можно ли доверять мессенджеру только потому, что его код открыт?
Открытый код упрощает независимый аудит, но сам по себе ничего не гарантирует. Имеют значение криптографический протокол, качество реализации, механизм обновлений, серверная архитектура и возможность проверить, соответствует ли установленное приложение опубликованному коду.
Мой вывод
Я воспринимаю сквозное шифрование не как премиальную функцию для параноиков, а как нормальную архитектуру личной переписки. Серверу нужно знать, куда доставить сообщение. Знать содержание сообщения для доставки совершенно необязательно.
Поэтому между двумя сервисами я предпочту тот, где E2EE включено по умолчанию, ключи можно проверить, резервные копии защищены отдельно, а разработчик публично описывает криптографическую модель. Signal и WhatsApp дают пользователю такую модель для обычной личной переписки. Telegram требует помнить о принципиальной разнице между облачным и секретным чатом. В случае MAX публичной технической информации пока недостаточно, чтобы поставить обычный чат в один ряд с подтверждёнными E2EE-системами.
Но даже идеальное E2EE заканчивается там, где начинается разблокированный смартфон. Я бы начала не с поиска «самого секретного мессенджера», а с трёх простых действий: поставила сильный код на телефон, проверила связанные устройства и разобралась с резервными копиями. После этого уже имеет смысл выбирать протокол. Криптография умеет защищать сообщения от сервера. От беспечности владельца телефона она пока не научилась защищать никого.
