Сквозное шифрование — дополнительный слой, а не разрешение игнорировать предупреждения TLS или доверять изменённому коду.
TLS и сквозное шифрование создают две разные границы. Эти границы важны и при оценке VPN и прокси. TLS обычно защищает соединение вашего устройства с сервисом; правильно реализованное сквозное шифрование с аутентификацией защищает содержимое разговора вплоть до устройства получателя. Чтение слоя TLS не обязательно означает чтение сквозно зашифрованного содержимого, но из этого нельзя делать вывод, что безопасность TLS больше не важна.
Если посредник может завершить защищённое соединение на своей стороне, то помимо просмотра передаваемых данных он может изменить ответы или код веб-приложения. Поэтому выражение «обход TLS с помощью LVR1» не является подходящим описанием безопасности мессенджера.
Как корневой сертификат делает возможной инспекцию?
При соединении HTTPS устройство проверяет цепочку сертификатов сервера и имя хоста. Если посредник предъявляет сертификат, который приложение считает действительным, он может создать два отдельных соединения: одно с пользователем, другое с настоящим сервером. В таком случае посредник является конечной точкой одного из соединений TLS, а не наблюдателем, который взломал шифрование, просто рассматривая пакеты.
Одной установки произвольного сертификата недостаточно: приложение должно ему доверять, а проверки соединения должны завершиться успешно. Документация Android по настройке сетевой безопасности объясняет, что политика доверия может различаться у разных приложений. Приложения, ориентированные на Android 7.0 и новее, по умолчанию не доверяют сертификатам, добавленным пользователем, если не настроены иначе.
Это общий технический механизм. Без доказательств он не позволяет судить о конкретном операторе, стране или инциденте. Сбой или фильтрация сами по себе не доказывают успешную инспекцию TLS.
Что можно увидеть, если TLS раскрыт?
| Тип данных или ситуация | Возможное последствие инспекции TLS |
|---|---|
| Содержимое, защищённое только HTTPS | Доверенный посредник может увидеть текст |
| Сообщение, уже зашифрованное действительным ключом получателя | Посредник обычно видит шифротекст, а не текст сообщения |
| Данные маршрутизации, сеанса или вспомогательных запросов | Степень раскрытия зависит от формата и устройства сервиса |
| Код веб-версии, поступающий тем же путём | Изменение кода может угрожать безопасности конечной точки |
| Сервис недоступен или трафик заблокирован | Шифрование само по себе не устанавливает соединение |
Защита содержимого с помощью E2EE также зависит от подлинности ключа получателя и целостности программного обеспечения обеих сторон. Если злоумышленник подменит исходный ключ или изменит приложение, которое видит сообщение до шифрования, одного наличия AES или ML-KEM недостаточно.
Почему веб-версии нужен безопасный TLS?
Веб-приложение обычно получает исполняемый код с сервера. Если этот код вредоносен, он может получить доступ к содержимому до шифрования или после расшифрования. Сквозное шифрование нельзя оценивать независимо от способа доставки и исполнения кода.
В установленной версии тоже важны подлинность пакета, обновления и целостность операционной системы. Подпись пакета и проверка хеша полезны, но не являются полной проверкой безопасности приложения. Модель угроз Livara также отмечает: если злоумышленник изменит и файл, и отображаемый хеш, совпадение хешей само по себе не докажет подлинность.
Что заявляет Livara?
Согласно документации по безопасности Livara, личные сообщения используют LVR1, а совместимые закрытые группы — LGS1. Документация описывает сочетание P-256 и ML-KEM-768 и шифрование содержимого сообщений. Это заявления о продукте, а не результаты независимого аудита в этой статье.
На той же странице указаны сохранение метаданных маршрутизации и публичный характер каналов публикации. Поэтому верный вывод — не «вся информация скрыта» и не «никакого доверия в сети не требуется». Вывод в том, что защиту частного содержимого нужно рассматривать отдельно от соединения, доставки ключей, кода приложения и метаданных.
Что делать при предупреждении о сертификате?
- Не игнорируйте предупреждение браузера или приложения ради продолжения конфиденциального разговора.
- Проверьте дату на устройстве и точный адрес сервиса: не каждая ошибка сертификата обязательно означает атаку.
- Если устройство принадлежит организации, уточните политику управления и установленные сертификаты у уполномоченного ответственного; не меняйте управляемые настройки самовольно.
- Не устанавливайте сертификат или профиль лишь по просьбе из неизвестного сообщения.
- В конфиденциальных разговорах сверяйте отпечаток ключа с собеседником по независимому каналу: сверка ключа не заменяет устранение предупреждения TLS.
Частые вопросы
Решает ли VPN все эти проблемы?
Нет. VPN может изменить путь наблюдения за трафиком, но не исправляет автоматически заражённое устройство, вредоносный доверенный сертификат или изменённый веб-код.
Достаточно ли аутентификации без отправки пароля?
Нет. Протокол аутентификации, управление сеансом и шифрование сообщений выполняют разные функции. Поддельная страница входа или вредоносный код могут получить сам ввод пользователя ещё до выполнения протокола.
Практический принцип: E2EE — ценный слой защиты; не считайте его разрешением игнорировать сертификаты, подлинность приложения или проверку ключей.
