Kan 'n betaalde VPN sessies magtig sonder jou rekening?
Onkoppelbare tekens kan die geskiktheidskontrole van die sessie self skei. Wat saak maak is die ontwerp van uitreiking en inlossing, nie die etiket op die aanmelding nie.
Om vir 'n tonnel te betaal hoef nie te beteken dat jy die betaalidentiteit by elke verbinding moet wys nie. 'n Ontwerp kan geskiktheid een keer nagaan, aan die kliënt kriptografiese tekens gee, en die poort later 'n teken laat aanvaar sonder om die rekening daarager te sien. Of dit werklik iets wegsteek, hang af van die keuses rondom uitreiking en inlossing, so behandel dit as 'n spesifikasie-oefening met vier afdelings eerder as 'n funksie wat jy aanskakel.
Skei die aankoopstap van die sessiestap
Die Privacy Pass-argitektuur in RFC 9576 gee die woordeskat: 'n kliënt, 'n attesteerder, 'n uitreiker en 'n oorsprong. Die kliënt bewys een of ander eienskap aan die uitreiker en ontvang tekens; later wys hy een aan die oorsprong, wat besluit of hy dit bedien. Op 'n VPN toegepas, kan die eienskap wat geattesteer word 'n enkele eenheid toegang wees.
Fakturering sien steeds wat sy eie proses nodig het, en niemand beweer anders nie. Die nouer doel is dat die latere inlossing nie teruggevoer kan word na die aankoop wat die teken geskep het nie. Dit is 'n spesifieke, toetsbare eienskap, en dit is die een wat die moeite werd is om neer te skryf.
'n Lukraak-ogende draerstring bied dit nie. As die uitreiker die waarde langs 'n klantrekord stoor en die poort daardie koppeling kan opvra, word die twee interaksies deur 'n databasis verbind eerder as deur kriptografie. Die konstruksie moet die uitreiker onbekwaam maak om daardie vraag te antwoord, en die ontplooiing moet keer dat die uitreiker en die poort hul sienings saamvoeg.
Bepaal waarvoor een teken magtiging gee
«Een teken koop toegang» antwoord operasioneel byna niks. Is die eenheid 'n enkele verbinding, 'n tydtoelae of 'n volume? Kan 'n kliënt wat sy antwoord verloor het dieselfde toekenning hervat? Wat gebeur wanneer 'n toestel gedurende 'n netwerkverandering weer koppel? Daardie antwoorde bepaal of die ontwerp bruikbaar is, en elkeen het 'n privaatheidgevolg.
| 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 een doelbewus en skryf die foutgedrag daarby. 'n Kliënt wat ná 'n tydsverloop met 'n nuwe reg opnuut probeer, verbruik nog 'n eenheid, wat terselfdertyd 'n faktureringsverrassing en 'n privaatheidsignaal is.
Skryf die hergebruik- en herroepingsbeleid
Herroeping is waar anonieme ontwerpe gewoonlik hul eie belofte breek. Die kansellasie van 'n intekening en die ongeldigmaking van tekens wat reeds uitgereik is, is verskillende bewerkings, en 'n poort wat stilweg 'n rekeningnavraag doen om te besluit, is op daardie punt nie meer anoniem nie.
Kies 'n vervaldatum, 'n uitreikingslimiet en 'n herroepingsverhaal wat by mekaar pas. Gaan dan die poort se eie rekords na vir velde wat die skakel wat jy verwyder het, weer invoer.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Daardie soektog lys loglêers wat teken- of rekeningvelde bevat, en dit is die eerste plek waar 'n sorgvuldige ontwerp in die praktyk lek. 'n Sessierekord wat die tekenwaarde langs 'n rekeningidentifiseerder stoor, verydel die hele konstruksie, en dit kom gewoonlik deur 'n ontfoutingsverandering wat niemand weer nagegaan het nie.
Bepaal ook wat die poort ná die einde van 'n sessie hou. Duur, grepe en eindpunt is nuttig vir bedryf, en elkeen is 'n stukkie van die legkaart wat 'n waarnemer graag sou wou hê. Hou die bewaartydperk kort en die veldlys kort, en hersien albei wanneer 'n ontfoutingsverandering 'n kolom byvoeg. Niemand merk 'n nuwe logveld op voordat dit 'n jaar daar is nie.
Stel die bewering, dan die waarnemings wat oorbly
Skryf die privaatheidsbewering in een sin met sy aannames: watter party moet onbekwaam wees om watter kontekste te koppel, en wat gebeur as die uitreiker en die poort notas vergelyk. 'n Ontwerp wat daardie sin oorleef, is hersienbaar; een wat net as «zero knowledge» beskryf word, is nie.
Lys dan wat ongeag sigbaar bly. Bronadresse, verbindingstye, pakketgroottes en die eenvoudige feit dat 'n aankoop kort voor die enigste nuwe verbinding gebeur het, val alles buite die kriptografie. 'n Enkele klant wat een eenheid koop en een keer koppel, is bloot deur tydsberekening koppelbaar, en geen tekenontwerp verander dit nie.
Die eerlike resultaat is 'n nouer skakel tussen rekening en gebruik, nie 'n onsigbare sessie nie. Dit is steeds die moeite werd om te bou, solank die dokumentasie dit sê en die bedryfsrekords by die bewering pas.