Wat het lokale netwerk nog steeds via je VPN ziet

Drie waarnemers vallen samen in één vraag telkens wanneer iemand vraagt of een VPN zijn verkeer verbergt: het netwerk waarop hij is aangesloten, de machine in zijn handen en de operator van de tunnel. Elk leert iets anders, en de tunnel verandert elk van die beelden op een andere manier. Het helpt om de andere kant op te werken en te beginnen bij de bewering die wordt gedaan, want de bewering is wat de toets moet doorstaan. Bepaal welke bewering je nodig hebt en vergelijk daar vervolgens de hulpmiddelen mee.

Bewering één: niemand kan het verkeer lezen

Begin met de smalste bewering: de lading blijft onleesbaar. Een passieve waarnemer op het pad kan niet in een TLS-sessie kijken, dus de tunnel voegt weinig toe aan een site die al HTTPS gebruikt en niets tegen de twee eindpunten. De partij die deze bewering breekt is wie het apparaat beheert, want een inspectieproxy beëindigt de verbinding en ondertekent die opnieuw met een wortel die de machine al vertrouwt. Daarom verschijnt het slotje nog steeds terwijl de certificaatketen de naam draagt van de organisatie die de wortel installeerde.

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

Op macOS drukt die pijplijn één onderwerpregel af voor elk certificaat in de sleutelhanger van de machine, zonder een venster te openen, en op Windows somt certutil -store Root dezelfde opslag op die certlm.msc grafisch toont. Een wortel van een school, een werkgever of een netwerkbeveiligingsproduct is de vermelding waarnaar je moet zoeken. Er één vinden bewijst alleen dat onderschepping mogelijk is, niet dat die plaatsvindt.

Wat je eraan kunt doen is een kwestie van beleid en niet van techniek. Een profiel of een inspectiewortel verwijderen van hardware die niet van jou is, schendt meestal de overeenkomst voor aanvaardbaar gebruik, en het beheersysteem merkt dat doorgaans op en past het opnieuw toe, dus de eis dat de eigenaar van het apparaat je verkeer niet leest vereist een ander apparaat en niet een andere instelling.

Bewering twee: niemand ziet waar je heen gaat

De bestemming is de moeilijkere bewering, want er gebeuren twee onthullingen voordat een pagina laadt. Een opzoeking gaat naar de resolver die het systeem is geconfigureerd te gebruiken, en het antwoord is zichtbaar voor het netwerk dat het draagt. Daarna draagt de TLS-handdruk de gevraagde servernaam in de open lucht, tenzij Encrypted Client Hello aan beide uiteinden wordt ondersteund. Geen van beide onthullingen omvat ontsleuteling, dus de tunnel heeft op geen van beide effect.

resolvectl status | grep -A2 "Link"
nslookup example.com

Welke resolver werkelijk wordt gebruikt bepaalt de blootstelling, en dat kan worden gemeten in plaats van bediscussieerd. Op Linux drukt resolvectl status de DNS-servers per koppeling af, en de uitvoer vertelt je of de resolver van de site of de opgedrongen resolver antwoordt. Windows beantwoordt dezelfde vraag met nslookup example.com, waarvan het eerste blok uitvoer de DNS-server is die antwoordde.

Wanneer de laptop de resolver van de site bevraagt voordat de tunnel opkomt, of het profiel aankomt zonder vervangende server zodat de oude in gebruik blijft, verzamelt de beheerder nog steeds hostnamen zonder iets te ontsleutelen. Versleutelde DNS in de browser omzeilt de opgedrongen resolver of wordt volledig geblokkeerd en faalt gesloten. De uitgangsoperator ziet dezelfde namen van zijn kant. De resolver wijzigen verplaatst die onthulling dus niet weg van de tunnelprovider.

Bewering drie: niemand weet dat je verbonden was

De derde bewering is degene die een tunnel niet kan ondersteunen, want de pakketten steken nog steeds het lokale netwerk over. Dat netwerk leert het eindpuntadres, het geschatte volume, de timing en het bestaan van één langdurige versleutelde sessie, wat genoeg is om te blokkeren, te knijpen of simpelweg op te merken. Een firewall die een pakket niet kan lezen kan nog steeds weigeren het door te laten. Bespied worden is niet hetzelfde als door niemand bespied worden: je hebt de waarnemer verplaatst, niet verwijderd.

Split-tunneling, en elke toepassing die de opgedrongen route negeert, produceren stromen buiten de tunnel die er precies uitzien als voorheen. Dat zijn de stromen die een oplettende waarnemer het eerst opmerkt, en de routetabel van de client laat zien welke bestemmingen zijn uitgesloten.

De operator aan de andere kant houdt het spiegelbeeld van dat beeld: uitgangsadres, timing, volume en meestal de namen van de sites. Je provider wordt de partij met het uitzichtpunt, wat een andere ruil is dan onzichtbaarheid. Een provider kiezen die je vertrouwt is een echte beslissing; het resultaat onbespied noemen is dat niet.

Bepaal welke bewering je nodig hebt

Schrijf de eis in één regel op voordat je een client aanraakt: de inhoud verbergen, de bestemmingen verbergen of verbergen of je überhaupt verbonden was. Inhoud wordt al door HTTPS samen met de tunnel afgehandeld, terwijl bestemmingen een resolver en een pad vereisen die de apparatuur van de site volledig omzeilen.

De derde eis is de ongemakkelijke, want ergens is nog steeds zichtbaar iets verbonden, versleuteld of niet. Geen enkele clientinstelling verandert dat. Als de eis en het beleid uit elkaar lopen, hoort die kloof in een gesprek met wie het beleid bezit, niet in een clientoptie. De persoon die het kan beantwoorden is degene die het beleid schreef.