Kan 'n VPN-operateur sien watter werwe jy besoek?

Vra wat die VPN kan sien, en die antwoord hang daarvan af waar jy in die pad staan. Op die sessielaag het die operateur stawingsgebeurtenisse en grepetellings. Op die pakketlaag het dit bestemmingsadresse en tydsberekening. Op die DNS-laag het dit moontlik die name self. Elke laag beantwoord 'n ander vraag, en geen enkele skakelaar skuif jou tussen hulle nie.

Karteer die laag voordat jy 'n bewering maak

Dieselfde verbinding lewer verskillende rekords op elke punt, en 'n stelling oor privaatheid is net sinvol wanneer dit die punt noem. Lees die tabel kolom vir kolom: wat op daardie laag bestaan, wat 'n operateur daar kan sien, en wat daardie selfde rekords steeds nie vir hom kan sê nie.

Om een laag as die hele prentjie te lees, is hoe beide oorbewerings en valse gerusstelling begin. 'n Verskaffer wat sê hy teken nie blaaiery aan nie, kan akkuraat wees oor URL-aantekening terwyl hy steeds sessierekords hou, en 'n pakketopname wat net adresse wys, word nie 'n blaaierygeskiedenis sonder omgekeerde naslaan en raaiwerk nie.

Wanneer jy 'n beleid beoordeel, vind die sin wat elke laag beskryf. As die beleid hulle nie skei nie, vra watter rekords bestaan eerder as om 'n algemene stelling oor enkripsie te aanvaar.

Sessie-inventaris: wat 'n standaard OpenVPN-bediener hou

Uit die boks is 'n OpenVPN bediener nie daarop gemik om verkeer vas te vang nie. Die normale uitset is 'n sessie-inventaris: die rekening wat gestaaf het, die bronadres waar dit vandaan kom, tydstempels vir die begin en einde, die tonneladres wat uitgedeel is en die grepetotale in elke rigting. Dit is 'n inventaris van sessies, nie 'n lys bestemmings nie.

Aantekenopsies kan besonderhede byvoeg. 'n Hoër breedsprakigheidsvlak skryf meer oor die handdruk, en 'n statuslêer kan gekoppelde kliënte lys, maar nie een van hulle verander die bediener in 'n deursigtige instaanbediener nie. Om URL's te lewer vereis die beëindiging van TLS of die uitvoering van 'n eksplisiete instaanbediener, en albei verander die vertrouensreëling eerder as om 'n versteekte funksie te aktiveer.

Dit is waarom die akkurate weergawe van die bewering oor geen blaaiery-aantekeninge smaller is as wat dit klink. Die bediener ken nie die bladsy nie, maar hy weet dat 'n sessie bestaan het en omtrent hoeveel data daaroor gegaan het. Of daardie sessierekord gehou word, en vir hoe lank, is 'n aparte beleidsvraag.

Binne- en buitepakkette is verskillende bewyse

'n Pakketopname is hoe jy sien wat werklik deur die tonnel gaan. Op die bediener noem jy die tonnelkoppelvlak en skryf na 'n lêer wat vanlyn ontleed kan word:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

Daardie lêer bevat ontsleutelde binneverkeer: die kliënt se tonneladres as die bron, die bestemmingsadres en -poort, pakketgroottes en tydsberekening. Dit bevat nie die HTTP-pad of die antwoordliggaam nie, tensy TLS iewers beëindig is, en dit is sensitiewe data waarvan die bewaring 'n beleidsbesluit is eerder as 'n ontfoutingsgerief.

'n Opname op die fisiese koppelvlak wys iets anders. Daar sien jy buitepakkette wat aan die VPN-eindpunt gerig is, met die versleutelde vrag binne. Onverwante adresse wat in daardie lêer voorkom, is normaal sodra 'n virtuele adapter bestaan, want die tonneltoestel dra die binnevloei terwyl die versleutelde vervoer die buitese dra.

Vra wat die opname veronderstel is om te beantwoord. 'n Toepassing se gebruik van die tonnel is sigbaar op die virtuele adapter; die tonnel se bereikbaarheid na die eindpunt is sigbaar op die fisiese een. Om enige van die lêers te gebruik asof dit die volledige prentjie is, lewer gevolgtrekkings wat die data nie kan ondersteun nie.

DNS is waar name sigbaar word

DNS bly die praktiese uitsondering. Die oplosser sien die name wat gevra word om op te los, so wie dit ook al bedryf, leer watter werwe 'n kliënt opsoek selfs wanneer die latere verbindings versleutel is. 'n Tonnelopname wys adresse; die oplosser wys name.

Kontroleer watter adres die oplosser gebruik het om 'n eksterne diens te bereik. Die antwoord is die oplosser se uitgangsadres, en om dit met die VPN-uitgang te vergelyk, sê vir jou of die navraag deur die tonnel gereis het:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

As daardie adres by die plaaslike verbinding pas eerder as by die tonneluitgang, het die opsoek die VPN omseil en die naam was op die plaaslike pad sigbaar. Herhaal die toets ná 'n kliëntopdatering, want 'n nuwe weergawe kan verander watter oplosser die profiel installeer.

Versleutelde DNS skuif die sigbaarheid eerder as om dit te verwyder. Die netwerk sien nie meer die navraag nie, maar die oplosser sien dit steeds, en die vertrouensvraag verander bloot hande. Die TLS-bedienernaam in die verbindingshanddruk is nog 'n gedeeltelike sein: dit oorleef dikwels selfs wanneer die vrag ondeursigtig is, so bestemmingsadresse is nie die enigste metadata wat 'n deurvoerserver kan waarneem nie.

Drie soorte rekords en wie hulle kan lees

Sessieboekhouding, rekords per naam en lekbewyse is drie verskillende produkte met drie verskillende verpligtinge. Sessielogboeke is goedkoop en lae sensitiwiteit, en hulle beantwoord wie gekoppel het en wanneer. Rekords per naam vereis 'n aantekenende oplosser of 'n eksplisiete instaanbediener, en hulle skep 'n openbaringsverpligting teenoor die mense wat geraak word. Lekbewyse is 'n toets aan die kliëntekant wat vergelyk wat die oplosser onthul met die tonneluitgang.

Teken aan watter van hierdie drie jy dryf, wie dit kan lees en hoe lank dit bly. Stellings dat 'n diens geen logboeke hou nie, beskryf een laag, en hulle bly net waar binne daardie omvang. Dieselfde verskaffer kan akkuraat wees oor sessies terwyl hy verkeerd is oor DNS.

Hou die toets herhaalbaar: dieselfde navraag aan die oplosser, dieselfde opname-koppelvlak en dieselfde vergelyking. 'n Privaatheidbewering wat nie op 'n genoemde laag getoets kan word nie, is 'n slagspreuk, nie 'n operasionele feit nie.