Hvad netoperatøren ser inde i en mobil VPN-tunnel

En mobilforbindelse, der bærer en VPN, har to uafhængige beskyttelser, og stort set ethvert forvirret udsagn om mobil privatliv opstår ved at slå dem sammen. Radionettet beskytter sin egen adgang og signalering. VPN-klienten autentificerer en gateway og beskytter trafikken til den gateway. Ingen af dem er et lag af den anden, og netoperatøren bliver ikke VPN-peer, blot fordi den afslutter mobiladgangsbeskyttelsen.

Trin 1: tegn begge forhold

På den ene side er telefonen og mobilnettet: registrering, radiobærere og den beskyttelse, adgangsstandarden foreskriver. På den anden side er VPN-klienten og en bestemt fjern-gateway med sin egen autentificering og sine egne nøgler.

Forskellige endepunkter, forskelligt nøglemateriale, forskellige fejltilstande. Tegn dem som to linjer i stedet for én.

Trin 2: markér, hvor hver af dem slutter

I en IPsec-tunnel i tunneltilstand pakker klienten den indre pakke ind i en ny ydre IP-pakke, og nettet videresender det ydre hoved. ESP-specifikationen beskriver den indkapsling direkte: nyttelasten er beskyttet, og den ydre adressering er det, stien ser.

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

Intet langs stien dekrypterer nyttelasten ved et rutet hop. Behandlingen sker ved det konfigurerede endepunkt, og derfor smelter de to beskyttelsesgrænser ikke sammen til én.

Trin 3: list, hvad netoperatøren stadig kan

En adgangsoperatør kan se ydre destinationer, timing og volumen. Den kan også påvirke leveringen gennem routing, filtrering, tab eller en afbrudt forbindelse. En langsom eller mislykket tunnel er derfor fuldt mulig uden nogen dekryptering af indholdet. Latensspidser og tvungne genopkoblinger hører i samme kategori.

Observation og forstyrrelse er reelle evner. De er ikke den samme evne som at læse den indre nyttelast.

Trin 4: hold antagelserne ærlige

Konklusionen gælder for en understøttet, korrekt konfigureret tunnel mellem endepunkter, du har tillid til. Den overlever ikke en kompromitteret telefon, stjålne legitimationsoplysninger, en forældet cipher suite eller en gateway, der selv er ondsindet. Den gør heller ikke en uventet certifikatadvarsel harmløs; behandl den som sin egen hændelse i stedet for noget, man klikker væk. Hver af disse bryder en antagelse snarere end kryptografien.

At fjerne peer- eller certifikatvalidering for at få en advarsel til at forsvinde ændrer det beskyttelsesforhold, du byggede på.

Trin 5: følg dataene forbi gatewayen

VPN-beskyttelse slutter ved sit konfigurerede endepunkt. Hvad trafikken derefter gør, er kun beskyttet af det, der kører på det lag, og derfor er en korrekt valideret HTTPS-session stadig vigtig efter tunnelen. Klartekst, der sendes videre fra gatewayen, kræver sin egen vurdering.

Det er den del, folk glemmer, når de beskriver en tunnel som dækkende hele stien.

Trin 6: afgræns de strømme, der faktisk er beskyttet

Kontroller klientpolitikken for udelukkede programmer, delt tunnelling og adressefamilier. Et udelukket program, en uhåndteret adressefamilie eller en afbrudt session kan bruge en helt anden sti, og et statusikon fortæller dig ikke, hvilken strøm der gik hvorhen.

Skriv registreringen som fire fakta: adgangsnettet, det autentificerede VPN-endepunkt, applikationsendepunktet og den trafik, der faktisk er dækket. Den registrering forbliver sand, selv når ikonerne lyver.