Cosa vede ancora la rete locale attraverso la tua VPN

Tre osservatori si fondono in un’unica domanda ogni volta che qualcuno chiede se una VPN nasconde il suo traffico: la rete a cui è collegato, la macchina che ha tra le mani e l’operatore del tunnel. Ognuno apprende qualcosa di diverso, e il tunnel cambia ciascuna di queste viste in modo diverso. Conviene lavorare nella direzione opposta e partire dall’affermazione che viene fatta, perché è l’affermazione che deve reggere l’esame. Decidi di quale affermazione hai bisogno, poi confronta gli strumenti con essa.

Prima affermazione: nessuno può leggere il traffico

Inizia dall’affermazione più stretta: il contenuto resta illeggibile. Un osservatore passivo sul percorso non può vedere dentro una sessione TLS, quindi il tunnel aggiunge poco a un sito che già usa HTTPS e non aggiunge nulla contro i due estremi. A rompere questa affermazione è chi controlla il dispositivo, perché un proxy di ispezione termina la connessione e la firma di nuovo con una radice di cui la macchina si fida già. Per questo il lucchetto compare ancora mentre la catena dei certificati porta il nome dell’organizzazione che ha installato la radice.

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

Su macOS quella pipeline stampa una riga di soggetto per ogni certificato nel portachiavi della macchina, senza aprire finestre, e su Windows certutil -store Root elenca lo stesso archivio che certlm.msc mostra graficamente. Una radice appartenente a una scuola, a un datore di lavoro o a un prodotto di sicurezza di rete è la voce da cercare. Trovarne una dimostra solo che l’intercettazione è possibile, non che stia avvenendo.

Ciò che puoi fare al riguardo è una questione di politica e non di tecnica. Rimuovere un profilo o una radice di ispezione da un hardware che non è tuo di norma viola l’accordo di uso accettabile, e il sistema di gestione tende a notarlo e a riapplicarlo, quindi la richiesta che il proprietario del dispositivo non legga il tuo traffico richiede un altro dispositivo, non un’altra impostazione.

Seconda affermazione: nessuno vede dove vai

La destinazione è l’affermazione più difficile, perché due divulgazioni avvengono prima che una pagina si carichi. La richiesta va al resolver con cui il sistema è configurato, e la risposta è visibile alla rete che la trasporta. Poi la stretta di mano TLS trasporta in chiaro il nome del server richiesto, a meno che Encrypted Client Hello sia supportato a entrambi gli estremi. Nessuna delle due divulgazioni comporta decifratura, quindi il tunnel non ha effetto su nessuna.

resolvectl status | grep -A2 "Link"
nslookup example.com

Quale resolver viene davvero usato decide l’esposizione, e si può misurare invece di discuterne. Su Linux resolvectl status stampa i server DNS per collegamento, e il suo output ti dice se risponde il resolver del sito o quello imposto. Windows risponde alla stessa domanda con nslookup example.com, il cui primo blocco di output è il server DNS che ha risposto.

Quando il portatile interroga il resolver del sito prima che il tunnel salga, o il profilo arriva senza un server sostitutivo e il vecchio resta in uso, l’amministratore raccoglie comunque nomi host senza decifrare nulla. Il DNS cifrato del browser o aggira il resolver imposto oppure viene bloccato del tutto e fallisce chiuso. L’operatore di uscita vede gli stessi nomi dal suo lato. Cambiare resolver non allontana quindi quella divulgazione dal fornitore del tunnel.

Terza affermazione: nessuno sa che ti sei connesso

La terza affermazione è quella che un tunnel non può sostenere, perché i pacchetti attraversano ancora la rete locale. Quella rete apprende l’indirizzo dell’estremo, il volume approssimativo, il momento e l’esistenza di una sessione cifrata di lunga durata, il che basta per bloccare, limitare o semplicemente notare. Un firewall che non può leggere un pacchetto può comunque rifiutarsi di lasciarlo passare. Essere osservati non è come non essere osservati da nessuno: hai spostato l’osservatore, non l’hai cancellato.

Il tunnel diviso, e qualsiasi applicazione che ignora la rotta imposta, producono flussi fuori dal tunnel che appaiono esattamente come prima. Sono quei flussi che un osservatore attento nota per primi, e la tabella delle rotte del client mostra quali destinazioni sono escluse.

L’operatore all’altro capo tiene l’immagine speculare di quella vista: indirizzo di uscita, momento, volume e di solito i nomi dei siti. Il tuo fornitore diventa la parte con il punto di osservazione, che è un patto diverso dall’invisibilità. Scegliere un fornitore di cui ti fidi è una decisione vera; definire il risultato non osservato non lo è.

Decidi di quale affermazione hai bisogno

Scrivi il requisito in una riga prima di toccare un client: nascondere il contenuto, nascondere le destinazioni o nascondere se ti sei connesso. Il contenuto è già gestito da HTTPS insieme al tunnel, mentre le destinazioni richiedono un resolver e un percorso che aggirano del tutto l’apparecchiatura del sito.

Il terzo requisito è quello scomodo, perché qualcosa resta visibilmente connesso da qualche parte, cifrato o no. Nessuna impostazione del client cambia questo. Se requisito e politica si separano, quel divario appartiene a una conversazione con chi possiede la politica, non a un’opzione del client. La persona che può rispondere è quella che ha scritto la politica.