Tor o VPN: decidete in base a chi ogni percorso vi costringe a fidarvi
Una VPN accumula la vostra fiducia su un solo operatore; Tor la distribuisce tra i relay. Decidete in base alla copertura, a chi può collegarvi a un sito e a ciò che potete verificare.
Scegliere tra Tor e una VPN si riduce a quale parte potete tollerare che veda entrambe le estremità di una connessione. Una VPN concentra quella vista su un operatore che avete scelto. Tor la distribuisce tra i relay, così nessun singolo relay deve apprendere chi siete e cosa avete scaricato.
Nessuna delle due disposizioni vi rende anonimi da sola. Scegliete quella di cui potete dire ad alta voce la fiducia residua, poi correggete le parti che lascia scoperte.
Contate chi può collegarvi a una destinazione
Con una VPN, ogni flusso coperto raggiunge l’uscita dell’operatore prima di raggiungere la destinazione. Quell’operatore vede necessariamente il vostro indirizzo di origine e, per tutto ciò che non è cifrato attraverso di esso, la destinazione che avete richiesto. TLS tiene il contenuto della pagina fuori da quella vista ma di solito lascia visibile il nome host mentre la connessione viene impostata. Una parte può quindi collegarvi a un sito, e quel collegamento è precisamente la fiducia che concedete.
Tor separa quelle metà tra tre relay: una guardia che conosce il vostro indirizzo ma non la destinazione, un relay intermedio che non conosce nessuna delle due estremità e un’uscita che conosce la destinazione ma non voi. Il progetto presuppone che nessun relay combini entrambi i fatti, il che è un presupposto più debole e più utile che fidarsi di una sola azienda. Non presuppone che i relay siano onesti e non sconfigge un osservatore che guarda entrambe le estremità del percorso.
Entrambi i progetti condividono un punto debole, e si trova nella destinazione. Se accedete, il servizio collega quella sessione al vostro account qualunque percorso abbiano preso i pacchetti. Il routing cambia da dove sembra arrivare una richiesta, non ciò che la pagina vi chiede di fornire.
La copertura conta più del diagramma di routing
Una VPN instrada a livello di rete, quindi ogni applicazione del dispositivo eredita il tunnel a meno che non la escludiate deliberatamente. Questa ampiezza è il motivo per cui funziona contemporaneamente per un client di posta, un gestore di pacchetti e un browser.
Il browser Tor è un pacchetto, e le sue protezioni vivono soprattutto dentro il browser: un’impronta uniforme, isolamento tra siti e script limitati da un livello di sicurezza anziché dalle estensioni che avete installato. Puntare Chrome su una porta SOCKS compra il routing senza nulla di tutto ciò, che è una fonte comune di fiducia mal riposta.
Il resto del desktop resta intatto. Un client di sincronizzazione, un aggiornatore o un documento scaricato aperto in un altro programma si collega come quel programma è configurato, e nulla di ciò passa attraverso l’ascoltatore SOCKS a meno che non lo impostiate lì. Elencate le applicazioni che parlano alla rete, poi chiedete quali di esse lo strumento scelto copra davvero. La copertura è una proprietà della vostra configurazione, non della vostra intenzione.
Scegliete con tre condizioni
La decisione di solito si risolve con tre domande: il traffico viene da un’applicazione o dall’intero dispositivo, la destinazione deve essere incapace di identificare il vostro indirizzo, e dovete raggiungere una rete privata? Rispondete in quest’ordine e lo strumento di solito si sceglie da solo.
| Requirement | Better fit | Reason |
|---|---|---|
| Every app covered, including non-browser traffic | A device VPN | Routing happens below the application, with a kill switch to stop leaks |
| Destination must not learn your address | Tor | The site sees a shared exit address rather than one tied to your account |
| Browser fingerprint that blends in | Tor Browser | The uniformity ships with the browser, a proxy alone adds none of it |
| Access to a private subnet or office resource | A VPN | Tor exits reach the public internet, not your internal routes |
Dove due requisiti entrano in conflitto, pesate quale potete imporre. Un tunnel di dispositivo con un elenco di esclusioni che perde è peggiore di un percorso solo browser che potete dimostrare.
La verifica è economica per entrambi i percorsi, e dovrebbe avvenire prima che vi affidiate a uno dei due:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Un risultato falso del primo comando significa che la richiesta è uscita dal circuito, ed è il guasto che vale la pena cogliere presto. Confrontate il secondo con l’indirizzo assegnato dal vostro provider, non con quello che ricordate della settimana scorsa.
Ciò che nessuna delle due opzioni ripara
La cifratura delle applicazioni fa ancora un lavoro che nessun percorso svolge. L’HTTP semplice che attraversa una rete per la privacy resta leggibile all’uscita, e HTTPS resta l’unica cosa che protegge il carico da un capo all’altro. TLS inoltre non dice nulla sul nome host che avete digitato, ed è per questo che la destinazione resta visibile a chi termina il percorso.
Gli account vi identificano, e nessuna scelta di routing cambia questo: il servizio sa chi ha effettuato l’accesso indipendentemente dall’indirizzo nell’intestazione. La correlazione da parte di un osservatore che vede abbastanza rete, la compromissione del vostro dispositivo e tutto ciò che digitate in un modulo sopravvivono a entrambi i progetti. Trattate entrambi gli strumenti come modi per spostare la fiducia, non per eliminarla.
Partite dalla configurazione predefinita che ogni progetto documenta, confermate il percorso con i due comandi sopra, e solo dopo considerate l’idea di impilare una VPN sotto Tor. Annidarli è una configurazione con i propri modi di guasto, non un aggiornamento gratuito.