Tor eller VPN: vælg ud fra hvem hver rute tvinger dig til at stole på
En VPN lægger din tillid på én operatør; Tor fordeler den over relæer. Vælg ud fra dækning, ud fra hvem der kan koble dig til et websted, og ud fra hvad du kan verificere.
Valget mellem Tor og en VPN handler om, hvilken part du kan tolerere ser begge ender af en forbindelse. En VPN samler det syn på én operatør, du har valgt. Tor fordeler det over relæer, så intet enkelt relæ skal lære, hvem du er, og hvad du har hentet.
Ingen af de to ordninger gør dig anonym i sig selv. Vælg den, hvis resterende tillid du kan sige højt, og ret derefter de dele, den efterlader udækkede.
Tæl hvem der kan koble dig til en destination
Med en VPN når hver dækket strøm operatørens udgang, før den når destinationen. Den operatør ser nødvendigvis din kildeadresse og, for alt der ikke er krypteret gennem den, den destination, du bad om. TLS holder sideindhold ude af det syn, men efterlader normalt værtsnavnet synligt, mens forbindelsen oprettes. Én part kan derfor koble dig til et websted, og den kobling er præcis den tillid, du giver.
Tor deler de halvdele over tre relæer: en vagt, der kender din adresse men ikke din destination, et midterrelæ, der ikke kender nogen af enderne, og en udgang, der kender destinationen men ikke dig. Designet forudsætter, at intet enkelt relæ kombinerer begge fakta, hvilket er en svagere og mere nyttig antagelse end at stole på ét firma. Det forudsætter ikke, at relæer er ærlige, og det besejrer ikke en observatør, der ser begge ender af ruten.
Begge design har ét svagt punkt, og det ligger ved destinationen. Hvis du logger ind, knytter tjenesten den session til din konto, uanset hvilken rute pakkerne tog for at komme der. Routing ændrer, hvor en anmodning ser ud til at komme fra, ikke hvad siden beder dig om at oplyse.
Dækning betyder mere end routingdiagrammet
En VPN router på netværkslaget, så hver applikation på enheden arver tunnelen, medmindre du bevidst udelukker den. Den bredde er grunden til, at det virker for en mailklient, en pakkebehandler og en browser på samme tid.
Tor Browser er en samlet pakke, og dens beskyttelser bor mest inde i browseren: et ensartet fingeraftryk, isolation mellem websteder og scripts begrænset af et sikkerhedsniveau snarere end af de udvidelser, du har installeret. At pege Chrome mod en SOCKS-port køber routing uden noget af det, hvilket er en almindelig kilde til fejlplaceret selvtillid.
Resten af skrivebordet er urørt. En synkroniseringsklient, en opdaterer eller et downloadet dokument, der åbnes i et andet program, opretter forbindelse, som det program er konfigureret, og intet af det går gennem SOCKS-lytteren, medmindre du sætter det op der. Opret en liste over de applikationer, der taler med netværket, og spørg så, hvilke af dem det valgte værktøj faktisk dækker. Dækning er en egenskab ved din konfiguration, ikke ved din hensigt.
Vælg med tre betingelser
Beslutningen afgøres normalt af tre spørgsmål: kommer trafikken fra én applikation eller fra hele enheden, skal destinationen være ude af stand til at identificere din adresse, og har du brug for at nå et privat netværk? Svar på dem i den rækkefølge, og værktøjet vælger som regel sig selv.
| 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 |
Hvor to krav støder sammen, vej, hvilket du kan håndhæve. En enhedstunnel med en utæt undtagelsesliste er værre end en rute kun i browseren, som du kan demonstrere.
Verifikation er billig for begge veje, og den bør ske, før du stoler på nogen af dem:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Et falsk resultat fra den første kommando betyder, at anmodningen forlod kredsløbet, og det er fejlen, der er værd at fange tidligt. Sammenlign den anden med den adresse, din udbyder tildelte, ikke med den, du husker fra i sidste uge.
Hvad ingen af mulighederne reparerer
Applikationskryptering gør stadig arbejde, som ingen rute udfører. Almindelig HTTP, der krydser et privatlivsnetværk, forbliver læsbar ved udgangen, og HTTPS er fortsat det eneste, der beskytter nyttelasten fra ende til ende. TLS siger heller intet om det værtsnavn, du har skrevet, og derfor forbliver destinationen synlig for den, der afslutter ruten.
Konti identificerer dig, og intet routingvalg ændrer det: tjenesten ved, hvem der loggede ind, uanset adressen i headeren. Korrelation fra en observatør, der ser nok af netværket, kompromittering af din egen enhed og alt, hvad du skriver i en formular, overlever begge design. Behandl begge værktøjer som måder at flytte tillid på snarere end måder at slette den.
Start med den standardkonfiguration, hvert projekt dokumenterer, bekræft ruten med de to kommandoer ovenfor, og overvej først derefter at stable en VPN under Tor. At indlejre dem er en konfiguration med sine egne fejltilstande, ikke en gratis opgradering.