Tor eller VPN: velg etter hvem hver rute tvinger deg til å stole på
En VPN samler tilliten din hos én operatør; Tor fordeler den over reléer. Velg etter dekning, etter hvem som kan koble deg til et nettsted, og etter hva du kan verifisere.
Valget mellom Tor og en VPN handler om hvilken part du kan tolerere ser begge ender av en forbindelse. En VPN konsentrerer det synet hos én operatør du valgte. Tor fordeler det over reléer, så ingen enkelt relé skal lære hvem du er og hva du hentet.
Ingen av de to ordningene gjør deg anonym i seg selv. Velg den der du kan si den gjenværende tilliten høyt, og reparer deretter delene den lar stå udekket.
Tell hvem som kan koble deg til en destinasjon
Med en VPN når hver dekket strøm operatørens utgang før den når destinasjonen. Den operatøren ser nødvendigvis kildeadressen din og, for alt som ikke er kryptert gjennom den, destinasjonen du ba om. TLS holder sideinnholdet utenfor det synet, men lar vanligvis vertsnavnet være synlig mens forbindelsen settes opp. Én part kan derfor koble deg til et nettsted, og den koblingen er nettopp den tilliten du gir.
Tor deler de halvdelene over tre reléer: en vakt som kjenner adressen din men ikke destinasjonen, et mellomrelé som ikke kjenner noen av endene, og en utgang som kjenner destinasjonen men ikke deg. Designet forutsetter at ingen enkelt relé kombinerer begge fakta, som er en svakere og mer nyttig forutsetning enn å stole på ett selskap. Det forutsetter ikke at reléene er ærlige, og det beseirer ikke en observatør som ser begge ender av ruten.
Begge designene deler ett svakt punkt, og det ligger ved destinasjonen. Hvis du logger inn, knytter tjenesten den økten til kontoen din uansett hvilken rute pakkene tok. Ruting endrer hvor en forespørsel ser ut til å komme fra, ikke hva siden ber deg oppgi.
Dekning betyr mer enn rutingsdiagrammet
En VPN ruter på nettverkslaget, så hver applikasjon på enheten arver tunnelen med mindre du bevisst utelukker den. Den bredden er grunnen til at det virker for en e-postklient, en pakkebehandler og en nettleser samtidig.
Tor Browser er en samlet pakke, og vernet dens lever mest inne i nettleseren: et ensartet fingeravtrykk, isolasjon mellom nettsteder og skript begrenset av et sikkerhetsnivå snarere enn av utvidelsene du installerte. Å peke Chrome mot en SOCKS-port kjøper rutingen uten noe av det, som er en vanlig kilde til feilplassert selvtillit.
Resten av skrivebordet er urørt. En synkroniseringsklient, en oppdaterer eller et nedlastet dokument som åpnes i et annet program, kobler til slik det programmet er konfigurert, og ingenting av det går gjennom SOCKS-lytteren med mindre du setter det opp der. List opp applikasjonene som snakker med nettverket, og spør deretter hvilke av dem det valgte verktøyet faktisk dekker. Dekning er en egenskap ved konfigurasjonen din, ikke ved intensjonen din.
Velg med tre betingelser
Beslutningen avgjøres vanligvis av tre spørsmål: kommer trafikken fra én applikasjon eller fra hele enheten, må destinasjonen være ute av stand til å identifisere adressen din, og trenger du å nå et privat nettverk? Svar i den rekkefølgen, og verktøyet velger som regel seg 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 |
Der to krav kolliderer, vei hvilket du kan håndheve. En enhetstunnel med en utett unntaksliste er verre enn en rute bare i nettleseren som du kan demonstrere.
Verifisering er billig for begge veier, og den bør skje før du stoler på noen av 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 falskt resultat fra den første kommandoen betyr at forespørselen forlot kretsen, og det er feilen som er verdt å fange tidlig. Sammenlign den andre med adressen leverandøren din tildelte, ikke med den du husker fra forrige uke.
Hva ingen av valgene reparerer
Applikasjonskryptering gjør fortsatt arbeid som ingen rute utfører. Vanlig HTTP som krysser et personvernnettverk, forblir lesbart ved utgangen, og HTTPS er fortsatt det eneste som beskytter nyttelasten fra ende til ende. TLS sier heller ingenting om vertsnavnet du skrev, og derfor forblir destinasjonen synlig for den som avslutter ruten.
Kontoer identifiserer deg, og ingen rutingsvalg endrer det: tjenesten vet hvem som logget inn uansett adressen i headeren. Korrelasjon fra en observatør som ser nok av nettverket, kompromittering av din egen enhet og alt du skriver i et skjema overlever begge designene. Behandle begge verktøyene som måter å flytte tillit på snarere enn måter å slette den.
Start med standardkonfigurasjonen hvert prosjekt dokumenterer, bekreft ruten med de to kommandoene ovenfor, og vurder først deretter å stable en VPN under Tor. Å legge dem inni hverandre er en konfigurasjon med egne feilmoduser, ikke en gratis oppgradering.