Voiko maksullinen VPN valtuuttaa istuntoja ilman tiliäsi?
Yhdistämättömät tokenit voivat erottaa kelpoisuuden tarkistuksen itse istunnosta. Ratkaisevaa on myöntämisen ja lunastuksen suunnittelu, ei kirjautumisnäytön merkintä.
Tunnelista maksaminen ei tarkoita, että maksajan henkilöllisyys pitäisi esittää joka yhteydellä. Suunnittelu voi tarkistaa kelpoisuuden kerran, antaa asiakkaalle kryptografiset tokenit ja antaa yhdyskäytävän hyväksyä tokenin myöhemmin näkemättä sen takana olevaa tiliä. Se, kätkeekö tämä todella jotain, riippuu myöntämistä ja lunastusta koskevista valinnoista, joten käsittele sitä neliosaisena määrittelyharjoituksena äläkä ominaisuutena, jonka kytket päälle.
Erota ostovaihe istuntovaiheesta
RFC 9576:n Privacy Pass -arkkitehtuuri antaa sanaston: asiakas, todentaja, myöntäjä ja alkuperä. Asiakas todistaa jonkin ominaisuuden myöntäjälle ja saa tokeneita; myöhemmin se esittää yhden alkuperälle, joka päättää, palveleeko sitä. VPN:ään sovellettuna todennettava ominaisuus voisi olla yksi käyttöyksikkö.
Laskutus näkee edelleen sen, mitä sen oma prosessi tarvitsee, eikä kukaan väitä muuta. Kapeampi tavoite on, ettei myöhempää lunastusta voi yhdistää ostoon, joka tuotti tokenin. Se on konkreettinen ja testattava ominaisuus, ja juuri se kannattaa kirjata.
Satunnaiselta näyttävä kantajamerkkijono ei tarjoa sitä. Jos myöntäjä tallentaa arvon asiakastietueen viereen ja yhdyskäytävä voi kysyä tätä vastaavuutta, kaksi tapahtumaa yhdistyvät tietokannan eikä kryptografian kautta. Rakenteen on tehtävä myöntäjä kyvyttömäksi vastaamaan siihen kysymykseen, ja käyttöönoton on estettävä myöntäjää ja yhdyskäytävää yhdistämästä näkemyksiään.
Päätä, mihin yksi token valtuuttaa
«Yksi token ostaa pääsyn» ei vastaa käytännössä juuri mihinkään. Onko yksikkö yksi yhteys, aikakiintiö vai datamäärä? Voiko asiakas, joka menetti vastauksensa, jatkaa samaa myönnettyä oikeutta? Mitä tapahtuu, kun laite yhdistää uudelleen verkon vaihtuessa? Nämä vastaukset ratkaisevat, onko suunnittelu käyttökelpoinen, ja jokaisella niistä on seuraus yksityisyydelle.
| 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 |
Valitse yksi tarkoituksella ja kirjoita sen viereen virhetilanteen toiminta. Asiakas, joka aikakatkaisun jälkeen yrittää uudelleen uudella oikeudella, kuluttaa toisen yksikön, mikä on samalla sekä laskutusyllätys että yksityisyyden signaali.
Kirjoita uudelleenkäytön ja peruutuksen toimintatapa
Peruutus on kohta, jossa anonyymit suunnitelmat yleensä rikkovat oman lupauksensa. Tilauksen lopettaminen ja jo myönnettyjen tokenien mitätöiminen ovat eri toimintoja, eikä yhdyskäytävä, joka hiljaa tekee tilihakukan päätöksen tueksi, ole siinä kohdassa enää anonyymi.
Valitse vanheneminen, myöntämisraja ja peruutustarina, jotka sopivat yhteen. Tarkista sitten yhdyskäytävän omat tietueet kentistä, jotka tuovat takaisin poistamasi yhteyden.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Tuo haku listaa lokitiedostot, joissa on token- tai tilikenttiä, ja se on ensimmäinen paikka, jossa huolellinen suunnittelu vuotaa käytännössä. Istuntotietue, joka tallentaa tokenin arvon tilin tunnisteen viereen, tuhoaa koko rakenteen, ja se saapuu yleensä virheenkorjausmuutoksen kautta, jota kukaan ei tarkistanut uudelleen.
Määrittele myös, mitä yhdyskäytävä säilyttää istunnon päätyttyä. Kesto, tavut ja päätepiste ovat hyödyllisiä ylläpidolle, ja jokainen niistä on pala palapeliä, jonka tarkkailija haluaisi. Pidä säilytysaika lyhyenä ja kenttäluettelo lyhyenä ja tarkista molemmat, kun virheenkorjausmuutos lisää sarakkeen. Kukaan ei huomaa uutta lokikenttää ennen kuin se on ollut siellä vuoden.
Esitä väite ja sitten havainnot, jotka jäävät
Kirjoita yksityisyysväite yhteen lauseeseen sen oletuksineen: mikä osapuoli ei saa pystyä yhdistämään mitä konteksteja, ja mitä tapahtuu, jos myöntäjä ja yhdyskäytävä vertaavat muistiinpanojaan. Suunnitelma, joka selviää tuosta lauseesta, on arvioitavissa; vain «nollatietämykseksi» kuvattu ei ole.
Luettele sitten, mikä pysyy näkyvänä kaikesta huolimatta. Lähdeosoitteet, yhteyksien ajat, pakettien koot ja yksinkertainen tosiasia, että osto tapahtui hieman ennen ainoan uuden yhteyden ilmestymistä, ovat kaikki kryptografian ulkopuolella. Yksi asiakas, joka ostaa yhden yksikön ja yhdistää kerran, on yhdistettävissä pelkän ajoituksen perusteella, eikä mikään token-suunnittelu muuta sitä.
Rehellinen tulos on kapeampi yhteys tilin ja käytön välillä, ei näkymätön istunto. Se kannattaa silti rakentaa, kunhan dokumentaatio sanoo niin ja käyttötietueet vastaavat väitettä.