En mobilanslutning som bär VPN har två oberoende skydd, och nästan varje förvirrat påstående om mobil integritet kommer av att slå samman dem. Radionätet skyddar sin egen åtkomst och signalering. VPN-klienten autentiserar en gateway och skyddar trafiken till den gatewayen. Ingen av dem är ett lager av den andra, och operatören blir inte VPN-motpart bara för att den avslutar skyddet för mobil åtkomst.

Steg 1: rita båda sambanden

På ena sidan finns telefonen och mobilnätet: registrering, radiobärare och vilket skydd åtkomststandarden än föreskriver. På andra sidan finns VPN-klienten och en bestämd fjärrgateway, med egen autentisering och egna nycklar.

Olika ändpunkter, olika nyckelmaterial, olika fellägen. Rita dem som två linjer i stället för en.

Steg 2: markera var var och en slutar

För en IPsec-tunnel i tunnelläge packar klienten in det inre paketet i ett nytt yttre IP-paket och nätverket vidarebefordrar det yttre huvudet. ESP-specifikationen beskriver den inkapslingen direkt: nyttolasten skyddas, den yttre adresseringen är det som vägen ser.

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

Ingenting längs vägen dekrypterar nyttolasten vid ett routat hopp. Behandlingen sker vid den konfigurerade ändpunkten, och därför smälter inte de två skyddsgränserna samman till en.

Steg 3: lista vad operatören fortfarande kan göra

En åtkomstoperatör kan se yttre destinationer, timing och volym. Den kan också påverka leveransen genom routning, filtrering, förlust eller en bruten anslutning. En långsam eller misslyckad tunnel är därför fullt möjlig utan någon dekryptering av innehållet. Latensspikar och påtvingade återanslutningar hör till samma kategori.

Observation och störning är verkliga förmågor. De är inte samma förmåga som att läsa den inre nyttolasten.

Steg 4: håll antagandena ärliga

Slutsatsen gäller för en tunnel som stöds och är korrekt konfigurerad mellan ändpunkter du litar på. Den överlever inte en komprometterad telefon, stulna uppgifter, en föråldrad chiffersvit eller en gateway som själv är illvillig. Den gör inte heller en oväntad certifikatvarning ofarlig; behandla den som en egen incident och inte som något att klicka bort. Var och en av dessa bryter ett antagande och inte kryptografin.

Att ta bort motparts- eller certifikatvalidering för att få en varning att försvinna ändrar det skyddsförhållande du förlitade dig på.

Steg 5: följ data förbi gatewayen

VPN-skyddet slutar vid sin konfigurerade ändpunkt. Vad trafiken gör därefter skyddas bara av det som körs på det lagret, och därför är en korrekt validerad HTTPS-session fortfarande viktig efter tunneln. Klartext som skickas vidare från gatewayen behöver sin egen bedömning.

Det här är delen folk glömmer när de beskriver en tunnel som att den täcker hela vägen.

Steg 6: avgränsa de flöden som faktiskt är skyddade

Kontrollera klientprincipen för undantagna program, delad tunnling och adressfamiljer. En undantagen app, en adressfamilj som inte hanteras eller en frånkopplad session kan använda en helt annan väg, och en statusikon berättar inte vilket flöde som gick vart.

Skriv protokollet som fyra fakta: åtkomstnätet, den autentiserade VPN-ändpunkten, programmets ändpunkt och trafiken som faktiskt täcks. Protokollet förblir sant även när ikonerna ljuger.

Relaterade artiklar