VPN og ende-til-ende-kryptering: hvem kan læse hvad
En VPN beskytter ruten, beskedappen beskytter indholdet. Sammenlign udgangen, relæet og modtageren, før du antager, at en af dem skjuler beskeden.
Følg en besked fra en telefon til en ven, og den passerer mindst to forskellige former for beskyttelse. VPN’en dækker ruten mellem klienten og dens gateway, beskedappen dækker indholdet mellem deltagernes enheder. Ingen af dem erstatter den anden, og det nyttige spørgsmål er ikke, hvilken der er stærkest, men hvem der kan læse hvad ved hvert trin. Gå vejen igennem én gang, og rollerne bliver tydelige.
To beskyttelser, to ender
På afsenderenheden krypterer appen beskeden med nøgler, der hører til samtalen, og overdrager derefter chifferteksten til styresystemet. VPN’en pakker, hvis den er aktiv, al trafik ind, der matcher dens politik, og fører den til en gateway. Derfra rejser pakken over det almindelige internet til appens servere, som videresender den mod modtageren. Kun modtagerens enhed har den nøgle, der gør chifferteksten til tekst igen.
Et relæ på den vej kan se en besked komme og gå uden at læse den, og det er netop den egenskab, ende-til-ende-kryptering skal give.
Hvad VPN-udgangen kan og ikke kan læse
En VPN-gateway dekrypterer tunnelen, ikke appens indhold. Den kan observere, hvilken server klienten kontaktede, hvornår, og hvor mange data der blev flyttet, og derefter sende pakkerne videre. Det er et meningsfuldt sæt fakta og et meget mindre sæt end beskedens tekst. For et almindeligt HTTPS-websted slutter TLS-forbindelsen på webstedet, så webstedet kan læse det, der blev sendt, selv om VPN’en ikke kan. Forskellen handler om hvor hvert lag slutter, ikke om hvilket produkt der er mere privat.
Skift destination til en ende-til-ende-krypteret tjeneste, og relæet i midten mister indholdet, mens VPN’en stadig ser forbindelsesmønstret.
Nøgler hører til samtalen, ikke til ruten
Indholdsnøgler forhandles mellem deltagerne og bliver på deres enheder; en VPN deltager ikke i den udveksling. Apps viser ofte et sikkerhedsnummer eller et nøglefingeraftryk, så begge sider kan sammenligne, hvad de har. Den sammenligning opdager en udskiftet nøgle i midten, hvilket er værdifuldt og snævrere end at bevise, hvem der skriver. Bekræftelse af en persons identitet kræver stadig en kanal uden for appen, såsom et opkald eller et personligt tjek. En VPN’s servercertifikatkontrol verificerer en helt anden ende.
Læs ikke et bekræftet sikkerhedsnummer som bevis for kontoejerskab. Det er bevis om nøgler, ikke om mennesker.
Kopier, metadata og den anden enhed
Læsbart indhold findes ved enderne, så enderne afgør, hvad der sker næste gang. Lav et kort over de steder, hvor en kopi kan lande, før du beslutter, hvor meget tunnelen hjælper.
| 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 |
Læs appens regler for sikkerhedskopier, tilknyttede enheder, notifikationer og eksporter, fordi hver af dem er en separat kopi med sin egen håndtering. Netværket afslører stadig timing og volumen, selv når indholdet er beskyttet, og en VPN ændrer, hvilken udbyder der ser den lokale forbindelse, ikke om sådanne metadata findes. En fil, der eksporteres fra en beskyttet samtale, bevarer den beskyttelse, dens format giver, og tunnelen gør intet for den bagefter.
Vælg beskyttelsen til det, den dækker: appen til indhold og nøgler, VPN’en til ruten og udsynet til det lokale netværk. Opregn derefter de kopier og enheder, der ligger uden for begge.