Wat de provider ziet binnen een mobiele VPN-tunnel

Een mobiele verbinding met een VPN heeft twee onafhankelijke beschermingen, en bijna elke verwarde bewering over mobiele privacy komt voort uit het samenvoegen daarvan. Het radionetwerk beschermt zijn eigen toegang en signalering. De VPN-client authenticeert een gateway en beschermt het verkeer naar die gateway. Geen van beide is een laag van de andere, en de provider wordt niet de VPN-tegenpartij alleen omdat hij de bescherming van mobiele toegang beëindigt.

Stap 1: teken beide relaties

Aan de ene kant staan de telefoon en het mobiele netwerk: registratie, radiobearers en welke bescherming de toegangsstandaard ook voorschrijft. Aan de andere kant staan de VPN-client en een specifieke externe gateway, met eigen authenticatie en eigen sleutels.

Verschillende eindpunten, ander sleutelmateriaal, andere faalmodi. Teken ze als twee lijnen in plaats van één.

Stap 2: markeer waar elk van beide eindigt

Bij een IPsec-tunnel in tunnelmodus verpakt de client het binnenste pakket in een nieuw buitenste IP-pakket en het netwerk stuurt die buitenste kop door. De ESP-specificatie beschrijft die inkapseling rechtstreeks: de payload is beschermd, de buitenste adressering is wat het pad ziet.

phone -- cellular access protection -- radio network
phone -- ESP outer packet ------> office gateway -- inner traffic

Niets langs het pad ontsleutelt de payload bij een gerouteerde hop. De verwerking gebeurt op het geconfigureerde eindpunt, en daarom vallen de twee beschermingsgrenzen niet samen tot één.

Stap 3: som op wat de provider nog steeds kan doen

Een toegangsprovider kan buitenste bestemmingen, timing en volume zien. Hij kan de aflevering ook beïnvloeden via routering, filtering, verlies of een verbroken verbinding. Een trage of mislukte tunnel is dus volledig mogelijk zonder enige ontsleuteling van de inhoud. Latentiepieken en geforceerde herverbindingen vallen in dezelfde categorie.

Waarneming en verstoring zijn echte vermogens. Ze zijn niet hetzelfde vermogen als het lezen van de binnenste payload.

Stap 4: houd de aannames eerlijk

De conclusie geldt voor een ondersteunde, correct geconfigureerde tunnel tussen eindpunten die u vertrouwt. Ze overleeft geen gecompromitteerde telefoon, gestolen inloggegevens, een verouderde cijfersuite of een gateway die zelf kwaadwillig is. Ze maakt een onverwachte certificaatwaarschuwing ook niet ongevaarlijk; behandel die als een eigen incident en niet als iets om weg te klikken. Elk daarvan breekt een aanname en niet de cryptografie.

Het verwijderen van peer- of certificaatvalidatie om een waarschuwing te laten verdwijnen verandert de beschermingsrelatie waarop u vertrouwde.

Stap 5: volg de gegevens voorbij de gateway

VPN-bescherming eindigt op het geconfigureerde eindpunt. Wat het verkeer daarna doet, is alleen beschermd door wat op die laag draait, en daarom blijft een goed gevalideerde HTTPS-sessie ook na de tunnel belangrijk. Klare tekst die de gateway verder stuurt, vereist een eigen beoordeling.

Dit is het deel dat mensen vergeten wanneer ze een tunnel beschrijven als die het hele pad dekt.

Stap 6: bepaal welke stromen werkelijk beschermd zijn

Controleer het clientbeleid op uitgesloten toepassingen, split tunnelling en adresfamilies. Een uitgesloten app, een niet-afgehandelde adresfamilie of een verbroken sessie kan een heel ander pad gebruiken, en een statuspictogram vertelt u niet welke stroom waar heen ging.

Schrijf het verslag als vier feiten: het toegangsnetwerk, het geauthenticeerde VPN-eindpunt, het toepassingseindpunt en het verkeer dat werkelijk gedekt is. Dat verslag blijft waar, zelfs wanneer de pictogrammen liegen.