बोगद्यासाठी पैसे देणे म्हणजे प्रत्येक कनेक्शनवर बिलिंग ओळख दाखवणे असे मात्र नाही. एक रचना पात्रता एकदा तपासू शकते, ग्राहकाला क्रिप्टोग्राफिक टोकन देऊ शकते आणि नंतर गेटवेला मागील खाते न पाहता टोकन स्वीकारू देऊ शकते. हे खरोखर काही लपवते का हे निर्गमन आणि विमोचनाच्या निर्णयांवर अवलंबून आहे, म्हणून हे सुरू करायचे वैशिष्ट्य नाही, तर चार भागांचा तपशीलवार सराव माना.

खरेदीची पायरी सत्राच्या पायरीपासून वेगळी करा

RFC 9576 मधील Privacy Pass आर्किटेक्चर शब्दसंग्रह देते: क्लायंट, प्रमाणक, निर्गमक आणि उगम. क्लायंट निर्गमकाला एखादा गुण सिद्ध करतो आणि टोकन घेतो; नंतर एक टोकन उगमासमोर सादर करतो, जो सेवा द्यायची की नाही हे ठरवतो. VPN वर लागू केल्यास प्रमाणित गुण हा प्रवेशाचा एक घटक असू शकतो.

बिलिंगला अजूनही त्याच्या प्रक्रियेला आवश्यक ते दिसते आणि कोणीही उलटा दावा करत नाही. अरुंद उद्दिष्ट म्हणजे नंतरचे विमोचन टोकन निर्माण करणाऱ्या खरेदीशी जोडता येऊ नये. हा ठोस, तपासण्यायोग्य गुण आहे आणि तोच लिहून ठेवण्यासारखा आहे.

यादृच्छिक दिसणारी वाहक शृंखला ते देत नाही. निर्गमक मूल्य ग्राहक नोंदीजवळ ठेवतो आणि गेटवे ती जुळणी मागू शकतो, तर दोन्ही परस्परक्रिया क्रिप्टोग्राफीने नव्हे तर डेटाबेसने जोडल्या जातात. रचनेने निर्गमकाला त्या प्रश्नाचे उत्तर देण्यास असमर्थ करावे आणि उपयोजनाने निर्गमक व गेटवे यांना त्यांच्या दृष्टिकोन एकत्र करण्यापासून रोखावे.

एक टोकन कशाला अधिकृत करते ते ठरवा

«एक टोकन प्रवेश विकत घेते» याचे कार्यान्वयनाच्या पातळीवर जवळजवळ काहीही उत्तर मिळत नाही. एकक एक कनेक्शन आहे, वेळेचा वाटा, की आकारमान? प्रतिसाद गमावलेला क्लायंट तोच अनुदान पुढे ठेवू शकतो का? नेटवर्क बदलताना उपकरण पुन्हा जोडले तर काय होते? ही उत्तरे रचना वापरण्यायोग्य आहे की नाही हे ठरवतात आणि प्रत्येकाचा गोपनीयतेवर परिणाम असतो.

Reuse ruleWhat it buysWhat it leaks
Single use per connectionStrongest unlinkability between sessionsFrequent reissuance, more purchase-to-use timing pairs
Bounded time windowFewer tokens, reconnects workActivity inside the window is linkable
Long-lived grantOperationally simpleBehaves like an account reference with extra steps

एक जाणूनबुजून निवडा आणि त्याशेजारी अपयशाचे वर्तन लिहा. वेळ संपल्यानंतर नवीन अधिकाराने पुन्हा प्रयत्न करणारा क्लायंट आणखी एक एकक खर्च करतो, जे एकाच वेळी बिलिंगचे आश्चर्य आणि गोपनीयतेचा संकेत आहे.

पुनर्वापर आणि रद्दीकरण धोरण लिहा

रद्दीकरण ही अशी जागा आहे जिथे अनामिक रचना सहसा स्वतःचे वचन मोडतात. सदस्यता रद्द करणे आणि आधीच निर्गमित टोकन अवैध करणे या वेगळ्या क्रिया आहेत, आणि ठरवण्यासाठी गुपचूप खाते शोध करणारा गेटवे त्या क्षणी अनामिक राहत नाही.

एकमेकांशी जुळणारी मुदत, निर्गमन मर्यादा आणि रद्दीकरणाची कथा निवडा. नंतर तुम्ही काढून टाकलेला दुवा पुन्हा आणणारी क्षेत्रे गेटवेच्या स्वतःच्या नोंदींमध्ये तपासा.

sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/

ती शोध टोकन किंवा खाते क्षेत्रे असलेल्या लॉग फाइलींची यादी करते आणि प्रत्यक्षात काळजीपूर्वक रचना पहिल्यांदा तिथेच गळते. टोकनचे मूल्य खाते ओळखकर्त्याजवळ साठवणारी सत्र नोंद संपूर्ण रचना नष्ट करते आणि ती सहसा कोणीही पुन्हा न पाहिलेल्या दोषमार्जन बदलामधून येते.

सत्र संपल्यानंतर गेटवे काय ठेवते हेही ठरवा. कालावधी, बाइट आणि टोक या क्रियांसाठी उपयुक्त आहेत आणि प्रत्येक निरीक्षकाला हवा असलेला कोड्याचा तुकडा आहे. धारण कालावधी लहान आणि क्षेत्रांची यादी लहान ठेवा, नंतर दोषमार्जन बदलाने स्तंभ जोडल्यावर दोन्ही पुन्हा तपासा. नवीन लॉग क्षेत्र वर्षभर राहिल्याशिवाय कोणाच्याही लक्षात येत नाही.

दावा मांडा, नंतर उरलेली निरीक्षणे

गोपनीयतेचा दावा त्याच्या गृहीतकांसह एका वाक्यात लिहा: कोणत्या पक्षाला कोणते संदर्भ जोडता येऊ नयेत आणि निर्गमक व गेटवे नोंदी तुलना केल्यास काय होते. ते वाक्य टिकून राहणारी रचना पुनरावलोकनयोग्य आहे; फक्त «शून्य ज्ञान» असे वर्णन केलेली नाही.

नंतर काय दिसत राहते त्याची यादी करा. स्रोत पत्ते, कनेक्शनच्या वेळा, पॅकेटचे आकार आणि एकमेव नवीन कनेक्शन दिसण्याच्या थोडे आधी खरेदी झाली ही साधी वस्तुस्थिती — सर्व क्रिप्टोग्राफीबाहेर आहेत. एक एकक खरेदी करून एकदा जोडणारा एकच ग्राहक केवळ वेळेनुसार जोडता येतो आणि कोणतीही टोकन रचना ते बदलत नाही.

प्रामाणिक निष्कर्ष अदृश्य सत्र नाही, तर खाते आणि वापर यांतील अरुंद दुवा आहे. कागदपत्रे तसे सांगत असतील आणि कार्यन्वयन नोंदी दाव्याशी जुळत असतील तर ते बांधणे अजूनही योग्य आहे.

संबंधित लेख