Maaari bang mag-authorize ng mga session ang bayad na VPN nang walang account mo?
Ang mga token na hindi maikakabit ay maaaring maghiwalay ng pagsusuri ng karapatan mula sa session mismo. Ang mahalaga ay ang disenyo ng pag-isyu at pagtubos, hindi ang label sa pag-login.
Ang pagbabayad para sa isang tunnel ay hindi kailangang mangahulugan ng pagpapakita ng pagkakakilanlang pambayad sa bawat koneksyon. Maaaring suriin ng isang disenyo ang karapatan nang isang beses, bigyan ang kostumer ng mga cryptographic token, at hayaan ang gateway na tumanggap ng token mamaya nang hindi nakikita ang account sa likod nito. Kung talagang may itinatago ito ay nakasalalay sa mga pagpipilian sa pag-isyu at pagtubos, kaya ituring itong pagsasanay sa espesipikasyon na may apat na seksyon sa halip na isang feature na binubuksan mo.
Paghiwalayin ang hakbang ng pagbili sa hakbang ng session
Ang arkitekturang Privacy Pass sa RFC 9576 ay nagbibigay ng bokabularyo: isang kliyente, isang attester, isang nag-isyu at isang pinagmulan. Pinatutunayan ng kliyente ang isang katangian sa nag-isyu at tumatanggap ng mga token; mamaya naghaharap ito ng isa sa pinagmulan, na nagpapasya kung ito ay seserbisyuhan. Kapag inilapat sa isang VPN, ang katangiang pinatutunayan ay maaaring isang solong yunit ng pag-access.
Nakikita pa rin ng pagsingil ang kailangan ng sarili nitong proseso, at walang nagsasabing iba. Ang mas makitid na layunin ay ang pagtubos mamaya ay hindi maikabit pabalik sa pagbili na gumawa ng token. Iyon ay isang tiyak, nasusubok na katangian, at iyon ang nararapat isulat.
Ang bearer string na mukhang random ay hindi nagbibigay nito. Kung iniimbak ng nag-isyu ang halaga sa tabi ng talaan ng kostumer at maaaring hingin ng gateway ang mapping na iyon, ang dalawang interaksyon ay pinag-uugnay ng database sa halip na ng cryptography. Kailangang gawin ng konstruksyon na hindi makasagot ang nag-isyu sa tanong na iyon, at kailangang pigilan ng deployment na pagsamahin ng nag-isyu at gateway ang kanilang mga pananaw.
Magpasya kung ano ang ina-authorize ng isang token
Ang «isang token ay bumibili ng pag-access» ay halos walang sinasabi sa pagpapatakbo. Ang yunit ba ay isang koneksyon, isang paglalaan ng oras, o isang volume? Maaari bang ipagpatuloy ng kliyenteng nawalan ng tugon ang parehong pagpapahintulot? Ano ang nangyayari kapag muling kumonekta ang isang device habang nagbabago ang network? Ang mga sagot na iyon ang nagpapasya kung magagamit ang disenyo, at bawat isa ay may kahihinatnan sa privacy.
| 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 |
Pumili ng isa nang sinasadya at isulat sa tabi nito ang pag-uugali kapag nabigo. Ang kliyenteng muling sumusubok na may bagong karapatan pagkatapos ng timeout ay kumokonsumo ng isa pang yunit, na sabay na sorpresa sa pagsingil at senyales sa privacy.
Isulat ang patakaran sa muling paggamit at pagbawi
Ang pagbawi ang lugar kung saan karaniwang sinisira ng mga anonymous na disenyo ang sarili nilang pangako. Ang pagkansela ng subscription at pagpapawalang-bisa ng mga token na naisyu na ay magkaibang operasyon, at ang gateway na tahimik na naghahanap ng account upang magpasya ay hindi na anonymous sa puntong iyon.
Pumili ng pag-expire, limitasyon sa pag-isyu at kuwento ng pagbawi na magkakatugma. Pagkatapos ay suriin ang sariling mga talaan ng gateway para sa mga field na nagbabalik ng ugnayang inalis mo.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Inililista ng paghahanap na iyon ang mga log file na naglalaman ng token o field ng account, na siyang unang lugar kung saan tumatagas ang maingat na disenyo sa praktika. Ang talaan ng session na nag-iimbak ng halaga ng token sa tabi ng identifier ng account ay sumisira sa buong konstruksyon, at kadalasan ay dumarating ito sa pamamagitan ng pagbabagong pang-debug na walang bumalik upang tingnan.
Tukuyin din kung ano ang pinapanatili ng gateway pagkatapos ng session. Ang tagal, bytes at endpoint ay kapaki-pakinabang sa operasyon, at bawat isa ay piraso ng palaisipan na nais ng isang nagmamasid. Panatilihing maikli ang panahon ng pagpapanatili at maikli ang listahan ng field, pagkatapos ay suriin ang pareho kapag may pagbabagong pang-debug na nagdaragdag ng kolum. Walang pumapansin sa bagong field ng log hangga't hindi ito naroroon nang isang taon.
Sabihin ang pag-aangkin, pagkatapos ang mga obserbasyong natitira
Isulat ang pag-aangkin sa privacy sa isang pangungusap kasama ang mga palagay nito: aling partido ang dapat na hindi makapag-ugnay ng aling mga konteksto, at ano ang mangyayari kung ihambing ng nag-isyu at gateway ang kanilang mga tala. Ang disenyong nakakaligtas sa pangungusap na iyon ay masusuri; ang inilalarawan lamang bilang «zero knowledge» ay hindi.
Pagkatapos ay ilista kung ano ang nananatiling nakikita kahit ano pa. Ang mga address ng pinagmulan, oras ng koneksyon, laki ng packet at ang simpleng katotohanang nangyari ang isang pagbili ilang saglit bago lumitaw ang nag-iisang bagong koneksyon ay lahat nasa labas ng cryptography. Ang isang kostumer na bumili ng isang yunit at kumonekta nang isang beses ay maikakabit sa pamamagitan lamang ng oras, at walang disenyo ng token ang makakabago niyon.
Ang tapat na resulta ay isang mas makitid na ugnayan sa pagitan ng account at paggamit, hindi isang di-nakikitang session. Sulit pa ring itayo, hangga't sinasabi ito ng dokumentasyon at tumutugma ang mga talaan ng operasyon sa pag-aangkin.