VPN e crittografia end-to-end: chi può leggere cosa
Una VPN protegge la rotta, l’app di messaggistica protegge il contenuto. Confrontate l’uscita, il relay e il destinatario prima di supporre che uno dei due nasconda il messaggio.
Seguite un messaggio da un telefono a un amico e vedrete che attraversa almeno due tipi diversi di protezione. La VPN copre la rotta tra il client e il suo gateway, l’app di messaggistica copre il contenuto tra i dispositivi dei partecipanti. Nessuna delle due sostituisce l’altra, e la domanda utile non è quale sia più forte, ma chi può leggere cosa a ogni passaggio. Percorrete il percorso una volta e i ruoli diventano evidenti.
Due protezioni, due estremi
Sul dispositivo mittente l’app cifra il messaggio con chiavi che appartengono alla conversazione, poi consegna il testo cifrato al sistema operativo. La VPN, se ce n’è una attiva, avvolge tutto il traffico che corrisponde alla sua politica e lo porta a un gateway. Da lì il pacchetto viaggia sull’internet ordinaria fino ai server dell’app, che lo inoltrano verso il destinatario. Solo il dispositivo del destinatario possiede la chiave che riconverte il testo cifrato in testo.
Un relay su quel percorso può vedere un messaggio arrivare e ripartire senza leggerlo, ed è proprio la proprietà che la crittografia end-to-end dovrebbe fornire.
Cosa può e cosa non può leggere l’uscita della VPN
Un gateway VPN decifra il tunnel, non il contenuto dell’app. Può osservare quale server il client ha contattato, quando e quanti dati si sono mossi, poi inoltrare i pacchetti. È un insieme di fatti significativo e molto più piccolo del testo del messaggio. Su un normale sito HTTPS la connessione TLS termina al sito, quindi il sito può leggere ciò che è stato inviato anche se la VPN non può. La distinzione riguarda dove termina ogni livello, non quale prodotto sia più privato.
Cambiate la destinazione con un servizio cifrato end-to-end e il relay nel mezzo perde il contenuto, mentre la VPN vede ancora lo schema di connessione.
Le chiavi appartengono alla conversazione, non alla rotta
Le chiavi dei contenuti vengono negoziate tra i partecipanti e restano sui loro dispositivi; una VPN non partecipa a quello scambio. Le app espongono spesso un numero di sicurezza o un’impronta della chiave perché entrambe le parti confrontino ciò che hanno. Quel confronto rileva una chiave sostituita nel mezzo, cosa preziosa e più stretta del dimostrare chi sta digitando. Confermare l’identità di una persona richiede ancora un canale fuori dall’app, come una chiamata o un controllo di persona. Il controllo del certificato del server di una VPN verifica un endpoint del tutto diverso.
Non leggete un numero di sicurezza verificato come prova della titolarità dell’account. È una prova sulle chiavi, non sulle persone.
Copie, metadati e l’altro dispositivo
Il contenuto leggibile esiste agli estremi, quindi sono gli estremi a decidere cosa succede dopo. Fate una breve mappa dei luoghi in cui può atterrare una copia prima di decidere quanto aiuta il tunnel.
| Point | Can it read the message | Why |
|---|---|---|
| Sending device | Yes | Content exists before encryption |
| VPN gateway | No | Terminates the tunnel, not the app keys |
| App relay | No, by design | Only ciphertext passes through |
| Recipient device | Yes | Holds the conversation keys |
| Cloud backup | Depends on the product | May store plaintext or an encrypted archive |
Leggete le regole dell’app per backup, dispositivi collegati, notifiche ed esportazioni, perché ciascuna è una copia separata con la propria gestione. La rete espone ancora tempi e volumi anche quando il contenuto è protetto, e una VPN cambia quale fornitore vede la connessione locale, non se quei metadati esistano. Un file esportato da una conversazione protetta conserva la protezione che il suo formato offre, e il tunnel non fa più nulla per lui in seguito.
Scegliete la protezione per ciò che copre: l’app per il contenuto e le chiavi, la VPN per la rotta e la vista della rete locale. Poi elencate le copie e i dispositivi che restano fuori da entrambe.