Tor of VPN: beslis op basis van wie elk pad je dwingt te vertrouwen
Een VPN stapelt je vertrouwen op één operator; Tor verdeelt het over relays. Beslis op basis van dekking, van wie je aan een site kan koppelen en van wat je kunt verifiëren.
Kiezen tussen Tor en een VPN komt neer op welke partij je kunt tolereren beide uiteinden van een verbinding te zien. Een VPN concentreert dat zicht bij één operator die je hebt gekozen. Tor verdeelt het over relays, zodat geen enkel relay hoort te leren wie je bent en wat je hebt opgehaald.
Geen van beide opzetten maakt je op zichzelf anoniem. Kies degene waarvan je het resterende vertrouwen hardop kunt benoemen, en herstel daarna de delen die het onbedekt laat.
Tel wie je aan een bestemming kan koppelen
Met een VPN bereikt elke gedekte stroom de uitgang van de operator voordat hij de bestemming bereikt. Die operator ziet noodzakelijkerwijs je bronadres en, voor alles wat er niet doorheen versleuteld is, de bestemming die je hebt opgevraagd. TLS houdt de pagina-inhoud buiten dat zicht, maar laat gewoonlijk de hostnaam zichtbaar terwijl de verbinding wordt opgezet. Eén partij kan je dus aan een site koppelen, en die koppeling is precies het vertrouwen dat je geeft.
Tor splitst die helften over drie relays: een wachter die je adres kent maar niet je bestemming, een middenrelay die geen van beide uiteinden kent, en een uitgang die de bestemming kent maar niet jou. Het ontwerp veronderstelt dat geen enkel relay beide feiten combineert, wat een zwakkere en nuttiger aanname is dan één bedrijf vertrouwen. Het veronderstelt niet dat relays eerlijk zijn, en het verslaat geen waarnemer die beide uiteinden van het pad ziet.
Beide ontwerpen delen één zwak punt, en dat ligt bij de bestemming. Als je inlogt, koppelt de dienst die sessie aan je account, welke route de pakketten ook namen. Routing verandert waar een verzoek vandaan lijkt te komen, niet wat de pagina je vraagt te verstrekken.
Dekking is belangrijker dan het routingdiagram
Een VPN routeert op de netwerklaag, dus elke applicatie op het apparaat erft de tunnel, tenzij je die bewust uitsluit. Die breedte is de reden dat het tegelijk werkt voor een mailclient, een pakketbeheerder en een browser.
Tor Browser is een bundel, en de beschermingen leven vooral in de browser: een uniforme vingerafdruk, isolatie tussen sites en scripts die door een beveiligingsniveau worden beperkt in plaats van door de extensies die je hebt geïnstalleerd. Chrome naar een SOCKS-poort wijzen koopt de routing zonder iets daarvan, wat een veelvoorkomende bron van misplaatst zelfvertrouwen is.
De rest van de desktop blijft onaangeroerd. Een synchronisatieclient, een updater of een gedownload document dat in een ander programma wordt geopend, verbindt zoals dat programma is geconfigureerd, en niets daarvan gaat door de SOCKS-listener tenzij je het daar instelt. Inventariseer de applicaties die met het netwerk praten en vraag dan welke daarvan het gekozen hulpmiddel werkelijk dekt. Dekking is een eigenschap van je configuratie, niet van je bedoeling.
Kies met drie voorwaarden
De beslissing lost meestal op met drie vragen: komt het verkeer uit één applicatie of van het hele apparaat, moet de bestemming niet in staat zijn je adres te identificeren, en moet je een particulier netwerk bereiken? Beantwoord ze in die volgorde en het hulpmiddel kiest zich meestal zelf.
| 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 |
Waar twee eisen botsen, weeg af welke je kunt afdwingen. Een apparaattunnel met een lekke uitsluitingslijst is slechter dan een route alleen in de browser die je kunt aantonen.
Verificatie is goedkoop voor beide paden, en het zou moeten gebeuren voordat je op een van beide vertrouwt:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Een onjuist resultaat van de eerste opdracht betekent dat het verzoek het circuit heeft verlaten, en dat is de fout die het waard is vroeg te vangen. Vergelijk de tweede met het adres dat je provider heeft toegewezen, niet met het adres dat je van vorige week herinnert.
Wat geen van beide opties repareert
Applicatieversleuteling doet nog steeds werk dat geen enkele route verricht. Gewone HTTP die een privacy-netwerk doorkruist, blijft leesbaar bij de uitgang, en HTTPS blijft het enige dat de payload van begin tot eind beschermt. TLS zegt ook niets over de hostnaam die je hebt getypt, waardoor de bestemming zichtbaar blijft voor wie het pad beëindigt.
Accounts identificeren je, en geen enkele routingkeuze verandert dat: de dienst weet wie zich heeft aangemeld, ongeacht het adres in de header. Correlatie door een waarnemer die genoeg van het netwerk ziet, compromittering van je eigen apparaat en alles wat je in een formulier typt, overleven beide ontwerpen. Behandel beide hulpmiddelen als manieren om vertrouwen te verplaatsen, niet om het te wissen.
Begin met de standaardconfiguratie die elk project documenteert, bevestig de route met de twee opdrachten hierboven, en overweeg pas daarna een VPN onder Tor te stapelen. Ze in elkaar schuiven is een configuratie met eigen faalmodi, geen gratis upgrade.