प्रमाणीकृत पता हेल्पर्स

अवलोकन

यह प्रस्ताव पता हेल्पर URL में एक प्रमाणीकरण तंत्र जोड़ता है।

प्रेरणा

पता हेल्पर URL अंतर्निहित रूप से असुरक्षित होते हैं। कोई भी किसी लिंक में पता हेल्पर पैरामीटर डाल सकता है, यहां तक कि एक छवि के लिए भी कर सकता है, और “i2paddresshelper” URL पैरामीटर में किसी भी गंतव्य को डाल सकता है। उपयोगकर्ता के HTTP प्रॉक्सी कार्यान्वयन के आधार पर, यह होस्टनेम/गंतव्य मैपिंग, यदि वर्त्तमान में पता पुस्तक में नहीं है, इसे स्वीकार किया जा सकता है, उपयोगकर्ता द्वारा स्वीकार के लिए एक अंतराल के साथ या बिना।

डिज़ाइन

विश्वसनीय जंप सर्वर और पता पुस्तिका पंजीकरण सेवाएं प्रमाणीकरण पैरामीटर जोड़ने वाले नए पता हेल्पर लिंक प्रदान करेंगी। दो नए पैरामीटर एक बेस64 हस्ताक्षर और हस्ताक्षरित-द्वारा स्ट्रिंग होंगे।

ये सेवाएं एक सार्वजनिक कुंजी प्रमाणपत्र उत्पन्न करेंगी और प्रदान करेंगी। यह प्रमाणपत्र डाउनलोड और HTTP प्रॉक्सी सॉफ़्टवेयर में सम्मिलन के लिए उपलब्ध होगा। उपयोगकर्ता और सॉफ़्टवेयर डेवलपर्स इस प्रमाणपत्र को शामिल करके ऐसी सेवाओं पर विश्वास करने का निर्णय लेंगे।

एक पता हेल्पर लिंक का सामना करने पर, HTTP प्रॉक्सी अतिरिक्त प्रमाणीकरण पैरामीटरों की जांच करेगा, और हस्ताक्षर को सत्यापित करने का प्रयास करेगा। सफल सत्यापन पर, प्रॉक्सी पहले की तरह आगे बढ़ेगा, या तो नई प्रविष्टि को स्वीकार करके या उपयोगकर्ता को एक अंतराल दिखाकर। सत्यापन विफलता पर, प्रॉक्सी पता हेल्पर को अस्वीकार कर सकता है या उपयोगकर्ता को अतिरिक्त जानकारी दिखा सकता है।

यदि कोई प्रमाणीकरण पैरामीटर मौजूद नहीं हैं, तो HTTP प्रॉक्सी स्वीकार कर सकता है, अस्वीकृत कर सकता है, या उपयोगकर्ता को जानकारी प्रस्तुत कर सकता है।

जंप सेवाएं सामान्य रूप से विश्वसनीय होंगी, लेकिन एक अतिरिक्त प्रमाणीकरण चरण के साथ। अन्य साइटों पर पता हेल्पर लिंक को संशोधित करने की आवश्यकता होगी।

सुरक्षा प्रभाव

यह प्रस्ताव विश्वसनीय पंजीकरण/जंप सेवाओं से प्रमाणीकरण जोड़कर सुरक्षा बढ़ाता है।

विनिर्देश

टीबीडी।

दो नए पैरामीटर i2paddresshelpersig और i2paddresshelpersigner हो सकते हैं?

स्वीकृत हस्ताक्षर प्रकार टीबीडी। शायद RSA नहीं क्योंकि बेस64 हस्ताक्षर बहुत लंबे होंगे।

हस्ताक्षर एल्गोरिथ्म: टीबीडी। शायद सिर्फ hostname=b64dest (पंजीकरण प्रमाणीकरण के लिए प्रस्ताव 112 के समान)

संभवतः तीसरा नया पैरामीटर: HTTP प्रॉक्सी द्वारा अतिरिक्त सत्यापन के लिए पंजीकरण प्रमाणीकरण स्ट्रिंग (भाग “#” बाद में)। किसी भी “#” को स्ट्रिंग में “#” या “#” के रूप में एस्केप किया जाना होगा, या कुछ अन्य निर्दिष्ट (टीबीडी) URL-सुरक्षित अक्षर के साथ प्रतिस्थापित किया जाएगा।

प्रवास

पुराने HTTP प्रॉक्सी जो नए प्रमाणीकरण पैरामीटर को समर्थन नहीं देते, उन्हें अनदेखा कर देंगे, और वेब सर्वर को भेजेंगे, जो कि हानिरहित होना चाहिए।

नए HTTP प्रॉक्सी जो वैकल्पिक रूप से प्रमाणीकरण पैरामीटर का समर्थन करते हैं, नए प्रमाणीकरण पैरामीटर न रखने वाले पुराने पता हेल्पर लिंक के साथ ठीक काम करेंगे।

नए HTTP प्रॉक्सी जो प्रमाणीकरण पैरामीटर की आवश्यकता रखते हैं, नए प्रमाणीकरण पैरामीटर न रखने वाले पुराने पता हेल्पर लिंक की अनुमति नहीं देंगे।

एक प्रॉक्सी कार्यान्वयन की नीतियां एक प्रवास अवधि के दौरान विकसित हो सकती हैं।

मुद्दों

एक साइट मालिक अपने स्वयं की साइट के लिए पता हेल्पर उत्पन्न नहीं कर सकता, क्योंकि उसे एक विश्वसनीय जंप सर्वर से हस्ताक्षर की आवश्यकता होती है। उसे उस विश्वसनीय सर्वर पर इसे पंजीकृत करना होगा और उस सर्वर से प्रमाणीकरणयुक्त हेल्पर URL प्राप्त करना होगा। क्या साइट के लिए स्वयं-प्रमाणित पता हेल्पर URL उत्पन्न करने की कोई विधि है?

वैकल्पिक रूप से, प्रॉक्सी पता हेल्पर अनुरोध के लिए Referer की जांच कर सकता है। यदि Referer मौजूद है, b32 को शामिल करता है, और b32 हेल्पर के गंतव्य से मेल खाता है, तो इसे स्व-रेफरल के रूप में अनुमति दी जा सकती है। अन्यथा इसे 3rd-पार्टी अनुरोध माना जा सकता है, और अस्वीकृत किया जा सकता है।