होस्ट-जागरूक HTTP प्रॉक्सी टनल प्रकार के लिए प्रस्ताव
यह एक नया HTTP प्रॉक्सी टनल प्रकार पेश करके पारंपरिक HTTP-over-I2P उपयोग में “साझा पहचान समस्या” को हल करने के लिए एक प्रस्ताव है। इस टनल प्रकार में अतिरिक्त व्यवहार होता है जिसका उद्देश्य संभावित दुर्भावनापूर्ण छिपे हुए सेवा संचालकों द्वारा लक्षित उपयोगकर्ता-एजेंट (ब्राउज़र) और I2P क्लाइंट एप्लिकेशन के खिलाफ किए गए ट्रैकिंग की उपयोगिता को रोकना या सीमित करना है।
“साझा पहचान” समस्या क्या है?
“साझा पहचान” समस्या तब होती है जब क्रिप्टोग्राफ़िक रूप से पते वाले ओवरले नेटवर्क पर एक उपयोगकर्ता-एजेंट दूसरे उपयोगकर्ता-एजेंट के साथ क्रिप्टोग्राफ़िक पहचान साझा करता है। उदाहरण के लिए, जब एक Firefox और GNU Wget दोनों को एक ही HTTP प्रॉक्सी का उपयोग करने के लिए कॉन्फ़िगर किया जाता है, तो ऐसा होता है।
इस परिदृश्य में, सर्वर गतिविधि का जवाब देने के लिए उपयोग किए गए क्रिप्टोग्राफ़िक पते (Destination) को एकत्र करने और संग्रहीत करने में सक्षम होता है। यह इसे एक “फिंगरप्रिंट” के रूप में मान सकता है जो हमेशा 100% अद्वितीय होता है, क्योंकि यह क्रिप्टोग्राफ़िक मूल का होता है। इसका अर्थ है कि साझा पहचान समस्या द्वारा देखी गई लिंकेबिलिटी पूर्ण होती है।
लेकिन क्या यह एक समस्या है? ^^^^^^^^^^^^^^^^^^^^
साझा पहचान समस्या तब एक समस्या होती है जब उपयोगकर्ता-एजेंट जो एक ही प्रोटोकॉल बोलते हैं, अलग-अलग पहचान चाहते हैं। इसे पहली बार HTTP के संदर्भ में इस Reddit थ्रेड में उल्लेख किया गया था । इसके हटाए गए टिप्पणियां pullpush.io के सौजन्य से उपलब्ध हैं। उस समय मैं सबसे सक्रिय प्रतिक्रियादाताओं में से एक था, और उस समय मुझे लगा कि यह मुद्दा छोटा था। पिछले 8 वर्षों में, स्थिति और मेरा इसके प्रति दृष्टिकोण बदल गया है, अब मुझे लगता है कि दुर्भावनापूर्ण डिस्टिनेशन सहसंबंध के खतरे में काफी वृद्धि होती है क्योंकि अधिक साइटें विशिष्ट उपयोगकर्ताओं को “प्रोफाइल” करने की स्थिति में होती हैं।
इस हमले की प्रवेश बाधा बहुत कम है। इसके लिए केवल इतना आवश्यक है कि एक छिपे हुए सेवा संचालक कई सेवाएं संचालित करे। समकालिक भ्रमणों (एक ही समय में कई साइटों पर जाना) पर हमलों के लिए, यही एकमात्र आवश्यकता है। गैर-समकालिक लिंकिंग के लिए, उनमें से एक सेवा ऐसी होनी चाहिए जो “खाते” होस्ट करे जो एक एकल उपयोगकर्ता के हों जिसे ट्रैकिंग के लिए लक्षित किया जा रहा है।
वर्तमान में, कोई भी सेवा संचालक जो उपयोगकर्ता खाते होस्ट करता है, साझा पहचान समस्या का उपयोग करके उन्हें अपने नियंत्रण में किसी भी साइट पर गतिविधि के साथ सहसंबंधित कर सकता है। मैस्टोडॉन, गिटलैब, या यहां तक कि साधारण फोरम भी तब तक हमलावर हो सकते हैं जब तक वे एक से अधिक सेवाएं संचालित करते हैं और उपयोगकर्ता के लिए प्रोफाइल बनाने में रुचि रखते हैं। इस निगरानी का उपयोग स्टॉकिंग, वित्तीय लाभ या खुफिया संबंधित कारणों के लिए किया जा सकता है। अभी दर्जनों प्रमुख संचालक हैं, जो इस हमले को अंजाम दे सकते हैं और इससे सार्थक डेटा प्राप्त कर सकते हैं। हम अभी उन पर भरोसा करते हैं कि वे ऐसा नहीं करेंगे, लेकिन ऐसे खिलाड़ी आसानी से उभर सकते हैं जिन्हें हमारी राय की परवाह नहीं है।
यह स्पष्ट वेब पर प्रोफाइल बनाने के एक काफी बुनियादी रूप से सीधे संबंधित है जहां संगठन अपनी साइट पर बातचीत को उनके नियंत्रण में नेटवर्क पर बातचीत के साथ सहसंबंधित कर सकते हैं। I2P पर, क्योंकि क्रिप्टोग्राफ़िक डिस्टिनेशन अद्वितीय है, यह तकनीक कभी-कभी भू-स्थानन की अतिरिक्त शक्ति के बिना भी और अधिक विश्वसनीय हो सकती है।
साझा पहचान का उपयोग उस उपयोगकर्ता के खिलाफ नहीं किया जा सकता जो I2P का उपयोग केवल भू-स्थानन को गुमनाम बनाने के लिए करता है। इसका उपयोग I2P के रूटिंग को तोड़ने के लिए भी नहीं किया जा सकता। यह केवल संदर्भात्मक पहचान प्रबंधन की एक समस्या है।
- साझा पहचान समस्या का उपयोग करके I2P उपयोगकर्ता का भू-स्थानन करना असंभव है।
- यदि सत्र समकालिक नहीं हैं, तो साझा पहचान समस्या का उपयोग करके I2P सत्रों को जोड़ना असंभव है।
हालांकि, ऐसी परिस्थितियों में जो शायद बहुत आम हैं, I2P उपयोगकर्ता की गोपनीयता को कम करने के लिए इसका उपयोग करना संभव है। उनमें से एक कारण यह है कि हम फायरफॉक्स के उपयोग को प्रोत्साहित करते हैं, एक वेब ब्राउज़र जो “टैब” संचालन का समर्थन करता है।
- तीसरे पक्ष के संसाधनों के अनुरोध का समर्थन करने वाले किसी भी वेब ब्राउज़र में साझा पहचान समस्या से फिंगरप्रिंट उत्पन्न करना हमेशा संभव होता है।
- साझा पहचान समस्या के खिलाफ जावास्क्रिप्ट को अक्षम करने से कुछ भी प्रभाव नहीं पड़ता।
- यदि गैर-समकालिक सत्रों के बीच एक लिंक स्थापित किया जा सकता है, जैसे “पारंपरिक” ब्राउज़र फिंगरप्रिंटिंग द्वारा, तो साझा पहचान को संक्रमित रूप से लागू किया जा सकता है, जिससे गैर-समकालिक लिंकिंग रणनीति संभव हो सकती है।
- यदि स्पष्ट नेट गतिविधि और I2P पहचान के बीच एक लिंक स्थापित किया जा सकता है, उदाहरण के लिए, यदि लक्ष्य एक साइट पर दोनों तरफ I2P और स्पष्ट नेट उपस्थिति के साथ लॉग इन है, तो साझा पहचान को संक्रमित रूप से लागू किया जा सकता है, जिससे पूर्ण डी-एनोनिमाइज़ेशन संभव हो सकता है।
साझा पहचान समस्या की गंभीरता को आप कैसे देखते हैं जो I2P HTTP प्रॉक्सी पर लागू होती है, यह इस बात पर निर्भर करता है कि आप (या अधिक सटीक बिंदु पर, एक “उपयोगकर्ता” जिसकी अज्ञानतापूर्ण अपेक्षाएं हो सकती हैं) के अनुसार एप्लिकेशन के लिए “संदर्भात्मक पहचान” कहां स्थित है। कई संभावनाएं हैं:
- HTTP एप्लिकेशन और संदर्भात्मक पहचान दोनों है - यह वर्तमान में जैसे काम करता है। सभी HTTP एप्लिकेशन एक पहचान साझा करते हैं।
- प्रक्रिया एप्लिकेशन है और संदर्भात्मक पहचान है - यह तब काम करता है जब एक एप्लिकेशन SAMv3 या I2CP जैसे API का उपयोग करता है, जहां एक एप्लिकेशन अपनी पहचान बनाता है और अपने जीवनकाल को नियंत्रित करता है।
- HTTP एप्लिकेशन है, लेकिन होस्ट संदर्भात्मक पहचान है - यह इस प्रस्ताव का उद्देश्य है, जो प्रत्येक होस्ट को एक संभावित “वेब एप्लिकेशन” के रूप में मानता है और खतरे के सतह को इस तरह से मानता है।
क्या इसे हल किया जा सकता है? ^^^^^^^^^^^^^^^
शायद ऐसा प्रॉक्सी बनाना संभव नहीं है जो बुद्धिमानी से प्रतिक्रिया दे सके हर संभावित मामले में जहां इसका संचालन एक एप्लिकेशन की गोपनीयता को कमजोर कर सकता है। हालांकि, एक एप्लिकेशन के लिए बुद्धिमानी से प्रतिक्रिया करने वाला प्रॉक्सी बनाना संभव है जो एक भविष्यवाणी योग्य तरीके से व्यवहार करता है। उदाहरण के लिए, आधुनिक वेब ब्राउज़र में, यह अपेक्षित है कि उपयोगकर्ता के पास कई टैब खुले होंगे, जहां वे कई वेब साइटों के साथ बातचीत करेंगे, जिन्हें होस्टनाम द्वारा अलग किया जाएगा।
इससे हम इस प्रकार के HTTP उपयोगकर्ता-एजेंट के लिए HTTP प्रॉक्सी के व्यवहार में सुधार कर सकते हैं कि प्रॉक्सी के व्यवहार को उपयोगकर्ता-एजेंट के व्यवहार के साथ मिलाएं, जहां प्रत्येक होस्ट को HTTP प्रॉक्सी के साथ उपयोग करते समय अपना डिस्टिनेशन दिया जाए। यह परिवर्तन साझा पहचान समस्या का उपयोग करके फिंगरप्रिंट प्राप्त करना असंभव बना देता है जिसका उपयोग ग्राहक गतिविधि को 2 होस्ट के साथ सहसंबंधित करने के लिए किया जा सकता है, क्योंकि 2 होस्ट अब वापसी पहचान साझा नहीं करेंगे।
विवरण: ^^^^^^^^^^^^
एक नया HTTP प्रॉक्सी छिपे सेवा प्रबंधक (I2PTunnel) में बनाया जाएगा और जोड़ा जाएगा। नया HTTP प्रॉक्सी I2PSocketManagers के एक “मल्टीप्लेक्सर” के रूप में काम करेगा। मल्टीप्लेक्सर का स्वयं कोई डिस्टिनेशन नहीं होता। मल्टीप्लेक्स में शामिल होने वाले प्रत्येक व्यक्तिगत I2PSocketManager का अपना स्थानीय डिस्टिनेशन होता है, और अपना टनल पूल होता है। I2PSocketManagers को मल्टीप्लेक्सर द्वारा आवश्यकता के आधार पर बनाया जाता है, जहां “आवश्यकता” नए होस्ट पर पहली यात्रा होती है। मल्टीप्लेक्सर में डालने से पहले एक या अधिक को अग्रिम में बनाकर और उन्हें मल्टीप्लेक्सर के बाहर संग्रहीत करके I2PSocketManagers के निर्माण को अनुकूलित करना संभव है। इससे प्रदर्शन में सुधार हो सकता है।
एक अतिरिक्त I2PSocketManager, जिसका अपना डिस्टिनेशन होता है, किसी भी साइट के लिए एक “आउटप्रॉक्सी” के वाहक के रूप में स्थापित किया जाता है जिसका I2P डिस्टिनेशन नहीं होता है, उदाहरण के लिए कोई भी स्पष्ट नेट साइट। इससे प्रभावी रूप से सभी आउटप्रॉक्सी उपयोग एकल संदर्भात्मक पहचान बन जाता है, इस सावधानी के साथ कि टनल के लिए कई आउटप्रॉक्सी कॉन्फ़िगर करने से सामान्य “स्टिकी” आउटप्रॉक्सी रोटेशन होगा, जहां प्रत्येक आउटप्रॉक्सी को केवल एक साइट के लिए अनुरोध मिलते हैं। यह स्पष्ट इंटरनेट पर I2P प्रॉक्सी को डिस्टिनेशन द्वारा अलग करने के बराबर व्यवहार है।
संसाधन विचार: ’’’’’’’’’’’’’’’’’’’’’’''
नए HTTP प्रॉक्सी को मौजूदा HTTP प्रॉक्सी की तुलना में अतिरिक्त संसाधनों की आवश्यकता होती है। यह:
- संभावित रूप से अधिक टनल और I2PSocketManagers बनाएगा
- अधिक बार टनल बनाएगा
इनमें से प्रत्येक की आवश्यकता है:
- स्थानीय कंप्यूटिंग संसाधन
- सहकर्मियों से नेटवर्क संसाधन
सेटिंग्स: ’’’’’’’''
बढ़ी हुई संसाधन उपयोग के प्रभाव को न्यूनतम करने के लिए, प्रॉक्सी को यथासंभव कम से कम उपयोग करने के लिए कॉन्फ़िगर किया जाना चाहिए। मल्टीप्लेक्सर के हिस्से वाले प्रॉक्सी (मूल प्रॉक्सी नहीं) को इस प्रकार कॉन्फ़िगर किया जाना चाहिए:
- मल्टीप्लेक्स किए गए I2PSocketManagers अपने टनल पूल में 1 टनल इन, 1 टनल आउट बनाते हैं
- मल्टीप्लेक्स किए गए I2PSocketManagers डिफ़ॉल्ट रूप से 3 हॉप्स लेते हैं।
- 10 मिनट की निष्क्रियता के बाद सॉकेट बंद करें
- मल्टीप्लेक्सर द्वारा शुरू किए गए I2PSocketManagers मल्टीप्लेक्सर के जीवनकाल को साझा करते हैं। मल्टीप्लेक्स किए गए टनल को तब तक “नष्ट” नहीं किया जाता जब तक मूल मल्टीप्लेक्सर नष्ट नहीं हो जाता।
डायग्राम: ^^^^^^^^^
नीचे दिया गया डायग्राम HTTP प्रॉक्सी के वर्तमान संचालन को दर्शाता है, जो “क्या यह एक समस्या है” खंड के तहत “संभावना 1” के अनुरूप है। जैसा कि आप देख सकते हैं, HTTP प्रॉक्सी सीधे केवल एक डिस्टिनेशन का उपयोग करके I2P साइटों के साथ बातचीत करता है। इस परिदृश्य में, HTTP एप्लिकेशन और संदर्भात्मक पहचान दोनों है।
**वर्तमान स्थिति: HTTP एप्लिकेशन है, HTTP संदर्भात्मक पहचान है**
__-> Outproxy <-> i2pgit.org
/
Browser <-> HTTP Proxy(one Destination)<->I2PSocketManager <---> idk.i2p
\__-> translate.idk.i2p
\__-> git.idk.i2p
नीचे दिया गया डायग्राम होस्ट-जागरूक HTTP प्रॉक्सी के संचालन को दर्शाता है, जो “क्या यह एक समस्या है” खंड के तहत “संभावना 3” के अनुरूप है। इस परिदृश्य में, HTTP एप्लिकेशन है, लेकिन होस्ट संदर्भात्मक पहचान को परिभाषित करता है, जहां प्रत्येक I2P साइट एक अलग HTTP प्रॉक्सी के साथ बातचीत करती है जिसका प्रत्येक होस्ट के लिए अद्वितीय डिस्टिनेशन होता है। इससे कई साइटों के संचालकों को यह अलग करने से रोका जाता है कि जब एक ही व्यक्ति उनके द्वारा संचालित कई साइटों पर जाता है।
**परिवर्तन के बाद: HTTP एप्लिकेशन है, होस्ट संदर्भात्मक पहचान है**
__-> I2PSocketManager(Destination A - Outproxies Only) <--> i2pgit.org
/
Browser <-> HTTP Proxy Multiplexer(No Destination) <---> I2PSocketManager(Destination B) <--> idk.i2p
\__-> I2PSocketManager(Destination C) <--> translate.idk.i2p
\__-> I2PSocketManager(Destination C) <--> git.idk.i2p
स्थिति: ^^^^^^^
होस्ट-जागरूक प्रॉक्सी का एक कार्यात्मक जावा कार्यान्वयन जो इस प्रस्ताव के पुराने संस्करण के अनुरूप है, idk के फोर्क में शाखा: i2p.i2p.2.6.0-browser-proxy-post-keepalive के तहत उपलब्ध है। उद्धरण में लिंक। इसे छोटे खंडों में परिवर्तनों को तोड़ने के लिए भारी संशोधन के अधीन किया जा रहा है।
SAMv3 लाइब्रेरी का उपयोग करके गो में विभिन्न क्षमताओं के साथ कार्यान्वयन लिखे गए हैं, वे अन्य गो एप्लिकेशन में एम्बेड करने या go-i2p के लिए उपयोगी हो सकते हैं लेकिन जावा I2P के लिए अनुपयुक्त हैं। इसके अलावा, उनमें एन्क्रिप्टेड लीज़सेट्स के साथ इंटरैक्टिव रूप से काम करने का अच्छा समर्थन नहीं है।
परिशिष्ट: i2psocks
नए टनल प्रकार को लागू किए बिना या मौजूदा I2P कोड में बदलाव किए बिना अन्य प्रकार के क्लाइंट को अलग करने के लिए एक सरल एप्लिकेशन-उन्मुख दृष्टिकोण संभव है जो I2PTunnel मौजूदा उपकरणों को जोड़ता है जो पहले से ही गोपनीयता समुदाय में व्यापक रूप से उपलब्ध और परीक्षण किए गए हैं। हालांकि, यह दृष्टिकोण एक कठिन धारणा बनाता है जो HTTP के लिए सत्य नहीं है और कई अन्य प्रकार के संभावित I2P क्लाइंट के लिए भी सत्य नहीं है।
लगभग, निम्नलिखित स्क्रिप्ट एक एप्लिकेशन-जागरूक SOCKS5 प्रॉक्सी उत्पन्न करेगी और अंतर्निहित कमांड को सॉक्सिफाई करेगी:
#! /bin/sh
command_to_proxy="$@"
java -jar ~/i2p/lib/i2ptunnel.jar -wait -e 'sockstunnel 7695'
torsocks --port 7695 $command_to_proxy
परिशिष्ट: हमले का उदाहरण कार्यान्वयन
HTTP उपयोगकर्ता-एजेंट पर साझा पहचान हमले का एक उदाहरण कार्यान्वयन
कई वर्षों से मौजूद है। एक अतिरिक्त उदाहरण idk के prop166 रिपॉजिटरी
के simple-colluder उपनिर्देश में उपलब्ध है। ये उदाहरण जानबूझकर इस बात को दर्शाने के लिए डिज़ाइन किए गए हैं कि हमला काम करता है और एक वास्तविक हमले में बदलने के लिए संशोधन (हालांकि मामूली) की आवश्यकता होगी।