Onion-dienst versus VPN-dienst: verschillende toegangsmodellen

Mensen beschrijven een Onion-dienst en een dienst die alleen via VPN bereikbaar is als twee varianten van hetzelfde idee: verberg de poort, deel het geheime adres. Ze verschillen in waaraan het adres gebonden is, wie het kan bereiken en wat er moet gebeuren voordat een verzoek aankomt. Het ene is een ontmoetingspunt binnen Tor, het andere een route binnen een particulier netwerk. Ze als uitwisselbaar behandelen levert ontwerpen op die noch privé noch onderhoudbaar zijn.

De mythe: beide ontwerpen zijn maar een verborgen deur

De gedeelde eigenschap is echt maar dun: geen van beide ontwerpen zet de beheerinterface op een direct bereikbare openbare poort. Alles daarna loopt uiteen. Een Onion-adres wordt afgeleid van de eigen sleutel van de dienst, dus de naam is aan een identiteit gebonden; een VPN-adres is alleen een adres binnen een netwerk waar je bent toegelaten. Het ene verbergt de dienst in een overlaylaag, het andere laat je toe in een particuliere topologie. Het tweede als synoniem van het eerste zien, daar begint de verwarring.

Geen van beide eigenschappen is een beveiligingsmaatregel voor de applicatie zelf. Een verborgen locatie patcht de software erachter niet, en een particuliere route voegt geen authenticatie toe aan de inlogpagina. Beide ontwerpen hebben nog steeds de eigen rechten van de applicatie nodig, en beide hebben nog steeds iemand nodig die verantwoordelijk is voor updates en herstel.

Waar een Onion-adres werkelijk naar wijst

Een Onion-adres van versie v3 codeert de openbare sleutel van de dienst, daarom kan niemand een adres kiezen voor een dienst die hij niet beheert. De client verbindt via Tor met een ontmoetingspunt, en de dienst bereikt hetzelfde punt vanaf zijn kant; geen gewone uitgangsnode draagt die verbinding naar de dienst. De naam is een identiteit, geen DNS-record.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

Daarom helpt het niets om een route of een hosts-regel voor een onion-naam toe te voegen. De opzoeking is niet het mechanisme; de Tor-client en zijn circuits zijn dat. Als de dienst bedoeld is voor een kleine groep mensen, kan onion-clientautorisatie een sleutel eisen voordat de verbinding wordt geaccepteerd, maar dat is nog steeds geen applicatie-login. Het adres publiceren is ook een bewuste handeling, want iedereen die het leert kan een verbinding proberen tenzij je het hebt beperkt.

Stop als de enige reden voor het onion-ontwerp is om het instellen van authenticatie te vermijden. De overlaylaag biedt dat niet, en je bouwt het later toch.

Wat een VPN-route werkelijk geeft

Een VPN laat een apparaat toe in een netwerk en geeft het een route naar een gateway of een subnet. De dienst achter die gateway ziet een adres uit de tunnelpool en past de autorisatie toe die hij heeft. De route zegt niets over wie de gebruiker is; ze zegt waar pakketten mogen heen gaan.

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

Dat model past bij een bekende groep met beheerde apparaten, omdat de gateway de apparaatstatus kan afdwingen en het netwerk kan worden geaudit. Het past slecht bij anonieme of ad-hocbezoekers, die eerst zouden moeten worden ingeschreven. De eigen login van de applicatie bepaalt nog steeds wat een verbonden gebruiker mag lezen. Bereikbaarheid met toestemming verwarren is hoe een VPN uiteindelijk een heel subnet geeft aan iedereen die kan verbinden.

Stop als het publiek onbekend is of voortdurend verandert. Vreemden inschrijven in een particulier netwerk om hun één pagina te tonen is een grote verplichting vergeleken met het publiceren van een dienst.

Kiezen tussen beide, en wat hetzelfde blijft

Kies het onion-model wanneer het publiek technisch is, de dienst helemaal geen openbaar adres mag hebben en je de eisen van de Tor-client kunt accepteren. Kies het VPN-model wanneer het publiek een afgebakende groep is waarvan je de apparaten beheert en waarvan je de toegang op netwerkniveau wilt loggen. Geen van beide keuzes haalt de behoefte aan applicatie-authenticatie, patches of een herstelpad weg. Geen van beide is automatisch meer privé in de zin die voor je gebruikers telt.

Schrijf in beide ontwerpen op wie de dienst kan bereiken, hoe ze worden geïdentificeerd en wat er gebeurt als een inloggegeven verloren gaat. Het antwoord voor een onion-dienst omvat de clientautorisatiesleutels en het adres zelf; het antwoord voor een VPN omvat het account, het apparaat en het gatewaybeleid. Dat zijn verschillende inventarissen, en slechts één ervan zal voor de volgende beheerder vanzelfsprekend zijn.

De vergelijking eindigt waar de applicatie begint. Een verborgen adres en een particuliere route zijn transportkeuzes, en de applicatie moet nog steeds beslissen wat een verzoek mag doen. Houd die beslissingen in aparte documenten, en geen van beide ontwerpen zal stilzwijgend het werk van het andere overnemen.