Cosa vede l’operatore dentro un tunnel VPN cellulare

Una connessione cellulare che trasporta una VPN ha due protezioni indipendenti, e quasi ogni affermazione confusa sulla privacy mobile nasce dal fonderle. La rete radio protegge il proprio accesso e la propria segnalazione. Il client VPN autentica un gateway e protegge il traffico verso quel gateway. Nessuna delle due è uno strato dell’altra, e l’operatore non diventa il peer della VPN solo perché termina la protezione dell’accesso cellulare.

Passo 1: disegnare entrambe le relazioni

Da un lato ci sono il telefono e la rete mobile: registrazione, portanti radio e la protezione specificata dallo standard di accesso. Dall’altro ci sono il client VPN e uno specifico gateway remoto, con la propria autenticazione e le proprie chiavi.

Estremi diversi, materiale di chiave diverso, modalità di errore diverse. Disegnateli come due linee invece di una.

Passo 2: segnare dove finisce ciascuna

In un tunnel IPsec in modalità tunnel, il client incapsula il pacchetto interno in un nuovo pacchetto IP esterno, e la rete inoltra quell’intestazione esterna. La specifica ESP descrive direttamente quell’incapsulamento: il carico utile è protetto, l’indirizzamento esterno è ciò che vede il percorso.

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

Nulla lungo il percorso decifra il carico utile a un salto instradato. L’elaborazione avviene all’estremo configurato, ed è per questo che i due confini di protezione non si fondono in uno.

Passo 3: elencare cosa può ancora fare l’operatore

Un operatore di accesso vede destinazioni esterne, tempi e volume. Può anche influire sulla consegna tramite instradamento, filtraggio, perdita o connessione interrotta. Un tunnel lento o fallito è quindi del tutto possibile senza alcuna decifratura del suo contenuto. I picchi di latenza e le riconnessioni forzate rientrano nella stessa categoria.

Osservazione e disturbo sono capacità reali. Non sono la stessa capacità che leggere il carico utile interno.

Passo 4: mantenere onesti i presupposti

La conclusione vale per un tunnel supportato e configurato correttamente tra estremi di cui vi fidate. Non sopravvive a un telefono compromesso, a credenziali rubate, a una suite di cifratura obsoleta né a un gateway esso stesso malevolo. Non rende nemmeno innocuo un avviso di certificato inatteso; trattatelo come un incidente a sé invece che come qualcosa da ignorare con un clic. Ognuno di questi elementi rompe un presupposto, non la crittografia.

Rimuovere la convalida del peer o del certificato per far sparire un avviso cambia la relazione di protezione su cui contavate.

Passo 5: seguire i dati oltre il gateway

La protezione VPN termina al suo estremo configurato. Ciò che il traffico fa dopo è protetto solo da ciò che gira su quel livello, ed è per questo che una sessione HTTPS correttamente validata conta ancora dopo il tunnel. Il testo in chiaro inviato dal gateway ha bisogno di una propria valutazione.

Questa è la parte che le persone dimenticano quando descrivono un tunnel come se coprisse l’intero percorso.

Passo 6: delimitare i flussi realmente protetti

Controllate la politica del client per applicazioni escluse, tunnel diviso e famiglie di indirizzi. Un’applicazione esclusa, una famiglia di indirizzi non gestita o una sessione disconnessa possono usare un percorso del tutto diverso, e un’icona di stato non vi dirà quale flusso è andato dove.

Scrivete il resoconto come quattro fatti: la rete di accesso, l’estremo VPN autenticato, l’estremo dell’applicazione e il traffico realmente coperto. Quel resoconto resta vero anche quando le icone mentono.