Kan en betalt VPN autorisere sesjoner uten kontoen din?
Tokens som ikke kan kobles sammen, kan skille berettigelsessjekken fra selve sesjonen. Det som betyr noe, er utformingen av utstedelse og innløsning, ikke etiketten på innloggingen.
Å betale for en tunnel trenger ikke bety at du viser betalingsidentiteten ved hver tilkobling. En løsning kan kontrollere berettigelsen én gang, gi kunden kryptografiske tokens og la gatewayen godta et token senere uten å se kontoen bak det. Om det faktisk skjuler noe, avhenger av valgene for utstedelse og innløsning, så behandle det som en spesifikasjonsøvelse med fire avsnitt i stedet for en funksjon du slår på.
Skill kjøpstrinnet fra sesjonstrinnet
Privacy Pass-arkitekturen i RFC 9576 gir vokabularet: en klient, en attester, en utsteder og en opprinnelse. Klienten beviser en egenskap overfor utstederen og mottar tokens; senere presenterer den ett for opprinnelsen, som avgjør om den vil betjene det. Brukt på en VPN kan egenskapen som attesteres, være nøyaktig én tilgangsenhet.
Fakturering ser fortsatt det dens egen prosess trenger, og ingen påstår noe annet. Det snevrere målet er at den senere innløsningen ikke kan knyttes tilbake til kjøpet som produserte tokenet. Det er en bestemt, testbar egenskap, og den er verdt å skrive ned.
En streng som ser tilfeldig ut, gir ikke dette. Hvis utstederen lagrer verdien ved siden av en kundepost og gatewayen kan spørre etter den koblingen, er de to interaksjonene knyttet sammen via database i stedet for kryptografi. Konstruksjonen må gjøre utstederen ute av stand til å svare på spørsmålet, og utplasseringen må hindre utstederen og gatewayen i å slå sammen oversiktene sine.
Bestem hva ett token autoriserer
«Ett token kjøper tilgang» svarer nesten ingenting operativt. Er enheten en enkelt tilkobling, en tidskvote eller et volum? Kan en klient som mistet svaret, gjenoppta samme tildeling? Hva skjer når en enhet kobler til på nytt under en nettverksendring? Svarene avgjør om løsningen er brukbar, og hvert av dem har en personvernkonsekvens.
| 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 |
Velg én med overlegg og skriv feilatferden ved siden av. En klient som prøver på nytt med en ny berettigelse etter en tidsavbrudd, bruker opp nok en enhet, noe som er både en faktureringsoverraskelse og et personvernsignal.
Skriv policyen for gjenbruk og tilbakekalling
Tilbakekalling er der anonyme løsninger vanligvis bryter sitt eget løfte. Å avslutte et abonnement og å ugyldiggjøre allerede utstedte tokens er forskjellige operasjoner, og en gateway som i stillhet gjør et kontooppslag for å avgjøre, er ikke lenger anonym på det punktet.
Velg en utløpstid, en utstedelsesgrense og en tilbakekallingshistorie som passer sammen. Sjekk deretter gatewayens egne poster for felt som gjeninnfører koblingen du fjernet.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Det søket lister loggfiler som inneholder token- eller kontofelt, som er det første stedet en grundig løsning lekker i praksis. En sesjonspost som lagrer tokenverdien ved siden av en kontoidentifikator, ødelegger hele konstruksjonen, og den kommer vanligvis via en feilsøkingsendring ingen har gått tilbake til.
Definer også hva gatewayen beholder etter at en sesjon er avsluttet. Varighet, byte og endepunkt er nyttige for drift, og hvert av dem er en brikke en observatør gjerne vil ha. Hold oppbevaringsperioden kort og feltlisten kort, og gjennomgå begge når en feilsøkingsendring legger til en kolonne. Ingen legger merke til et nytt loggfelt før det har stått der i et år.
Formuler påstanden, og deretter observasjonene som gjenstår
Skriv personvernpåstanden i én setning med forutsetningene: hvilken part som må være ute av stand til å knytte hvilke kontekster sammen, og hva som skjer hvis utstederen og gatewayen sammenligner notater. En løsning som overlever den setningen, kan gjennomgås; en som bare beskrives som «null kunnskap», kan ikke.
List deretter opp det som forblir synlig uansett. Kildeadresser, tilkoblingstider, pakkestørrelser og det enkle faktum at et kjøp skjedde kort før den eneste nye tilkoblingen dukket opp, ligger alt utenfor kryptografien. En enkelt kunde som kjøper én enhet og kobler til én gang, kan kobles sammen bare ved hjelp av timing, og ingen tokenkonstruksjon endrer det.
Det ærlige resultatet er en snevrere kobling mellom konto og bruk, ikke en usynlig sesjon. Det er fortsatt verdt å bygge, så lenge dokumentasjonen sier det og driftsregistrene stemmer med påstanden.