Tor o VPN: decidiu per qui us obliga a confiar cada camí
Una VPN acumula la vostra confiança en un sol operador; Tor la reparteix entre relés. Decidiu per la cobertura, per qui us pot vincular a un lloc i per què podeu verificar.
Triar entre Tor i una VPN es redueix a quina part podeu tolerar que vegi els dos extrems d’una connexió. Una VPN concentra aquesta visió en un operador que heu triat. Tor la reparteix entre relés, de manera que cap relé no ha de saber qui sou ni què heu baixat.
Cap de les dues disposicions no us fa anònims per si sola. Trieu la que us permeti dir en veu alta la confiança que hi queda, i després arregleu les parts que deixa descobertes.
Compteu qui us pot vincular a una destinació
Amb una VPN, cada flux cobert arriba a la sortida de l’operador abans d’arribar a la destinació. Aquest operador veu necessàriament la vostra adreça d’origen i, per a tot el que no estigui xifrat a través seu, la destinació que heu demanat. TLS manté el contingut de la pàgina fora d’aquesta visió, però normalment deixa el nom d’amfitrió visible mentre s’estableix la connexió. Per tant, una part us pot vincular a un lloc, i aquest vincle és precisament la confiança que atorgueu.
Tor separa aquestes meitats entre tres relés: un guardià que coneix la vostra adreça però no la destinació, un relé intermedi que no coneix cap dels dos extrems, i una sortida que coneix la destinació però no vosaltres. El disseny suposa que cap relé no combina els dos fets, cosa que és una suposició més feble i més útil que confiar en una sola empresa. No suposa que els relés siguin honestos i no venç un observador que miri els dos extrems del camí.
Els dos dissenys comparteixen un punt feble, i es troba a la destinació. Si inicieu sessió, el servei vincula aquella sessió al vostre compte sigui quin sigui el camí que hagin seguit els paquets. L’encaminament canvia d’on sembla que ve una petició, no què us demana la pàgina que proporcioneu.
La cobertura importa més que el diagrama d’encaminament
Una VPN encamina a la capa de xarxa, així que cada aplicació del dispositiu hereta el túnel tret que l’exclogueu expressament. Aquesta amplitud és la raó per la qual funciona alhora per a un client de correu, un gestor de paquets i un navegador.
El navegador Tor és un paquet, i les seves proteccions viuen sobretot dins del navegador: una empremta uniforme, aïllament entre llocs i scripts limitats per un nivell de seguretat i no per les extensions que hàgiu instal·lat. Dirigir Chrome a un port SOCKS compra l’encaminament sense res d’això, que és una font habitual de confiança mal col·locada.
La resta de l’escriptori queda intacta. Un client de sincronització, un actualitzador o un document baixat obert en un altre programa es connecta tal com estigui configurat aquell programa, i res d’això no passa pel dispositiu d’escolta SOCKS tret que ho hi configureu. Enumerueu les aplicacions que parlen amb la xarxa i pregunteu-vos quines cobreix realment l’eina triada. La cobertura és una propietat de la vostra configuració, no de la vostra intenció.
Trieu amb tres condicions
La decisió normalment es resol amb tres preguntes: el trànsit ve d’una aplicació o de tot el dispositiu, la destinació ha de ser incapaç d’identificar la vostra adreça, i heu d’arribar a una xarxa privada? Responeu-les en aquest ordre i l’eina gairebé sempre es tria sola.
| 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 |
Quan dos requisits entren en conflicte, valoreu quin podeu fer complir. Un túnel de dispositiu amb una llista d’exclusions amb fuites és pitjor que una ruta només de navegador que pugueu demostrar.
La verificació és barata per als dos camins, i hauria de passar abans que confieu en qualsevol dels dos:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Un resultat fals de la primera ordre significa que la petició ha sortit fora del circuit, que és la fallada que val la pena atrapar aviat. Compareu la segona amb l’adreça que us ha assignat el proveïdor, no amb la que recordeu de la setmana passada.
Què no repara cap de les dues opcions
El xifratge d’aplicacions encara fa una feina que cap ruta no fa. L’HTTP simple que travessa una xarxa de privadesa continua essent llegible a la sortida, i HTTPS continua essent l’única cosa que protegeix la càrrega d’un extrem a l’altre. TLS tampoc no diu res sobre el nom d’amfitrió que heu escrit, i per això la destinació continua visible per a qui acaba el camí.
Els comptes us identifiquen, i cap elecció d’encaminament no ho canvia: el servei sap qui ha iniciat sessió independentment de l’adreça de la capçalera. La correlació per part d’un observador que veu prou xarxa, el compromís del vostre dispositiu i tot el que escriviu en un formulari sobreviuen tots dos dissenys. Tracteu les dues eines com a maneres de moure la confiança, no d’eliminar-la.
Partiu de la configuració per defecte que documenta cada projecte, confirmeu la ruta amb les dues ordres anteriors i només després planteu-vos apilar una VPN sota Tor. Encaixar-les és una configuració amb els seus propis modes de fallada, no una actualització gratuïta.