VPN i szyfrowanie end-to-end: kto może przeczytać co
VPN chroni trasę, a aplikacja do wiadomości chroni treść. Porównaj wyjście, przekaźnik i odbiorcę, zanim założysz, że którekolwiek z nich ukrywa wiadomość.
Śledź jedną wiadomość od telefonu do znajomego, a zobaczysz, że przechodzi przez co najmniej dwa różne rodzaje ochrony. VPN obejmuje trasę między klientem a jego bramą, aplikacja do wiadomości obejmuje treść między urządzeniami uczestników. Żadne nie zastępuje drugiego, a użyteczne pytanie nie brzmi, które jest silniejsze, tylko kto na każdym etapie może przeczytać co. Przejdź tę drogę raz, a role staną się oczywiste.
Dwie ochrony, dwa końce
Na urządzeniu nadawcy aplikacja szyfruje wiadomość kluczami należącymi do rozmowy, a następnie przekazuje szyfrogram systemowi operacyjnemu. VPN, jeśli jest aktywny, opakowuje cały ruch zgodny z jego polityką i przenosi go do bramy. Stamtąd pakiet wędruje zwykłym internetem do serwerów aplikacji, które przesyłają go dalej do odbiorcy. Tylko urządzenie odbiorcy ma klucz, który zamienia szyfrogram z powrotem w tekst.
Przekaźnik na tej drodze może widzieć, jak wiadomość przychodzi i odchodzi, nie czytając jej, i właśnie tę właściwość ma zapewniać szyfrowanie end-to-end.
Co wyjście VPN może, a czego nie może przeczytać
Brama VPN odszyfrowuje tunel, a nie treść aplikacji. Może obserwować, z którym serwerem połączył się klient, kiedy i ile danych się przesunęło, a następnie przekazywać pakiety dalej. To znaczący zbiór faktów i znacznie mniejszy zbiór niż tekst wiadomości. W zwykłej witrynie HTTPS połączenie TLS kończy się w witrynie, więc witryna może przeczytać to, co wysłano, nawet jeśli VPN nie może. Różnica dotyczy gdzie kończy się każda warstwa, a nie tego, który produkt jest bardziej prywatny.
Zmień cel na usługę szyfrowaną end-to-end, a przekaźnik w środku traci treść, podczas gdy VPN nadal widzi wzorzec połączenia.
Klucze należą do rozmowy, nie do trasy
Klucze treści są negocjowane między uczestnikami i pozostają na ich urządzeniach; VPN nie bierze udziału w tej wymianie. Aplikacje często pokazują numer bezpieczeństwa lub odcisk klucza, aby obie strony mogły porównać to, co mają. To porównanie wykrywa podmieniony klucz w środku, co jest cenne i węższe niż udowodnienie, kto pisze. Potwierdzenie tożsamości osoby nadal wymaga kanału poza aplikacją, na przykład rozmowy lub sprawdzenia osobiście. Sprawdzenie certyfikatu serwera VPN weryfikuje zupełnie inny punkt końcowy.
Nie czytaj potwierdzonego numeru bezpieczeństwa jako dowodu własności konta. To dowód na temat kluczy, a nie ludzi.
Kopie, metadane i drugie urządzenie
Czytelna treść istnieje na końcach, więc końce decydują, co stanie się dalej. Zanim zdecydujesz, ile pomaga tunel, zrób krótką mapę miejsc, w których może wylądować kopia.
| 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 |
Przeczytaj zasady aplikacji dotyczące kopii zapasowych, połączonych urządzeń, powiadomień i eksportu, ponieważ każde z nich jest osobną kopią z własnym traktowaniem. Sieć nadal ujawnia czas i objętość, nawet gdy treść jest chroniona, a VPN zmienia to, który dostawca widzi połączenie lokalne, a nie to, czy takie metadane istnieją. Plik wyeksportowany z chronionej rozmowy zachowuje ochronę, jaką daje jego format, a tunel nie robi dla niego nic później.
Wybierz ochronę do tego, co obejmuje: aplikację do treści i kluczy, VPN do trasy i widoku sieci lokalnej. Następnie wypisz kopie i urządzenia, które znajdują się poza oboma.