Kan en betalt VPN godkende sessioner uden din konto?
Tokens uden kobling kan adskille kontrol af berettigelse fra selve sessionen. Det afgørende er designet af udstedelse og indløsning, ikke etiketten på loginskærmen.
At betale for en tunnel behøver ikke betyde, at betalingsidentiteten fremvises ved hver forbindelse. Et design kan kontrollere berettigelsen én gang, give kunden kryptografiske tokens og lade gatewayen senere acceptere et token uden at se kontoen bag det. Om det reelt skjuler noget, afhænger af valgene omkring udstedelse og indløsning, så behandl det som en specifikationsøvelse med fire afsnit frem for en funktion, du slår til.
Adskil købstrinnet fra sessionstrinnet
Privacy Pass-arkitekturen i RFC 9576 giver ordforrådet: en klient, en attesterer, en udsteder og en oprindelse. Klienten beviser en egenskab over for udstederen og modtager tokens; senere fremviser den et til oprindelsen, som afgør, om den vil betjene det. Anvendt på en VPN kan den attesterede egenskab være én enhed adgang.
Fakturering ser stadig det, dens egen proces har brug for, og ingen påstår andet. Det snævrere mål er, at den senere indløsning ikke kan kædes sammen med det køb, der frembragte tokenet. Det er en konkret og testbar egenskab, og den er værd at skrive ned.
En tilfældigt udseende bærerstreng giver det ikke. Hvis udstederen gemmer værdien ved siden af en kundepost, og gatewayen kan spørge efter den kobling, er de to interaktioner forbundet via en database frem for via kryptografi. Konstruktionen skal gøre udstederen ude af stand til at besvare spørgsmålet, og udrulningen skal forhindre, at udsteder og gateway lægger deres viden sammen.
Fastlæg, hvad ét token godkender
«Et token køber adgang» besvarer næsten intet operationelt. Er enheden en enkelt forbindelse, en tidskvote eller et volumen? Kan en klient, der mistede svaret, genoptage den samme bevilling? Hvad sker der, når en enhed genopretter forbindelse under et netværksskift? De svar afgør, om designet er brugbart, og hvert af dem har en konsekvens for privatlivet.
| 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ælg ét bevidst, og skriv fejlopførslen ved siden af. En klient, der prøver igen med en ny rettighed efter en timeout, bruger endnu en enhed, hvilket er både en faktureringsoverraskelse og et privatlivssignal.
Skriv politikken for genbrug og tilbagekaldelse
Tilbagekaldelse er der, hvor anonyme designs normalt bryder deres eget løfte. At opsige et abonnement og at ugyldiggøre allerede udstedte tokens er forskellige handlinger, og en gateway, der stille slår kontoen op for at beslutte, er ikke længere anonym på det punkt.
Vælg en udløbsdato, en udstedelsesgrænse og en tilbagekaldelseshistorie, der passer sammen. Gennemgå derefter gatewayens egne registreringer for felter, der genindfører den kobling, du fjernede.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Den søgning lister logfiler med token- eller kontofelter, og det er det første sted, et omhyggeligt design lækker i praksis. En sessionspost, der gemmer tokenværdien ved siden af en kontoidentifikator, ødelægger hele konstruktionen, og den kommer normalt ind via en fejlretningsændring, som ingen har set på igen.
Definér også, hvad gatewayen beholder, når en session slutter. Varighed, bytes og endepunkt er nyttige for driften, og hver af dem er en brik i det puslespil, en observatør gerne vil have. Hold opbevaringsperioden kort og feltlisten kort, og gennemgå begge, når en fejlretningsændring tilføjer en kolonne. Ingen lægger mærke til et nyt logfelt, før det har været der i et år.
Formulér påstanden, og derefter de observationer, der står tilbage
Skriv privatlivspåstanden i én sætning med dens antagelser: hvilken part der skal være ude af stand til at koble hvilke sammenhænge, og hvad der sker, hvis udstederen og gatewayen sammenligner noter. Et design, der overlever den sætning, kan revideres; et, der kun beskrives som «nul viden», kan ikke.
List derefter, hvad der forbliver synligt uanset hvad. Kildeaddresser, forbindelsestider, pakkestørrelser og det simple faktum, at et køb fandt sted kort før den eneste nye forbindelse, ligger alle uden for kryptografien. En enkelt kunde, der køber én enhed og forbinder én gang, kan kobles alene på timing, og intet tokendesign ændrer det.
Det ærlige resultat er en snævrere kobling mellem konto og brug, ikke en usynlig session. Det er stadig værd at bygge, så længe dokumentationen siger det, og driftsregistreringerne passer med påstanden.