അക്കൗണ്ട് ഇല്ലാതെ ഒരു പണമടച്ച VPN സെഷനുകൾ അധികാരപ്പെടുത്താൻ കഴിയുമോ?
ബന്ധിപ്പിക്കാൻ കഴിയാത്ത ടോക്കണുകൾ യോഗ്യതാ പരിശോധനയെ സെഷനിൽ നിന്നുതന്നെ വേർപെടുത്താം. പ്രധാനം ഇഷ്യൂവിംഗിന്റെയും റിഡെംപ്ഷന്റെയും രൂപകൽപ്പനയാണ്, ലോഗിൻ സ്ക്രീനിലെ ലേബലല്ല.
ഒരു ടണലിന് പണം നൽകുക എന്നത് ഓരോ കണക്ഷനിലും ബില്ലിംഗ് ഐഡന്റിറ്റി കാണിക്കണം എന്നല്ല. ഒരു രൂപകൽപ്പന യോഗ്യത ഒരിക്കൽ പരിശോധിച്ച്, ഉപഭോക്താവിന് ക്രിപ്റ്റോഗ്രാഫിക് ടോക്കണുകൾ നൽകി, പിന്നീട് ഗേറ്റ്വേയ്ക്ക് അതിന് പിന്നിലുള്ള അക്കൗണ്ട് കാണാതെ ടോക്കൺ സ്വീകരിക്കാൻ അനുവദിക്കാം. അത് യഥാർത്ഥത്തിൽ എന്തെങ്കിലും മറയ്ക്കുന്നുണ്ടോ എന്നത് ഇഷ്യൂവിംഗ്, റിഡെംപ്ഷൻ തീരുമാനങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ ഇത് ഓൺ ചെയ്യുന്ന ഒരു സവിശേഷതയല്ല, നാല് ഭാഗങ്ങളുള്ള ഒരു സ്പെസിഫിക്കേഷൻ അഭ്യാസമായി കാണുക.
വാങ്ങൽ ഘട്ടത്തെ സെഷൻ ഘട്ടത്തിൽ നിന്ന് വേർതിരിക്കുക
RFC 9576-ലെ Privacy Pass ആർക്കിടെക്ചർ പദാവലി നൽകുന്നു: ക്ലയന്റ്, അറ്റസ്റ്റർ, ഇഷ്യൂവർ, ഒറിജിൻ. ക്ലയന്റ് ഇഷ്യൂവറിനോട് ഏതോ ഒരു ഗുണം തെളിയിച്ച് ടോക്കണുകൾ വാങ്ങുന്നു; പിന്നീട് ഒന്ന് ഒറിജിന് സമർപ്പിക്കുന്നു, അത് സേവനം നൽകണമോ എന്ന് തീരുമാനിക്കുന്നു. VPN-ൽ പ്രയോഗിക്കുമ്പോൾ അറ്റസ്റ്റ് ചെയ്യുന്ന ഗുണം ഒരു പ്രവേശന യൂണിറ്റ് ആകാം.
ബില്ലിംഗ് അതിന്റെ സ്വന്തം പ്രക്രിയയ്ക്ക് ആവശ്യമുള്ളത് ഇപ്പോഴും കാണുന്നു, അതിന് വിരുദ്ധമായി ആരും വാദിക്കുന്നില്ല. ഇടുങ്ങിയ ലക്ഷ്യം, പിന്നീടുള്ള റിഡെംപ്ഷൻ ടോക്കൺ സൃഷ്ടിച്ച വാങ്ങലുമായി ബന്ധിപ്പിക്കാൻ കഴിയാതിരിക്കുക എന്നതാണ്. അത് നിർദ്ദിഷ്ടവും പരിശോധിക്കാവുന്നതുമായ ഒരു ഗുണമാണ്, അതാണ് എഴുതിവയ്ക്കാൻ യോഗ്യമായത്.
ക്രമരഹിതമായി തോന്നുന്ന ഒരു വാഹക ശ്രേണി അത് നൽകുന്നില്ല. ഇഷ്യൂവർ മൂല്യം ഉപഭോക്തൃ രേഖയ്ക്കൊപ്പം സൂക്ഷിക്കുകയും ഗേറ്റ്വേ ആ മാപ്പിംഗ് ചോദിക്കാൻ കഴിയുകയും ചെയ്താൽ, രണ്ട് ഇടപെടലുകളും ക്രിപ്റ്റോഗ്രാഫിയല്ല, ഡാറ്റാബേസാണ് ബന്ധിപ്പിക്കുന്നത്. ആ ചോദ്യത്തിന് ഉത്തരം നൽകാൻ ഇഷ്യൂവറെ അപ്രാപ്തമാക്കണം, ഇഷ്യൂവറും ഗേറ്റ്വേയും അവരുടെ കാഴ്ചപ്പാടുകൾ ഒരുമിപ്പിക്കാതിരിക്കാനും വിന്യാസം വേണം.
ഒരു ടോക്കൺ എന്തിന് അധികാരം നൽകുന്നു എന്ന് തീരുമാനിക്കുക
«ഒരു ടോക്കൺ പ്രവേശനം വാങ്ങുന്നു» പ്രവർത്തനപരമായി ഏതാണ്ട് ഒന്നും ഉത്തരം നൽകുന്നില്ല. യൂണിറ്റ് ഒരു കണക്ഷനാണോ, സമയ വിഹിതമാണോ, അതോ അളവാണോ? പ്രതികരണം നഷ്ടപ്പെട്ട ക്ലയന്റിന് അതേ അനുവാദം തുടരാമോ? നെറ്റ്വർക്ക് മാറുമ്പോൾ ഉപകരണം വീണ്ടും ബന്ധിപ്പിച്ചാൽ എന്ത് സംഭവിക്കും? ഈ ഉത്തരങ്ങളാണ് രൂപകൽപ്പനയുടെ ഉപയോഗക്ഷമത തീരുമാനിക്കുന്നത്, ഓരോന്നിനും സ്വകാര്യതയിൽ പ്രത്യാഘാതമുണ്ട്.
| 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 |
ഒന്ന് ബോധപൂർവ്വം തിരഞ്ഞെടുത്ത് അതിനൊപ്പം പരാജയ സ്വഭാവം എഴുതുക. സമയം കഴിഞ്ഞതിന് ശേഷം പുതിയ അവകാശത്തോടെ വീണ്ടും ശ്രമിക്കുന്ന ക്ലയന്റ് മറ്റൊരു യൂണിറ്റ് ചെലവഴിക്കുന്നു, അത് ഒരേ സമയം ബില്ലിംഗ് ആശ്ചര്യവും സ്വകാര്യതാ സൂചനയുമാണ്.
പുനരുപയോഗ, റദ്ദാക്കൽ നയം എഴുതുക
അജ്ഞാത രൂപകൽപ്പനകൾ സാധാരണയായി സ്വന്തം വാഗ്ദാനം ലംഘിക്കുന്നിടമാണ് റദ്ദാക്കൽ. സബ്സ്ക്രിപ്ഷൻ റദ്ദാക്കുന്നതും ഇതിനകം ഇഷ്യൂ ചെയ്ത ടോക്കണുകൾ അസാധുവാക്കുന്നതും വ്യത്യസ്ത പ്രവർത്തനങ്ങളാണ്, തീരുമാനിക്കാൻ നിശ്ശബ്ദമായി അക്കൗണ്ട് തിരയുന്ന ഗേറ്റ്വേ ആ നിമിഷത്തിൽ അജ്ഞാതമല്ല.
പരസ്പരം യോജിക്കുന്ന കാലാവധി, ഇഷ്യൂ പരിധി, റദ്ദാക്കൽ കഥ എന്നിവ തിരഞ്ഞെടുക്കുക. തുടർന്ന് നിങ്ങൾ നീക്കിയ ബന്ധം വീണ്ടും കൊണ്ടുവരുന്ന ഫീൽഡുകൾക്കായി ഗേറ്റ്വേയുടെ സ്വന്തം രേഖകൾ പരിശോധിക്കുക.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
ആ തിരയൽ ടോക്കൺ അല്ലെങ്കിൽ അക്കൗണ്ട് ഫീൽഡുകൾ അടങ്ങിയ ലോഗ് ഫയലുകൾ പട്ടികപ്പെടുത്തുന്നു, പ്രായോഗികമായി സൂക്ഷ്മമായ രൂപകൽപ്പന ആദ്യം ചോരുന്നത് അവിടെയാണ്. ടോക്കൺ മൂല്യം അക്കൗണ്ട് ഐഡന്റിഫയറിനൊപ്പം സൂക്ഷിക്കുന്ന സെഷൻ രേഖ മുഴുവൻ നിർമ്മാണത്തെയും തകർക്കുന്നു, അത് സാധാരണയായി ആരും വീണ്ടും പരിശോധിക്കാത്ത ഡീബഗ്ഗിംഗ് മാറ്റത്തിലൂടെയാണ് വരുന്നത്.
സെഷൻ അവസാനിച്ചതിന് ശേഷം ഗേറ്റ്വേ എന്ത് സൂക്ഷിക്കുന്നു എന്നും നിർവചിക്കുക. ദൈർഘ്യം, ബൈറ്റുകൾ, എൻഡ്പോയിന്റ് എന്നിവ പ്രവർത്തനങ്ങൾക്ക് ഉപകരിക്കും, ഓരോന്നും നിരീക്ഷകൻ സ്വന്തമാക്കാൻ ആഗ്രഹിക്കുന്ന പസിലിന്റെ കഷണമാണ്. സൂക്ഷിക്കുന്ന കാലയളവ് ചെറുതും ഫീൽഡ് പട്ടിക ചെറുതുമായി നിലനിർത്തുക, ഡീബഗ്ഗിംഗ് മാറ്റം ഒരു കോളം ചേർത്താൽ രണ്ടും വീണ്ടും പരിശോധിക്കുക. പുതിയ ലോഗ് ഫീൽഡ് ഒരു വർഷം ഉണ്ടായിരിക്കുന്നതുവരെ ആരും ശ്രദ്ധിക്കുന്നില്ല.
അവകാശവാദം പറയുക, പിന്നെ ബാക്കിയുള്ള നിരീക്ഷണങ്ങൾ
സ്വകാര്യതാ അവകാശവാദം അതിന്റെ അനുമാനങ്ങളോടെ ഒരു വാക്യത്തിൽ എഴുതുക: ഏത് കക്ഷി ഏത് സന്ദർഭങ്ങൾ ബന്ധിപ്പിക്കാൻ പാടില്ല, ഇഷ്യൂവറും ഗേറ്റ്വേയും കുറിപ്പുകൾ താരതമ്യം ചെയ്താൽ എന്ത് സംഭവിക്കും. ആ വാക്യം അതിജീവിക്കുന്ന രൂപകൽപ്പന പരിശോധിക്കാവുന്നതാണ്; «പൂജ്യം അറിവ്» എന്ന് മാത്രം വിവരിക്കുന്നതല്ല.
പിന്നെ എന്തായാലും കാണാവുന്നത് പട്ടികപ്പെടുത്തുക. സ്രോതസ്സ് വിലാസങ്ങൾ, കണക്ഷൻ സമയങ്ങൾ, പാക്കറ്റ് വലിപ്പങ്ങൾ, ഏക പുതിയ കണക്ഷൻ പ്രത്യക്ഷപ്പെടുന്നതിന് തൊട്ടുമുമ്പ് ഒരു വാങ്ങൽ നടന്നു എന്ന ലളിതമായ വസ്തുത — എല്ലാം ക്രിപ്റ്റോഗ്രാഫിക്ക് പുറത്താണ്. ഒരു യൂണിറ്റ് വാങ്ങി ഒരിക്കൽ ബന്ധിപ്പിക്കുന്ന ഒരു ഉപഭോക്താവിനെ സമയം കൊണ്ട് മാത്രം ബന്ധിപ്പിക്കാം, ഒരു ടോക്കൺ രൂപകൽപ്പനയും അത് മാറ്റുന്നില്ല.
സത്യസന്ധമായ ഫലം അദൃശ്യമായ സെഷനല്ല, അക്കൗണ്ടും ഉപയോഗവും തമ്മിലുള്ള ഇടുങ്ങിയ ബന്ധമാണ്. രേഖകൾ അങ്ങനെ പറയുന്നെങ്കിലും പ്രവർത്തന രേഖകൾ അവകാശവാദവുമായി യോജിക്കുന്നെങ്കിലും അത് നിർമ്മിക്കുന്നത് ഇപ്പോഴും യോഗ്യമാണ്.