Kan een betaalde VPN sessies autoriseren zonder jouw account?
Niet-koppelbare tokens kunnen de geschiktheidscontrole losmaken van de sessie zelf. Wat telt is het ontwerp van uitgifte en inwisseling, niet het label op de login.
Betalen voor een tunnel hoeft niet te betekenen dat je bij elke verbinding de factuuridentiteit laat zien. Een ontwerp kan de geschiktheid één keer controleren, de klant cryptografische tokens geven en de gateway later een token laten accepteren zonder het account erachter te zien. Of dat echt iets verbergt, hangt af van de keuzes bij uitgifte en inwisseling, dus behandel het als een specificatieoefening met vier secties in plaats van een functie die je aanzet.
Scheid de aankoopstap van de sessiestap
De Privacy Pass-architectuur in RFC 9576 levert het vocabulaire: een client, een attester, een uitgever en een origin. De client bewijst een eigenschap aan de uitgever en ontvangt tokens; later toont hij er een aan de origin, die beslist of hij die bedient. Toegepast op een VPN kan de bewezen eigenschap één enkele eenheid toegang zijn.
Facturering ziet nog steeds wat het eigen proces nodig heeft, en niemand beweert anders. Het smallere doel is dat de latere inwisseling niet kan worden teruggevoerd op de aankoop die het token heeft geproduceerd. Dat is een specifieke, testbare eigenschap, en het is de moeite waard om die op te schrijven.
Een willekeurig uitziende bearer-string levert dat niet. Als de uitgever de waarde naast een klantrecord opslaat en de gateway naar die koppeling kan vragen, zijn de twee interacties verbonden door een database in plaats van door cryptografie. De constructie moet de uitgever onbekwaam maken om die vraag te beantwoorden, en de implementatie moet voorkomen dat de uitgever en de gateway hun beelden samenvoegen.
Bepaal waarvoor één token autoriseert
‘Eén token koopt toegang’ zegt operationeel bijna niets. Is de eenheid één verbinding, een tijdsbudget of een volume? Kan een client die zijn antwoord kwijt is, dezelfde toekenning hervatten? Wat gebeurt er als een apparaat opnieuw verbindt tijdens een netwerkwijziging? Die antwoorden bepalen of het ontwerp bruikbaar is, en elk ervan heeft een privacygevolg.
| 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 |
Kies er bewust één en schrijf het faalgedrag ernaast. Een client die na een time-out opnieuw probeert met een nieuwe aanspraak, verbruikt nog een eenheid, wat tegelijk een factureringsverrassing en een privacysignaal is.
Schrijf het hergebruik- en intrekkingsbeleid
Intrekking is waar anonieme ontwerpen meestal hun eigen belofte breken. Een abonnement opzeggen en al uitgegeven tokens ongeldig maken zijn verschillende handelingen, en een gateway die stilletjes een accountopzoeking doet om te beslissen, is op dat punt niet meer anoniem.
Kies een vervaltijd, een uitgiftelimiet en een intrekkingsverhaal die bij elkaar passen. Controleer daarna de eigen administratie van de gateway op velden die de koppeling die je hebt verwijderd weer invoeren.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Die zoekopdracht somt logbestanden op met token- of accountvelden, wat in de praktijk de eerste plek is waar een zorgvuldig ontwerp lekt. Een sessierecord dat de tokenwaarde naast een accountidentificatie opslaat, ondermijnt de hele constructie, en het komt meestal binnen via een debugwijziging waar niemand naar terugkeek.
Bepaal ook wat de gateway na het einde van een sessie bewaart. Duur, bytes en endpoint zijn nuttig voor de bedrijfsvoering, en elk daarvan is een stukje van de puzzel dat een observeerder graag heeft. Houd de bewaartermijn kort en de veldenlijst kort, en herzie beide wanneer een debugwijziging een kolom toevoegt. Niemand merkt een nieuw logveld op voordat het er een jaar staat.
Formuleer de claim, en dan de observaties die overblijven
Schrijf de privacyclaim in één zin met de aannames: welke partij welke contexten niet aan elkaar moet kunnen koppelen, en wat er gebeurt als de uitgever en de gateway aantekeningen vergelijken. Een ontwerp dat die zin overleeft, is beoordeelbaar; een dat alleen als ‘zero knowledge’ wordt beschreven, niet.
Som daarna op wat hoe dan ook zichtbaar blijft. Bronadressen, verbindingstijden, pakketgroottes en het simpele feit dat een aankoop kort voor de enige nieuwe verbinding plaatsvond, vallen allemaal buiten de cryptografie. Een enkele klant die één eenheid koopt en één keer verbindt, is alleen al via timing koppelbaar, en geen enkel tokenontwerp verandert dat.
Het eerlijke resultaat is een smallere koppeling tussen account en gebruik, geen onzichtbare sessie. Dat is nog steeds de moeite van het bouwen waard, zolang de documentatie dat zegt en de operationele gegevens bij de claim passen.