Kan en betald VPN auktorisera sessioner utan ditt konto?
Token som inte går att koppla samman kan skilja behörighetskontrollen från själva sessionen. Det som avgör är utformningen av utfärdande och inlösen, inte etiketten på inloggningen.
Att betala för en tunnel behöver inte betyda att du visar faktureringsidentiteten vid varje anslutning. En design kan kontrollera behörigheten en gång, ge kunden kryptografiska tokens och låta gatewayen acceptera en token senare utan att se kontot bakom den. Om det verkligen döljer något beror på valen kring utfärdande och inlösen, så behandla det som en specifikationsövning med fyra avsnitt i stället för en funktion du slår på.
Skilj köpsteget från sessionssteget
Privacy Pass-arkitekturen i RFC 9576 ger vokabulären: en klient, en attesterare, en utfärdare och en ursprungspunkt. Klienten bevisar en egenskap för utfärdaren och får tokens; senare presenterar den en för ursprungspunkten, som avgör om den vill betjäna den. Tillämpat på en VPN kan egenskapen som attesteras vara en enda åtkomstsenhet.
Faktureringen ser fortfarande det den egna processen behöver, och ingen påstår något annat. Det snävare målet är att den senare inlösen inte kan kopplas tillbaka till köpet som skapade token. Det är en konkret, testbar egenskap, och det är den som är värd att skriva ned.
En sträng som ser slumpmässig ut ger inte det. Om utfärdaren lagrar värdet bredvid en kundpost och gatewayen kan fråga efter den mappningen, är de två interaktionerna sammankopplade via databas i stället för via kryptografi. Konstruktionen måste göra utfärdaren oförmögen att svara på frågan, och driftsättningen måste hindra utfärdaren och gatewayen från att slå ihop sina vyer.
Bestäm vad en token auktoriserar
”En token köper åtkomst” säger nästan ingenting operativt. Är enheten en enda anslutning, en tidskvot eller en volym? Kan en klient som tappat svaret återuppta samma beviljande? Vad händer när en enhet återansluter under en nätverksändring? De svaren avgör om designen är användbar, och varje svar har en integritetskonsekvens.
| Reuse rule | What it buys | What it leaks |
|---|---|---|
| Single use per connection | Strongest unlinkability between sessions | Frequent reissuance, more purchase-to-use timing pairs |
| Bounded time window | Fewer tokens, reconnects work | Activity inside the window is linkable |
| Long-lived grant | Operationally simple | Behaves like an account reference with extra steps |
Välj en medvetet och skriv felbeteendet bredvid. En klient som försöker igen med en ny rättighet efter en tidsgräns förbrukar ytterligare en enhet, vilket är både en faktureringsöverraskning och en integritetssignal.
Skriv policyn för återanvändning och återkallelse
Återkallelse är där anonyma designer vanligtvis bryter sitt eget löfte. Att avsluta en prenumeration och att ogiltigförklara redan utfärdade tokens är olika operationer, och en gateway som i tysthet gör en kontosökning för att avgöra är inte längre anonym i det läget.
Välj en utgångstid, en utfärdandegräns och en återkallelseberättelse som passar ihop. Kontrollera sedan gatewayens egna register efter fält som återinför kopplingen du tog bort.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Den sökningen listar loggfiler som innehåller token- eller kontofält, vilket är den första platsen en noggrann design läcker i praktiken. En sessionspost som lagrar tokenvärdet bredvid en kontoidentifierare omintetgör hela konstruktionen, och den kommer oftast in via en felsökningsändring som ingen gått tillbaka till.
Definiera också vad gatewayen behåller efter att en session avslutats. Varaktighet, byte och ändpunkt är användbara för drift, och var och en av dem är en pusselbit som en observatör gärna vill ha. Håll kvarhållningstiden kort och fältlistan kort, och granska båda när en felsökningsändring lägger till en kolumn. Ingen lägger märke till ett nytt loggfält förrän det stått där i ett år.
Formulera påståendet och sedan de observationer som återstår
Skriv integritetspåståendet i en mening med dess antaganden: vilken part som måste vara oförmögen att koppla vilka sammanhang, och vad som händer om utfärdaren och gatewayen jämför sina anteckningar. En design som överlever den meningen går att granska; en som bara beskrivs som ”noll kunskap” gör det inte.
Lista sedan vad som förblir synligt oavsett. Källadresser, anslutningstider, paketstorlekar och det enkla faktum att ett köp skedde strax innan den enda nya anslutningen dök upp ligger alla utanför kryptografin. En enda kund som köper en enhet och ansluter en gång går att koppla enbart via tidpunkter, och ingen tokendesign ändrar på det.
Det ärliga resultatet är en snävare koppling mellan konto och användning, inte en osynlig session. Det är fortfarande värt att bygga, så länge dokumentationen säger det och driftregistren stämmer med påståendet.