Wat je VPN-provider kan zien en wat niet
De exit ziet adressen, tijden en, tenzij Encrypted Client Hello wordt gebruikt, de sitenaam in de TLS-handshake. Bewaring is een aparte vraag.
Je tunnel houdt het lokale netwerk buiten je verkeer. Hij verwijdert echter niet het bedrijf aan de andere kant, dat elk pakket verwerkt voordat het het open internet bereikt. Die positie is zowel het verdienmodel als de privacyvraag. De nuttige vraag is daarom niet of de provider je kan zien, maar wat hij ziet, wat hij kan benoemen en wat hij bewaart.
Waar het vertrouwen werkelijk verschuift
De versleuteling loopt van je apparaat naar de server van de provider, en dat buitenste stuk is alles wat je lokale netwerk ooit ziet. De provider houdt het andere uiteinde van dat stuk, dus hij ontsleutelt de tunnel en stuurt je pakketten door. Daar is niets mis mee; het is de definitie van de dienst die je hebt gekocht. Het vertrouwen verschoof van de lokale operator naar de operator van de exit in plaats van te verdwijnen.
Vanuit die positie leert hij je bronadres, wanneer je verbond, ongeveer hoeveel je overdroeg en welke bestemmingen je benaderde. Niets daarvan vereist je berichten te lezen, en dat is precies het punt van het scheiden van categorieën. De interessante verschillen tussen providers gaan over wat er daarna met die waarnemingen gebeurt.
Wat de exit noodzakelijkerwijs verwerkt
Sorteer de categorieën naar hoe betrouwbaar de exit ze kan zien. Geen van de rijen vereist het breken van versleuteling, en elke rij heeft een ander antwoord op de vraag of die überhaupt te vermijden is.
| Category | Visible at the exit | Why |
|---|---|---|
| Your public address | Always | It is the address the tunnel arrives from |
| Connection times and volume | Always | Accounting data, not content |
| Destination IP addresses | Always | The exit has to route the packets |
| HTTPS hostname (SNI) | Normally, unless ECH is used | Sent in the clear in the TLS ClientHello |
| DNS names | Only if DNS is plaintext | DoH or DoT hides the query; plaintext is readable by the forwarder |
| Page paths and form contents | Not normally | Protected by the destination site's TLS session |
De vierde rij is wat de meeste mentale modellen missen. Een moderne browser zet de sitenaam in de ClientHello, het eerste bericht van de TLS-handshake, en dat veld is leesbaar bij de exit, zelfs wanneer elke DNS-query end-to-end versleuteld is. Tenzij Encrypted Client Hello wordt onderhandeld, reist de naam in platte tekst naast het bestemmingsadres. Versleutelde DNS verandert wie de query ziet, niet wie de naam ziet.
Hetzelfde geldt voor certificaten op oudere verbindingen: TLS 1.3 versleutelt het servercertificaat, terwijl een TLS 1.2-handshake de naam kan blootstellen aan een waarnemer die de stream opneemt. Beide zijn transportfeiten en geen providerbeleid.
Wat TLS dekt en wat niet
Wanneer een site HTTPS levert, bouwt je browser een TLS-verbinding met het eindpunt van die site, niet met de VPN-server. De provider stuurt versleutelde records door en leert het bestemmingsadres, het tijdstip en de geschatte groottes. De sitenaam reist mee in de ClientHello tenzij ECH in het spel is, en de paginabody blijft in beide gevallen versleuteld. Een onverwacht rootcertificaat verandert die grens, daarom verdienen certificaatwaarschuwingen respect.
Gewone HTTP heeft zo'n bescherming voorbij de exit niet. De tunnel beschermt het stuk naar de provider, en daarna reist het verzoek precies zoals het zonder VPN zou hebben gedaan. ECH lost dat niet op, omdat het de naam beschermt en niet de inhoud.
Bewaring is een andere vraag dan zichtbaarheid
Een operator kan verbindingsgegevens in het geheugen verwerken en niets bewaren, of een subset bewaren en die nauwkeurig omschrijven als geen browsegeschiedenis. Lees een no-logsclaim per categorie en niet per slogan: verbindingsrecords, tijdstempels, volumetotalen, bestemmingsgegevens, accountidentificatoren en supportberichten tellen allemaal mee. Een provider kan eerlijk geen browslogs bijhouden en tegelijk het accountrecord en de metadata bewaren die nodig zijn om de dienst te draaien. Zichtbaarheid vertelt je niet welke van die categorieën wordt opgeslagen.
Een audit is bewijs over de systemen en het tijdvenster dat die dekte, en openbron-clientcode beschrijft de client en niet de servers. Beide zijn nuttig, en geen van beide spreekt voor elk opslagsysteem achter de exit. Vraag naar de reikwijdte van een audit, niet naar de badge.
Vragen die providers onderscheiden
Vraag wat er bewaard wordt, hoe lang en wie het kan ophalen. Vraag wie de exit beheert, want een vermelding in een gids, een app-ontwikkelaar en de persoon die een bepaalde server draait kunnen drie verschillende partijen zijn. Vraag hoe DNS wordt behandeld en of ECH wordt ondersteund op de routes die je gebruikt, want een ClientHello in platte tekst noemt de site zelfs zonder DNS-query. Vraag wat er bij een juridisch verzoek gebeurt, en lees het antwoord als een beschrijving van vermogen en niet van intentie.
De gids van de EFF om een VPN te kiezen is een redelijke checklist voor die vragen, en het is een kader en geen vonnis over enige dienst. Een marketingpagina is geen bewaarbeleid. Niets hiervan maakt een VPN nutteloos; het verandert wie je moet vertrouwen, en waarvoor.