क्या कोई सशुल्क 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/
वह खोज ऐसी लॉग फ़ाइलें सूचीबद्ध करती है जिनमें टोकन या खाता फ़ील्ड हैं, और व्यवहार में सावधान डिज़ाइन पहली बार यहीं चूता है। जो सत्र रिकॉर्ड टोकन का मान किसी खाता पहचानकर्ता के पास रखता है वह पूरा निर्माण बिगाड़ देता है, और यह आम तौर पर ऐसे डिबगिंग बदलाव से आता है जिसे किसी ने दोबारा नहीं देखा।
यह भी तय करें कि सत्र खत्म होने के बाद गेटवे क्या रखता है। अवधि, बाइट और एंडपॉइंट परिचालन के लिए उपयोगी हैं, और इनमें से हर एक उस पहेली का टुकड़ा है जो एक पर्यवेक्षक चाहेगा। अवधारण अवधि छोटी और फ़ील्ड की सूची छोटी रखें, फिर जब डिबगिंग बदलाव कोई कॉलम जोड़े तो दोनों की समीक्षा करें। किसी को नया लॉग फ़ील्ड तब तक नहीं दिखता जब तक वह एक साल वहाँ न रह जाए।
दावा लिखें, फिर वे अवलोकन जो बचे रहते हैं
गोपनीयता का दावा एक वाक्य में उसकी मान्यताओं के साथ लिखें: कौन-सा पक्ष किन संदर्भों को जोड़ने में असमर्थ होना चाहिए, और क्या होता है अगर जारीकर्ता और गेटवे अपने नोट्स मिलाएँ। जो डिज़ाइन उस वाक्य से बच निकलता है वह समीक्षा योग्य है; जिसे केवल «शून्य ज्ञान» कहा जाए वह नहीं।
फिर सूची बनाएँ कि क्या हर हाल में दिखता रहता है। स्रोत पते, कनेक्शन के समय, पैकेट के आकार और यह सीधा तथ्य कि कोई खरीद उस अकेले नए कनेक्शन के दिखने से थोड़ा पहले हुई थी, सब क्रिप्टोग्राफ़ी से बाहर हैं। एक ही ग्राहक जो एक इकाई खरीदे और एक बार जुड़े, केवल समय के आधार पर जोड़ा जा सकता है, और कोई टोकन डिज़ाइन इसे नहीं बदलता।
ईमानदार नतीजा खाते और उपयोग के बीच एक संकरा लिंक है, अदृश्य सत्र नहीं। इसे बनाना अब भी सार्थक है, बशर्ते दस्तावेज़ यही कहें और परिचालन रिकॉर्ड दावे से मेल खाएँ।