Hva en bedriftsbrannmur kan og ikke kan se inne i en VPN

Den samme bærbare maskinen når VPN-en hjemmefra og får ikke koblet til fra kontoret, så noen må lese trafikken. Blokkering og lesing er atskilte fullmakter, og bare den andre trenger et sted på veien pluss et sertifikat klienten stoler på. En mellomkasse som kaster håndtrykket ditt, har ikke lært noe om det du ville ha sendt. Å avgjøre hvilken av de to du står overfor, er hele jobben.

Blokkering og lesing er forskjellige fullmakter

En avvisning er billig og høylytt: sockelen åpnes og ingenting svarer, eller en reset kommer med en gang. Ingenting av det betyr inspeksjon, fordi ingen nyttelast krysset ledningen.

Lesing krever et endepunkt som avslutter beskyttelsen, beviser seg med et sertifikat og starter en ny forbindelse videre. Det endepunktet må ligge på veien og være betrodd av klienten. En brannmur som bare videresender pakker, har verken posisjon eller legitimasjon.

Hva innpakningen gir bort gratis

Hver tunnelpakke har en utside, og utsiden må være rutbar. Det betyr to adresser, en protokoll, en port og en lengde, i tillegg til tid og volum. Enhver ruter håndterer allerede disse feltene, og en NAT skriver om adressen og porten for å holde mappetabellen konsistent. Nyttelasten forblir forseglet, så observasjonen stopper ved at det finnes en tunnel mellom to verter.

Et vertsnavn er ikke blant dem. Nettsteder lekker gjennom andre dører, og den bredeste er DNS: hvis den bærbare fortsatt spør den lokale resolveren, vises navnene i klartekst.

Tid og volum fortjener respekt uten å overdrives. Byte per minutt kan vise at en stor overføring starter klokken 14:20; de kan ikke vise hvilken fil som flyttet seg. Det er en reell avsløring om atferd, og en annen kategori enn å lese innhold.

TLS-avlytting krever en rot du allerede stoler på

Et inspeksjonsapparat bryter ikke TLS; det avslutter det. Klienten får svar med et sertifikat fra en rot organisasjonen eier, og en andre forbindelse går til den virkelige destinasjonen. Klienten godtar dette fordi roten ligger i tillitslageret, og derfor viser en administrert bærbar maskin ingen advarsel. Kryptografi ble aldri beseiret; endepunktet ble flyttet.

Det er også derfor ordningen etterlater spor. Utstederen på kjeden som presenteres, tilhører organisasjonen og ikke en offentlig CA, og en klient kan se det uten spesialverktøy. En kjede som ender i en intern rot, er signaturen på avlytting, ikke en feil.

Hvorfor en VPN-kanal ikke er en HTTPS-økt

En VPN-datakanal gir en inspektør ingen slik fotfeste. IKEv2 og WireGuard kjører egne håndtrykk og nøkkelplaner, uten TLS å avslutte, mens OpenVPN låner TLS til kontrollkanalen i en endret form før det beskytter data på sin egen måte. En proxy bygget for HTTPS gjenkjenner ikke den økten som noe den kan parse.

Et apparat som ikke kan parse en økt, kan fortsatt kaste den. Derfor ser VPN-blokkering vanligvis ut som en tidsavbrudd og ikke en sertifikatadvarsel, og derfor endrer et unntak ingenting.

Sjekk det fra din egen maskin

Start med kjeden nettstedet presenterer. Nettstedsopplysningene i nettleseren viser utstederen, og kommandolinjen rapporterer det samme uten sammendraget:

openssl s_client -connect example.com:443 -servername example.com

Skill så et avvist håndtrykk fra filtrert indre trafikk med tellere. Logg transportporten før enhver droppregel, og les dem etter forsøket:

iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers

Ingen logglinje på den ytre sockelen betyr at håndtrykket aldri gikk ut, så veien avviser tunnelen. Et fullført håndtrykk der bare noen mål feiler, betyr at tunnelen virker og at policyen inni ikke gjør det. Ingen av resultatene krevde å lese en byte nyttelast.

Lesingen som faktisk skjer, sitter i kantene: en delt tunnel gir intern HTTPS til en bedriftsproxy, og en konsentrator eid av arbeidsgiveren eksponerer alt ved utgangen. Uansett hva du finner, ikke slå av sertifikatverifisering for å tvinge fram en forbindelse, for den kontrollen er det eneste som skiller inspeksjon fra en angriper.