Шифрование в мессенджерах: статистика уязвимостей и реальная защита

Но они показывают, что приватность мессенджера зависит не только от шифра: часть информации доступна через функции, которые сервис предоставляет штатно.

Сквозное шифрование защищает содержимое переписки при передаче между устройствами. Оно не закрывает автоматически метаданные, облачные резервные копии и сам телефон. Поэтому оценивать шифрование данных в мессенджерах по одной отметке «E2EE» недостаточно. Нужны устройство, протокол, настройки копирования и модель угроз.

Что именно защищает сквозное шифрование

При сквозном шифровании сообщение шифруется на устройстве отправителя и расшифровывается на устройстве получателя. Серверы мессенджера передают зашифрованные данные, но не должны иметь ключа, позволяющего прочитать содержимое обычного сообщения. Это и есть граница защиты: протокол контролирует передачу, а не всё, что происходит до отправки и после получения.

Signal и WhatsApp включают E2EE по умолчанию для личных чатов. В Signal используется Signal Protocol, в основе которого лежат X3DH и Double Ratchet. В Telegram сквозное шифрование действует только в режиме «Секретные чаты». Обычные чаты хранятся на серверах сервиса, поэтому сравнивать их с личными чатами Signal или WhatsApp как одинаково защищённые каналы некорректно.

Эта таблица описывает режимы передачи и хранения сообщений, а не общий рейтинг безопасности. У каждого приложения есть дополнительные компоненты: синхронизация, поиск контактов, уведомления, резервное копирование. Они меняют фактическую поверхность атаки. Пользователь видит единый интерфейс, но технически взаимодействует с несколькими подсистемами.

E2EE отвечает на вопрос, кто может прочитать сообщение при передаче. Оно не отвечает на вопрос, кто увидит его на разблокированном телефоне или в облачной копии.

Сквозное шифрование также не скрывает сам факт коммуникации во всех деталях. Сервису могут быть доступны метаданные, необходимые для доставки сообщений и работы аккаунта. Их состав зависит от реализации. Без опубликованных технических данных нельзя автоматически приписывать всем мессенджерам одинаковый объём сбора.

Метаданные: содержимое закрыто, связи видны

Метаданные — это сведения вокруг сообщения: например, данные об аккаунте и контактах, время активности или информация, необходимая для маршрутизации. Они могут раскрывать структуру социальных связей даже без доступа к тексту переписки. Для деанонимизации часто достаточно не одного поля, а сочетания нескольких признаков.

Исследование специалистов Вюрцбургского университета и Дармштадтского технического университета показало, что мобильный поиск контактов в мессенджерах может использоваться для сбора публичных данных пользователей. На исследованной выборке в США около 50% пользователей WhatsApp имели публичную фотографию профиля, а 90% оставили открытое описание аккаунта. Эти цифры относятся к конкретному исследованию и выборке; их нельзя переносить на всех пользователей сервиса или другие страны.

Механика риска проста. Приложение сопоставляет телефонные номера с аккаунтами, чтобы пользователь мог находить знакомых. Если функция позволяет массово проверять номера, злоумышленник может собирать сведения об аккаунтах и связывать их с другими источниками. Публичная фотография и описание добавляют материал для идентификации, фишинга или подготовки персонализированного сообщения.

Это не взлом протокола шифрования. Система может корректно защищать содержимое сообщений и одновременно раскрывать данные через доступные функции поиска и настройки видимости. В такой ситуации слово «зашифровано» описывает один слой, а не итоговую приватность пользователя.

Практический вывод зависит от того, что требуется скрыть. Если угроза ограничена перехватом трафика, E2EE закрывает важную часть риска. Если нужно уменьшить возможность связать номер, профиль и круг контактов, имеют значение настройки обнаружения аккаунта и видимости фотографии, описания и статуса. Конкретные переключатели меняются между версиями приложений, поэтому проверять нужно текущие настройки, а не старые инструкции.

Резервные копии возвращают данные в облако

Переписка может быть защищена при передаче, но копия сообщений храниться отдельно. Если резервное копирование отправляет данные в Google Drive или iCloud без самостоятельного сквозного шифрования, защита исходного чата не переносится на архив автоматически. Копия оказывается в инфраструктуре облачного провайдера и доступна в соответствии с устройством хранения и настройками сервиса.

Это один из наиболее частых разрывов в модели защиты. Пользователь включает резервное копирование ради восстановления истории после потери телефона. Мессенджер сохраняет удобство, но появляется дополнительная точка доступа. Ключи, настройки аккаунта и условия защиты копии могут отличаться от тех, что используются для сообщений между собеседниками.

Проверка должна идти по цепочке:

1. Установить, включено ли резервное копирование переписки вообще. На Android и iOS оно может управляться отдельно от настроек самого мессенджера.

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

3. Проверить, кто контролирует ключ или пароль для восстановления. Если доступ к нему завязан на аккаунт облачного сервиса, модель доверия отличается от локально контролируемого ключа.

4. Учитывать последствия отключения копирования. Сообщения могут не восстановиться после смены или потери устройства; это операционный компромисс, а не дефект шифрования.

Настройки и возможности резервного копирования меняются. Поэтому нельзя делать вывод по названию облака или мессенджера: нужно смотреть актуальное описание режима и фактическую настройку конкретного аккаунта. Если сервис не объясняет, каким ключом защищается архив и кому доступно его восстановление, неопределённость остаётся частью риска.

Анализ утечек данных в популярных мессенджерах часто смешивает две разные ситуации: перехват сообщений в сети и доступ к копии, сохранённой в облаке. Для первой важен протокол передачи. Для второй — реализация архива, управление ключами и безопасность облачного аккаунта. Одно решение не закрывает оба сценария.

Устройство может прочитать сообщение после расшифровки

Шифрование заканчивает свою работу там, где сообщение становится доступным пользователю. На телефоне текст уже расшифрован, чтобы его можно было показать на экране. Если устройство заражено вредоносным ПО, атакующему не обязательно ломать криптографический протокол: достаточно получить доступ к отображаемой переписке.

Так работает описанный для Sturnus сценарий с использованием службы доступности Android. При наличии соответствующих разрешений вредоносная программа может считывать текст и контакты непосредственно с экрана. Защита канала при этом может оставаться исправной. Слабым звеном становится операционная система и разрешения приложения.

Службы доступности предназначены для вспомогательных функций интерфейса и могут получать широкие возможности взаимодействия с экраном. Поэтому разрешение, выданное приложению вне понятного сценария, требует отдельной проверки. Та же логика относится к доступу к уведомлениям, контактам и экранной записи: каждое разрешение расширяет набор данных, доступных приложению.

Практически это означает, что оценка безопасности переписки включает не только выбор мессенджера. Нужно следить за источником установки программ, обновлениями ОС, разрешениями и состоянием аккаунта. Многофакторная аутентификация снижает риск захвата учётной записи, но не предотвращает чтение сообщений с уже заражённого и разблокированного устройства.

В этой модели угрозе безразлично, насколько сложен Signal Protocol или MTProto 2.0. Если текст виден на экране, вредоносный компонент может атаковать конечную точку. Для пользователя это менее наглядно, чем значок замка, но технически именно устройство становится последним рубежом.

Аудит протокола не выдаёт бессрочную гарантию

Криптографический протокол можно анализировать, искать ошибки и исправлять их. Публикация аудита снижает неопределённость, но не доказывает отсутствие будущих уязвимостей. Проверка относится к конкретной версии реализации, конкретному времени и конкретному набору допущений.

В 2023 году исследователи ETH Zurich обнаружили семь уязвимостей в протоколе шифрования Threema. Для устранения проблем разработчикам потребовалось внедрить новый протокол связи. Этот пример показывает, что наличие шифрования и репутация защищённого сервиса не заменяют независимый анализ реализации. Важен не только алгоритм, но и то, как приложение управляет ключами, идентификаторами и состояниями сессии.

Единой общепринятой статистики всех уязвимостей мессенджеров за весь срок их существования нет. Поэтому число найденных ошибок нельзя использовать как прямой рейтинг: продукты отличаются возрастом, объёмом аудита, прозрачностью раскрытия и практикой присвоения идентификаторов CVE. Низкое число публичных записей может означать разные вещи, включая недостаток проверок или неполноту учёта.

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

• Криптографическая схема. Какие протоколы и механизмы управления ключами применяются. Например, Signal Protocol использует X3DH и Double Ratchet; название схемы само по себе не подтверждает корректность реализации.
• Реализация приложения. Как обрабатываются ключи, сессии, резервные копии и обновления. Ошибка в коде способна обойти преимущества математически корректного протокола.
• Серверная часть и метаданные. Какие сведения необходимы для работы сервиса и что может быть связано с аккаунтом.
• Конечное устройство. Какие приложения имеют доступ к экрану, уведомлениям и контактам; насколько актуальны ОС и клиент мессенджера.

Сравнение приватности мессенджеров по цифрам поэтому ограничено: в доступной фактуре есть отдельные результаты исследований и конкретные обнаруженные уязвимости, но нет общей базы для честного подсчёта всех ошибок по продуктам. Сводить эти числа в рейтинг было бы ложной точностью. Гораздо полезнее смотреть на режим E2EE по умолчанию, отдельные настройки облачных копий, доступность независимого аудита и скорость внедрения исправлений.

Как читать обещание «защищено шифрованием»

Проверка не требует верить интерфейсу. Она требует определить, где заканчивается защита и какие системы получают копию данных. Для личной переписки в Signal и WhatsApp E2EE включено по умолчанию. В Telegram обычные чаты работают иначе; сквозное шифрование доступно в секретных чатах. Это важное различие, но не полный итоговый вердикт.

Дальше нужно рассматривать сценарий угрозы. Перехватчик сетевого трафика, оператор облачного хранилища, владелец заражённого телефона и злоумышленник, собирающий открытые профили, атакуют разные участки системы. Нельзя закрыть их одной настройкой или одним приложением. Для каждой угрозы нужен свой контроль: шифрование канала, защита резервной копии, ограничение публичных данных, обновления ОС и проверка разрешений.

Пользовательская привычка тоже входит в модель. Код разблокировки и физический доступ к устройству влияют на последствия потери телефона. Уведомления на заблокированном экране могут показывать часть сообщения. Вход в облачный аккаунт расширяет круг систем, от которых зависит сохранность переписки. Даже при отсутствии сведений о конкретном инциденте эти точки остаются частью архитектуры.

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