VPN en Tor vervangen HTTPS niet: waar elke laag eindigt
Een tunnel eindigt bij zijn eigen tegenpartij en een Tor-circuit eindigt bij een exitrelay. Alleen HTTPS bereikt de site, dus een gewoon formulier blijft leesbaar.
Een VPN en een Tor-circuit versleutelen allebei je verkeer voor een deel van de reis. Beide stoppen met versleutelen bij een tegenpartij die ze zelf kiezen. HTTPS is de laag die de site zelf bereikt, en geen enkele hoeveelheid tunneling ervoor maakt van een gewone formulierinzending een beschermde. Elke laag volgen tot het punt waar hij eindigt, maakt dat duidelijk.
Drie lagen, drie verschillende eindpunten
Een conventionele VPN beëindigt zijn tunnel bij de VPN-server. Alles tussen je apparaat en die server zit in de tunnel, en alles daarna niet. Een Tor-circuit gedraagt zich hetzelfde met een andere tegenpartij en verlaat het netwerk bij een exitrelay die je verzoek naar de bestemming doorstuurt.
TLS eindigt bij de site. Het certificaat dat je hebt gevalideerd, bindt een hostnaam aan een sleutel die de site beheert, en de sessiesleutels bestaan tussen je browser en die server. Dat eindpunt ligt voorbij zowel de VPN-server als de Tor-uitgang.
De drie lagen hebben dus drie verschillende vertrouwensgrenzen, en een verzoek gaat er in volgorde door alle drie. Eén versterken zegt niets over de andere, en de laatste is de enige waaraan de bestemming deelneemt.
Wat de laatste sprong blootlegt
Als de toepassing gewone HTTP gebruikt, is de inhoud voorbij de uitgang leesbaar voor iedereen die die sprong beheert. De eerdere tunnel deed zijn werk perfect en is er simpelweg niet meer. Inloggegevens die in een HTTP-formulier worden getypt, liggen precies op het punt open waar de bescherming eindigde.
| Layer | Terminates at | Who can read the request there |
|---|---|---|
| VPN tunnel | The VPN server you selected | The operator of that server, and anyone who can compel them |
| Tor circuit | An exit relay chosen by the network | The exit relay operator, for traffic that is not otherwise protected |
| HTTPS | The website's own TLS endpoint | The site itself, and no intermediary on the path |
Met correct gevalideerde HTTPS kan een tussenpersoon op het pad de inhoud van de toepassing niet lezen of stil wijzigen. Hij ziet nog steeds dat je verbonden bent, wanneer en naar welk adres, omdat de pakketheaders routeerbaar moeten zijn. Vertrouwelijkheid van inhoud en metadata over de verbinding zijn verschillende eigenschappen, en alleen de eerste is wat TLS biedt.
Accountidentiteit is weer een derde ding. Inloggen op een account identificeert je bij die dienst ongeacht welk uitgangsadres je gebruikte, dus de uitgang beschermt het netwerkpad en niet het account. Dat onderscheid overleeft elk aantal lagen ervoor. Van uitgang wisselen verandert nooit wat een ingelogde sessie onthult. De dienst wist wie je was voordat het eerste pakket vertrok.
Niets aan deze opstelling gaat kapot door een tweede tunnel toe te voegen. Wat verandert, is welke waarnemer de eerste sprong ziet, niet of de laatste sprong versleuteld is.
De volgorde verandert de waarnemers, niet het eindpunt
Een VPN en Tor aan elkaar koppelen is een legitieme manier om te veranderen wie op netwerkniveau wat ziet. Tor over een VPN laten lopen verbergt voor je toegangsnetwerk het feit dat je Tor gebruikt, terwijl een VPN over Tor je adres voor de VPN-aanbieder verbergt. Beide volgordes zijn in openbare documentatie beschreven en beide hebben afwegingen in prestaties en foutgedrag.
Geen van beide volgordes verschuift het TLS-eindpunt. In beide gevallen valideert de browser nog steeds een certificaat voor de gevraagde hostnaam, en in beide gevallen stuurt een HTTP-adres zijn inhoud nog steeds onversleuteld na de laatste relay. De samenstelling verandert de waarnemerslijst; ze verandert niet het aantal lagen bij de bestemming.
Daarom gaat advies over koppelen meestal over dreigingsmodellen en niet over veiligheid in het algemeen. Een langere keten is geen sterkere versie van hetzelfde, en het is geen vervanging voor het protocol dat de toepassing koos.
curl -sSI https://example.net | head -3
openssl s_client -connect example.net:443 -servername example.net -brief
Beide commando's tonen de laag die bij de bestemming telt. Het tweede drukt het onderhandelde protocol af zonder een tunnel te betrekken. Geen van beide vertelt je iets over de uitgang die je gebruikte.
Houd de validatie werkend terwijl je problemen oplost
Een certificaatwaarschuwing is informatie over de verbinding die je op het punt staat te maken. Het kan een hostnaamafwijking, een klokprobleem, een niet-vertrouwde keten of een afluisterpoging betekenen. Een permanente uitzondering toevoegen omdat er een VPN verbonden is, haalt het enige signaal weg dat die gevallen zou hebben onderscheiden.
De veilige-verbindingsfuncties van Tor Browser en zijn waarschuwingen bestaan om dezelfde reden, en ze uitschakelen zodat een pagina laadt, ruilt een zichtbare fout voor een onzichtbare. Als een site niet zonder uitzondering bereikbaar is, is de eerlijke conclusie dat de verbinding niet verifieerbaar is, niet dat de tunnel hem veilig heeft gemaakt.
Versleuteling zegt ook niets over bedoeling. Een geldige HTTPS-verbinding met een misleidende site levert je gegevens met volmaakte vertrouwelijkheid aan die site. Controleer het adres en wat je indient, niet alleen of het slotje aanwezig is.
Onion-diensten zijn een werkelijk ander model. Ze worden via het Tor-netwerk bereikt zonder een gewone openbare uitgang, wat niet hetzelfde is als een openbare site via Tor bezoeken. Behandel dat als een apart geval met eigen verwachtingen, niet als een sterkere versie van hetzelfde bezoek.
De regel die elke configuratie overleeft, is kort. Houd de browservalidatie intact. Beoordeel elke laag naar waar hij werkelijk eindigt.