Wat jou VPN-verskaffer kan sien en wat nie
Die uitgang sien adresse, tye en, tensy Encrypted Client Hello gebruik word, die werfnaam in die TLS-handskud. Bewaring is 'n aparte vraag.
Jou tonnel hou die plaaslike netwerk uit jou verkeer. Dit verwyder egter nie die maatskappy aan die ander kant nie, wat elke pakkie verwerk voordat dit die oop internet bereik. Daardie posisie is tegelyk die sakemodel en die privaatheidvraag. Die nuttige vraag is dus nie of die verskaffer jou kan sien nie, maar wat hy sien, wat hy kan benoem en wat hy bewaar.
Waar die vertroue werklik verskuif
Die enkripsie loop van jou toestel na die verskaffer se bediener, en daardie buitenste been is al wat jou plaaslike netwerk ooit sien. Die verskaffer hou die ander punt van daardie been, ontsyfer dus die tonnel en stuur jou pakkies verder. Niks daarvan is 'n fout nie; dit is die definisie van die diens wat jy gekoop het. Die vertroue het van die plaaslike operateur na die operateur van die uitgang verskuif eerder as om te verdwyn.
Vanuit daardie posisie leer hy jou bronadres, wanneer jy verbind het, omtrent hoeveel jy oorgedra het en watter bestemmings jy gekontak het. Niks daarvan vereis dat hy jou boodskappe lees nie, en dit is juis die punt van die kategorieë se skeiding. Die interessante verskille tussen verskaffers gaan oor wat daarna met daardie waarnemings gebeur.
Wat die uitgang noodwendig verwerk
Sorteer die kategorieë volgens hoe betroubaar die uitgang hulle kan sien. Nie een van die rye vereis dat enkripsie gebreek word nie, en elkeen het 'n ander antwoord op die vraag of dit hoegenaamd vermybaar 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 |
Die vierde ry is wat die meeste denkmodelle mis. 'n Moderne blaaier plaas die werfnaam in die ClientHello, die eerste boodskap van die TLS-handskud, en daardie veld is by die uitgang leesbaar selfs wanneer elke DNS-navraag end-tot-end geënkripteer is. Tensy Encrypted Client Hello onderhandel word, reis die naam in die oopte langs die bestemmingsadres. Geënkripteerde DNS verander wie die navraag sien, nie wie die naam sien nie.
Dieselfde geld vir sertifikate by ouer verbindings: TLS 1.3 enkripteer die bediener-sertifikaat, terwyl 'n TLS 1.2-handskud die naam kan blootstel aan 'n waarnemer wat die stroom opneem. Beide is feite oor die vervoer, nie verskafferbeleid nie.
Wat TLS dek en wat nie
Wanneer 'n werf HTTPS lewer, bou jou blaaier 'n TLS-verbinding na daardie werf se eindpunt, nie na die VPN-bediener nie. Die verskaffer stuur geënkripteerde rekords aan en leer die bestemmingsadres, die tydsberekening en die benaderde groottes. Die werfnaam ry saam in die ClientHello tensy ECH in werking is, en die bladsy-inhoud bly in beide gevalle geënkripteer. 'n Onverwagte wortelsertifikaat verander daardie grens, en daarom verdien sertifikaatwaarskuwings respek.
Gewone HTTP het geen sulke beskerming anderkant die uitgang nie. Die tonnel beskerm die been na die verskaffer, en daarna reis die versoek presies soos dit sonder 'n VPN sou gedoen het. ECH maak dit nie reg nie, want dit beskerm die naam eerder as die inhoud.
Bewaring is 'n aparte vraag van sigbaarheid
'n Operateur kan verbindingsdata in die geheue verwerk en niks hou nie, of 'n deelversameling hou en dit akkuraat beskryf as nie-blaaiergeskiedenis nie. Lees 'n geen-log-bewering volgens kategorie eerder as volgens slagspreuk: verbindingsrekords, tydstempels, volume-totale, bestemmingsdata, rekening-identifiseerders en ondersteuningsboodskappe tel almal. 'n Verskaffer kan eerlik geen blaaierlogboeke hou nie en tog die rekeningrekord en die metadata wat nodig is om die diens te bedryf, besit. Sigbaarheid sê nie vir jou watter van daardie kategorieë gestoor word nie.
'n Oudit is bewyse oor die stelsels en die tydvenster wat dit gedek het, en oopbron-kliëntkode beskryf die kliënt eerder as die bedieners. Beide is nuttig, en nie een praat vir elke stoorstelsel agter die uitgang nie. Vra na die omvang van 'n oudit, nie na sy kenteken nie.
Vrae wat verskaffers onderskei
Vra wat bewaar word, vir hoe lank en wie dit kan ophaal. Vra wie die uitgang bedryf, want 'n gidsinskrywing, 'n app-ontwikkelaar en die persoon wat 'n bepaalde bediener bestuur, kan drie verskillende partye wees. Vra hoe DNS hanteer word en of ECH op die paaie wat jy gebruik ondersteun word, aangesien 'n gewone ClientHello die werf noem selfs sonder 'n DNS-navraag. Vra wat by 'n regsversoek gebeur, en lees die antwoord as 'n beskrywing van vermoë eerder as opset.
Die EFF se gids vir die keuse van 'n VPN is 'n redelike kontrolelys vir daardie vrae, en dit is 'n raamwerk eerder as 'n uitspraak oor enige diens. 'n Bemarkingsblad is nie 'n bewaringsbeleid nie. Niks hiervan maak 'n VPN nutteloos nie; dit verander wie jy moet vertrou, en waarvoor.