VPN и сквозное шифрование: кто что может прочитать
VPN защищает маршрут, мессенджер защищает содержимое. Сравните выход, релей и получателя, прежде чем предполагать, что кто-то из них скрывает сообщение.
Проследите одно сообщение от телефона до друга, и вы увидите, что оно проходит как минимум через два разных вида защиты. VPN покрывает маршрут между клиентом и его шлюзом, мессенджер покрывает содержимое между устройствами участников. Ни один не заменяет другой, и полезный вопрос не в том, что сильнее, а в том, кто на каждом шаге что может прочитать. Пройдите этот путь один раз, и роли станут очевидны.
Две защиты, два конца
На отправляющем устройстве приложение шифрует сообщение ключами, принадлежащими беседе, а затем передаёт шифротекст операционной системе. VPN, если он активен, упаковывает весь трафик, соответствующий его политике, и доставляет его к шлюзу. Оттуда пакет идёт по обычному интернету к серверам приложения, которые переправляют его получателю. Только на устройстве получателя есть ключ, превращающий шифротекст обратно в текст.
Релей на этом пути может видеть, как сообщение приходит и уходит, не читая его, и именно это свойство должно обеспечивать сквозное шифрование.
Что выход VPN может и не может прочитать
Шлюз VPN расшифровывает туннель, а не содержимое приложения. Он может наблюдать, к какому серверу обратился клиент, когда и сколько данных передано, а затем переправлять пакеты дальше. Это существенный набор фактов и гораздо меньший набор, чем текст сообщения. На обычном сайте HTTPS соединение TLS завершается на сайте, поэтому сайт может прочитать отправленное, даже если VPN не может. Разница в том, где заканчивается каждый слой, а не в том, какой продукт приватнее.
Смените назначение на сервис со сквозным шифрованием, и релей посередине теряет содержимое, а VPN по-прежнему видит картину соединения.
Ключи принадлежат беседе, а не маршруту
Ключи содержимого согласуются между участниками и остаются на их устройствах; VPN не участвует в этом обмене. Приложения часто показывают номер безопасности или отпечаток ключа, чтобы обе стороны могли сравнить то, что у них есть. Это сравнение выявляет подменённый ключ посередине, что ценно и уже, чем доказать, кто печатает. Подтверждение личности человека по-прежнему требует канала вне приложения, например звонка или проверки лично. Проверка серверного сертификата VPN удостоверяет совсем другую конечную точку.
Не читайте подтверждённый номер безопасности как доказательство владения аккаунтом. Это доказательство о ключах, а не о людях.
Копии, метаданные и другое устройство
Читаемое содержимое существует на концах, поэтому концы решают, что будет дальше. Прежде чем решать, насколько помогает туннель, составьте короткую карту мест, куда может попасть копия.
| Point | Can it read the message | Why |
|---|---|---|
| Sending device | Yes | Content exists before encryption |
| VPN gateway | No | Terminates the tunnel, not the app keys |
| App relay | No, by design | Only ciphertext passes through |
| Recipient device | Yes | Holds the conversation keys |
| Cloud backup | Depends on the product | May store plaintext or an encrypted archive |
Прочитайте правила приложения о резервных копиях, связанных устройствах, уведомлениях и экспорте, потому что каждое из них — отдельная копия со своей обработкой. Сеть всё равно раскрывает время и объём, даже когда содержимое защищено, а VPN меняет то, какой провайдер видит локальное соединение, но не то, существуют ли такие метаданные. Файл, экспортированный из защищённой беседы, сохраняет защиту, которую даёт его формат, и туннель после этого для него ничего не делает.
Выбирайте защиту под то, что она покрывает: приложение для содержимого и ключей, VPN для маршрута и вида локальной сети. Затем перечислите копии и устройства, которые остаются вне обеих.