Maakt een VPN vóór Tor je moeilijker te volgen?

Nog een versleuteld segment aan een route toevoegen verwijdert de waarnemers niet; het verplaatst ze, en soms komt er één bij. De nuttige oefening is de route tekenen en labelen wie bij elke stap wat ziet, want een VPN vóór Tor en een VPN die via Tor wordt bereikt geven tegengestelde antwoorden op bijna elke vraag die de moeite waard is. Geen van beide opstellingen verslaat een gecompromitteerd eindpunt, en geen van beide repareert een account dat de gebruiker noemt. De route in volgorde aflopen en dan vragen wat er breekt als een laag verdwijnt, maakt van een slogan een beslissing.

Loop de route en benoem elke waarnemer

Begin met het gewone Tor-geval en label elke hop. Het lokale netwerk en de internetprovider zien een verbinding met een Tor-ingangspunt, samen met de omvang en timing ervan. De ingangsbewaker ziet het adres van de client, en daarom is de bewaker een langdurige relatie in plaats van een willekeurige keuze. Het uitgangsknooppunt ziet de bestemming en de platte tekst van alles wat niet end-to-end versleuteld is, terwijl de bestemming een uitgangsadres ziet zonder enig clientadres eraan verbonden.

Schrijf die labels op voordat je iets toevoegt. Het diagram is het argument, en het is gemakkelijk te controleren.

Twee orden geven verschillende waarnemingen

Een VPN vóór Tor betekent dat het verkeer het apparaat verlaat richting de VPN-aanbieder, die aanbieder verlaat en pas daarna een Tor-ingang bereikt. Het lokale netwerk ziet Tor helemaal niet meer, en dat is precies het punt wanneer een netwerk het blokkeert of er toezicht op houdt. De ingangsbewaker ziet nu het adres van de VPN in plaats van dat van de gebruiker, en de VPN-aanbieder ziet dat een bepaalde klant met een bepaald tijdpatroon verbinding maakt met Tor. Die aanbieder wordt een nieuwe partij met een waardevolle waarneming, en het logbeleid is nu deel van het dreigingsmodel in plaats van erbuiten.

Een VPN bereiken via Tor keert de volgorde om en keert ook om wat er wordt blootgelegd: de bestemming ziet het adres van de VPN, de Tor-uitgang ziet de bestemming niet meer, en de VPN-aanbieder ziet binnenkomend Tor-verkeer in plaats van het thuisadres van een klant. Het belast de verbinding ook met twee lagen latentie en vereist clientondersteuning die veel commerciële toepassingen niet bieden.

Kiezen tussen beide is een vraag over welke waarnemer het meest telt, niet over welke veiliger klinkt. Een gebruiker die Tor-gebruik voor een lokaal netwerk verbergt, wil de eerste orde; een gebruiker die probeert te voorkomen dat een bestemming iets leert dat aan hem toerekenbaar is, heeft een andere analyse nodig, en geen van beide orden verbergt een accountnaam.

Wat de sessie nog identificeert

Waarnemers op adresniveau zijn slechts een deel van het beeld, en vaak niet het beslissende deel. Een aangemeld account verbindt de activiteit aan een identiteit, ongeacht welk uitgangsadres het pakket droeg, en een betalingsrecord dat de dienst aan een persoon kan koppelen doet hetzelfde. De browsertoestand draagt ook bij: een blijvende cookie, een opgeslagen login of een identificerende extensie kan een gebruiker volgen door circuits die ontworpen zijn om niet koppelbaar te zijn.

Inhoud die naar een site wordt gestuurd is het derde signaal. Een document met metadata, een in een formulier getypte naam of een unieke schrijfstijl overleven elk aantal versleutelingslagen, en geen van de hulpmiddelen ervoor is ontworpen om dat aan te raken. Een eerlijke lijst van deze identificatoren bijhouden beschermt meer dan nog een hop toevoegen.

Plan voor een laag die verdwijnt

Gedrag bij uitval is waar de opstellingen echt verschillen, en het is een configuratie-eigenschap, geen functie van een van beide hulpmiddelen. Als de VPN wegvalt terwijl Tor is ingesteld om erdoorheen te gaan, stopt Tor dan, of maakt het stilletjes opnieuw verbinding via de gewone route? De tweede uitkomst is geen lek naar de bestemming, maar het maakt aan het lokale netwerk duidelijk dat Tor wordt gebruikt, wat misschien precies is wat de opstelling wilde voorkomen.

Een killswitch op apparaatniveau kan een deel van het antwoord afdwingen door verkeer buiten de tunnel te weigeren, en hij dekt alleen verkeer dat het apparaat routeert. Een toepassing die van de tunnel is uitgesloten, omzeilt die bescherming, en een resolver die bij het opzetten van de verbinding wordt gebruikt, kan namen onthullen zelfs wanneer de payload in de tunnel blijft. Lees de uitsluitingen en de resolverconfiguratie in plaats van aan te nemen dat de schakelaar alles dekt.

Laat het browserpakket met rust

De beschermingen van Tor Browser hangen ervan af dat het hele pakket zich gedraagt zoals bedoeld: de eigen proxyconfiguratie, de isolatie tussen sites en de verdediging tegen vingerafdrukken. Een gewone browser op een lokale Tor-poort richten, of een proxy-extensie aan Tor Browser toevoegen, verandert aannames waarop het ontwerp leunt. De eigen richtlijnen van Tor Project over een VPN met Tor combineren behandelen de combinatie als een geavanceerde configuratie, en die voorzichtigheid gaat over deze interacties en niet over de VPN-leverancier.

Voordat je hulpmiddelen combineert, moet je de normale route, de uitvalroute en de rol van elke operator in eenvoudige zinnen kunnen benoemen. Als de enige rechtvaardiging is dat twee lagen veiliger klinken, is er geen eis om tegen te ontwerpen, en de toegevoegde storingsmodus is het belangrijkste dat is toegevoegd.