Tor of VPN: besluit op grond van wie elke pad jou laat vertrou
’n VPN stapel jou vertroue op een operateur; Tor versprei dit oor herleiers. Besluit op grond van dekking, van wie jou aan ’n webwerf kan koppel en van wat jy kan verifieer.
Om tussen Tor en ’n VPN te kies, kom neer op watter party jy kan verdra om albei kante van ’n verbinding te sien. ’n VPN konsentreer daardie siening in een operateur wat jy gekies het. Tor verdeel dit oor herleiers, sodat geen enkele herleier bedoel is om te leer wie jy is en wat jy opgehaal het nie.
Nie een van die twee reëlings maak jou op sigself anoniem nie. Kies die een wie se oorblywende vertroue jy hardop kan noem, en maak dan die dele reg wat dit onbedek laat.
Tel wie jou aan ’n bestemming kan koppel
Met ’n VPN bereik elke gedekte vloei die operateur se uitgang voordat dit die bestemming bereik. Daardie operateur sien noodwendig jou bronadres en, vir enigiets wat nie daardeur geënkripteer is nie, die bestemming wat jy aangevra het. TLS hou bladsyinhoud buite daardie siening, maar laat gewoonlik die gasheernaam sigbaar terwyl die verbinding opgestel word. Een party kan jou dus aan ’n webwerf koppel, en daardie koppeling is presies die vertroue wat jy gee.
Tor skei daardie helftes oor drie herleiers: ’n wag wat jou adres ken maar nie jou bestemming nie, ’n middelherleier wat geen van die twee kante ken nie, en ’n uitgang wat die bestemming ken maar nie jou nie. Die ontwerp aanvaar dat geen enkele herleier albei feite kombineer nie, wat ’n swakker en nuttiger aanname is as om een maatskappy te vertrou. Dit aanvaar nie dat herleiers eerlik is nie, en dit verslaan nie ’n waarnemer wat albei kante van die pad dophou nie.
Albei ontwerpe deel een swak punt, en dit sit by die bestemming. As jy inteken, koppel die diens daardie sessie aan jou rekening, ongeag watter roete die pakkette gevolg het om daar te kom. Roetering verander waar ’n versoek skynbaar vandaan kom, nie wat die bladsy jou vra om te verskaf nie.
Dekking maak meer saak as die roeteringsdiagram
’n VPN roeteer op die netwerklaag, so elke toepassing op die toestel erf die tonnel tensy jy dit doelbewus uitsluit. Daardie breedte is hoekom dit gelyktydig vir ’n e-poskatkliënt, ’n pakketbestuurder en ’n blaaier werk.
Tor Browser is ’n bundel, en sy beskermings lê meestal binne die blaaier: ’n eenvormige vingerafdruk, isolasie tussen werwe en skrifte wat deur ’n sekuriteitsvlak beperk word eerder as deur watter uitbreidings jy ook al geïnstalleer het. Om Chrome na ’n SOCKS-poort te wys, gee jou die roetering sonder enige van daardie beskermings, wat ’n algemene bron van misplaasde selfvertroue is.
Die res van die lessenaar bly onaangeraak. ’n Sinchroniseringskliënt, ’n opdateraar of ’n afgelaaide dokument wat in ’n ander program oopgemaak word, maak verbinding soos daardie program opgestel is, en niks daarvan gaan deur die SOCKS-ontvanger tensy jy dit daar instel nie. Lys die toepassings wat met die netwerk praat, en vra dan watter van hulle die gekose hulpmiddel werklik dek. Dekking is ’n eienskap van jou opstelling, nie van jou bedoeling nie.
Kies met drie voorwaardes
Die besluit val gewoonlik op drie vrae: kom die verkeer van een toepassing of van die hele toestel, moet die bestemming jou adres nie kan identifiseer nie, en moet jy ’n private netwerk bereik? Beantwoord hulle in daardie volgorde, en die hulpmiddel kies meestal homself.
| 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 vereistes bots, weeg af watter een jy kan afdwing. ’n Toesteltonnel met ’n lekkende uitsluitingslys is slegter as ’n roete net in die blaaier wat jy kan demonstreer.
Verifikasie is goedkoop vir albei paaie, en dit moet gebeur voordat jy op enigeen staatmaak:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
’n Valse resultaat van die eerste opdrag beteken dat die versoek buite die stroombaan vertrek het, wat die fout is wat die moeite werd is om vroeg te vang. Vergelyk die tweede met die adres wat jou verskaffer toegewys het, nie met die een wat jy van verlede week onthou nie.
Wat nie een van die twee opsies herstel nie
Toepassingsenkripsie doen steeds werk wat geen roete verrig nie. Gewone HTTP wat ’n privaatheidsnetwerk kruis, bly leesbaar by die uitgang, en HTTPS bly die enigste ding wat die vrag van punt tot punt beskerm. TLS sê ook niks oor die gasheernaam wat jy getik het nie, en daarom bly die bestemming sigbaar vir elkeen wat die pad beëindig.
Rekeninge identifiseer jou, en geen roetekeuse verander dit nie: die diens weet wie aangemeld het, ongeag die adres in die kop nie. Korrelasie deur ’n waarnemer wat genoeg van die netwerk sien, kompromittering van jou eie toestel en enigiets wat jy in ’n vorm intik, oorleef albei ontwerpe. Beskou albei hulpmiddels as maniere om vertroue rond te skuif eerder as maniere om dit uit te wis.
Begin by die verstekopstelling wat elke projek dokumenteer, bevestig die roete met die twee opdragte hierbo, en oorweeg eers daarna om ’n VPN onder Tor te stapel. Om hulle te nes te maak is ’n opstelling met sy eie foutmodusse, nie ’n gratis opgradering nie.