🥇टीएलएस 1.3 पर आधारित डोमेन फ़्रंटिंग

परिचय

सिस्को, ब्लूकोट, फायरआई जैसे प्रसिद्ध निर्माताओं के आधुनिक कॉर्पोरेट सामग्री फ़िल्टरिंग सिस्टम में उनके अधिक शक्तिशाली समकक्षों - डीपीआई सिस्टम के साथ काफी समानताएं हैं, जिन्हें राष्ट्रीय स्तर पर सक्रिय रूप से लागू किया जा रहा है। दोनों के काम का सार इनकमिंग और आउटगोइंग इंटरनेट ट्रैफ़िक का निरीक्षण करना और ब्लैक/व्हाइट सूचियों के आधार पर इंटरनेट कनेक्शन पर प्रतिबंध लगाने का निर्णय लेना है। और चूँकि वे दोनों अपने काम के मूल में समान सिद्धांतों पर भरोसा करते हैं, इसलिए उन्हें दरकिनार करने के तरीकों में भी बहुत कुछ समानता होगी।

उन प्रौद्योगिकियों में से एक जो आपको डीपीआई और कॉर्पोरेट सिस्टम दोनों को काफी प्रभावी ढंग से बायपास करने की अनुमति देती है, डोमेन-फ्रंटिंग तकनीक है। इसका सार यह है कि हम एक अवरुद्ध संसाधन पर जाते हैं, एक अच्छी प्रतिष्ठा वाले दूसरे सार्वजनिक डोमेन के पीछे छिपते हैं, जो स्पष्ट रूप से किसी भी सिस्टम द्वारा अवरुद्ध नहीं किया जाएगा, उदाहरण के लिए google.com।

इस तकनीक के बारे में पहले ही बहुत सारे लेख लिखे जा चुके हैं और कई उदाहरण दिए गए हैं। हालाँकि, लोकप्रिय और हाल ही में चर्चा में आई डीएनएस-ओवर-एचटीटीपीएस और एन्क्रिप्टेड-एसएनआई प्रौद्योगिकियां, साथ ही टीएलएस 1.3 प्रोटोकॉल का नया संस्करण, डोमेन फ्रंटिंग के लिए एक और विकल्प पर विचार करना संभव बनाता है।

प्रौद्योगिकी को समझना

सबसे पहले, आइए कुछ बुनियादी अवधारणाओं को परिभाषित करें ताकि हर किसी को यह समझ में आ जाए कि कौन है और यह सब क्यों आवश्यक है। हमने ईएसएनआई तंत्र का उल्लेख किया, जिसके संचालन पर आगे चर्चा की जाएगी। ईएसएनआई (एन्क्रिप्टेड सर्वर नेम इंडिकेशन) तंत्र एसएनआई का एक सुरक्षित संस्करण है, जो केवल टीएलएस 1.3 प्रोटोकॉल के लिए उपलब्ध है। मुख्य विचार अन्य बातों के अलावा, यह जानकारी एन्क्रिप्ट करना है कि अनुरोध किस डोमेन पर भेजा गया है।

अब आइए देखें कि ईएसएनआई तंत्र व्यवहार में कैसे काम करता है।

मान लीजिए कि हमारे पास एक इंटरनेट संसाधन है जो आधुनिक डीपीआई समाधान द्वारा अवरुद्ध है (उदाहरण के लिए, प्रसिद्ध टोरेंट ट्रैकर rutracker.nl को लें)। जब हम टोरेंट ट्रैकर की वेबसाइट तक पहुंचने का प्रयास करते हैं, तो हमें प्रदाता का मानक स्टब दिखाई देता है जो दर्शाता है कि संसाधन अवरुद्ध है:

आरकेएन वेबसाइट पर यह डोमेन वास्तव में स्टॉप सूचियों में सूचीबद्ध है:

जब आप whois से पूछते हैं, तो आप देख सकते हैं कि डोमेन स्वयं क्लाउड प्रदाता Cloudflare के पीछे "छिपा हुआ" है।

लेकिन आरकेएन के "विशेषज्ञों" के विपरीत, बीलाइन के अधिक तकनीकी रूप से समझदार कर्मचारियों (या हमारे प्रसिद्ध नियामक के कड़वे अनुभव से प्रशिक्षित) ने मूर्खतापूर्ण तरीके से आईपी पते द्वारा साइट पर प्रतिबंध नहीं लगाया, बल्कि डोमेन नाम को स्टॉप सूची में जोड़ दिया। आप इसे आसानी से सत्यापित कर सकते हैं यदि आप देखें कि समान आईपी पते के पीछे कौन से अन्य डोमेन छिपे हुए हैं, उनमें से किसी एक पर जाएं और देखें कि पहुंच अवरुद्ध नहीं है:

ये कैसे होता है? प्रदाता के DPI को कैसे पता चलता है कि मेरा ब्राउज़र किस डोमेन पर है, क्योंकि सभी संचार https प्रोटोकॉल के माध्यम से होते हैं, और हमने अभी तक Beeline से https प्रमाणपत्रों के प्रतिस्थापन पर ध्यान नहीं दिया है? क्या वह दिव्यदर्शी है या मेरा पीछा किया जा रहा है?

आइए वायरशार्क के माध्यम से यातायात को देखकर इस प्रश्न का उत्तर देने का प्रयास करें

स्क्रीनशॉट से पता चलता है कि पहले ब्राउज़र DNS के माध्यम से सर्वर का आईपी पता प्राप्त करता है, फिर गंतव्य सर्वर के साथ एक मानक टीसीपी हैंडशेक होता है, और फिर ब्राउज़र सर्वर के साथ एक एसएसएल कनेक्शन स्थापित करने का प्रयास करता है। ऐसा करने के लिए, यह एक एसएसएल क्लाइंट हैलो पैकेट भेजता है, जिसमें स्पष्ट पाठ में स्रोत डोमेन का नाम होता है। कनेक्शन को सही ढंग से रूट करने के लिए क्लाउडफ्लेयर फ्रंटएंड सर्वर को इस फ़ील्ड की आवश्यकता होती है। यहीं पर प्रदाता डीपीआई हमें पकड़ लेता है और हमारा कनेक्शन तोड़ देता है। उसी समय, हमें प्रदाता से कोई स्टब प्राप्त नहीं होता है, और हम मानक ब्राउज़र त्रुटि देखते हैं जैसे कि साइट अक्षम है या बस काम नहीं करती है:

आइए अब ब्राउज़र में eSNI तंत्र को सक्षम करें, जैसा कि निर्देशों में लिखा गया है Firefox :
ऐसा करने के लिए हम फ़ायरफ़ॉक्स कॉन्फ़िगरेशन पृष्ठ खोलते हैं के बारे में: विन्यास और निम्नलिखित सेटिंग्स सक्रिय करें:

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

इसके बाद हम जांचेंगे कि क्लाउडफ्लेयर वेबसाइट पर सेटिंग्स सही से काम कर रही हैं या नहीं। लिंक और आइए हमारे टोरेंट ट्रैकर के साथ इस ट्रिक को फिर से आज़माएँ।

वोइला. हमारा पसंदीदा ट्रैकर बिना किसी वीपीएन या प्रॉक्सी सर्वर के खुला। आइए अब वायरशार्क में ट्रैफिक डंप को देखें कि क्या हुआ।

इस बार, एसएसएल क्लाइंट हैलो पैकेज में स्पष्ट रूप से गंतव्य डोमेन शामिल नहीं है, बल्कि इसके बजाय, पैकेज में एक नया फ़ील्ड दिखाई दिया - एन्क्रिप्टेड_सर्वर_नाम - यह वह जगह है जहां rutracker.nl का मान निहित है, और केवल क्लाउडफ्लेयर फ्रंटएंड सर्वर ही इसे डिक्रिप्ट कर सकता है मैदान। और यदि ऐसा है, तो प्रदाता डीपीआई के पास हाथ धोने और ऐसे ट्रैफ़िक की अनुमति देने के अलावा कोई विकल्प नहीं है। एन्क्रिप्शन के साथ कोई अन्य विकल्प नहीं हैं.

इसलिए, हमने देखा कि ब्राउज़र में तकनीक कैसे काम करती है। आइए अब इसे और अधिक विशिष्ट और दिलचस्प चीज़ों पर लागू करने का प्रयास करें। और सबसे पहले, हम उसी कर्ल को टीएलएस 1.3 के साथ काम करने के लिए ईएसएनआई का उपयोग करना सिखाएंगे, और साथ ही हम देखेंगे कि ईएसएनआई-आधारित डोमेन फ़्रंटिंग स्वयं कैसे काम करता है।

ईएसएनआई के साथ डोमेन फ्रंटिंग

इस तथ्य के कारण कि कर्ल https प्रोटोकॉल के माध्यम से कनेक्ट करने के लिए मानक ओपनएसएल लाइब्रेरी का उपयोग करता है, सबसे पहले हमें वहां ईएसएनआई समर्थन प्रदान करने की आवश्यकता है। ओपनएसएल मास्टर शाखाओं में अभी तक कोई ईएसएनआई समर्थन नहीं है, इसलिए हमें एक विशेष ओपनएसएल शाखा डाउनलोड करने, इसे संकलित करने और स्थापित करने की आवश्यकता है।

हम GitHub से रिपॉजिटरी को क्लोन करते हैं और हमेशा की तरह संकलित करते हैं:

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

इसके बाद, हम रिपॉजिटरी को कर्ल के साथ क्लोन करते हैं और हमारी संकलित ओपनएसएल लाइब्रेरी का उपयोग करके इसके संकलन को कॉन्फ़िगर करते हैं:

$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni

$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug

यहां उन सभी निर्देशिकाओं को सही ढंग से निर्दिष्ट करना महत्वपूर्ण है जहां ओपनएसएल स्थित है (हमारे मामले में, यह /opt/openssl/ है) और सुनिश्चित करें कि कॉन्फ़िगरेशन प्रक्रिया त्रुटियों के बिना गुजरती है।

यदि कॉन्फ़िगरेशन सफल है, तो हम पंक्ति देखेंगे:

चेतावनी: ईएसएनआई ईएसएनआई सक्षम लेकिन प्रयोगात्मक के रूप में चिह्नित। सावधानी से प्रयोग करें!

$ make

पैकेज को सफलतापूर्वक बनाने के बाद, हम कर्ल को कॉन्फ़िगर करने और चलाने के लिए ओपनएसएल से एक विशेष बैश फ़ाइल का उपयोग करेंगे। आइए सुविधा के लिए इसे कर्ल के साथ निर्देशिका में कॉपी करें:

cp /opt/openssl/esnistuff/curl-esni

और क्लाउडफ़ेयर सर्वर पर एक परीक्षण https अनुरोध करें, साथ ही साथ वायरशार्क में DNS और TLS पैकेट रिकॉर्ड करें।

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

सर्वर प्रतिक्रिया में, ओपनएसएल और कर्ल से बहुत सारी डिबगिंग जानकारी के अलावा, हमें क्लाउडफ्लेयर से कोड 301 के साथ एक HTTP प्रतिक्रिया प्राप्त होगी।

HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/

जो इंगित करता है कि हमारा अनुरोध सफलतापूर्वक गंतव्य सर्वर तक पहुंचाया गया, सुना गया और संसाधित किया गया।

अब आइए वायरशार्क में ट्रैफिक डंप को देखें, यानी। प्रदाता डीपीआई ने इस मामले में क्या देखा।

यह देखा जा सकता है कि कर्ल ने सबसे पहले क्लाउडफ्लेयर सर्वर के लिए सार्वजनिक ईएसएनआई कुंजी के लिए डीएनएस सर्वर की ओर रुख किया - _esni.cloudflare.com (पैकेज नंबर 13) के लिए एक TXT DNS अनुरोध। फिर, ओपनएसएल लाइब्रेरी का उपयोग करते हुए, कर्ल ने क्लाउडफ्लेयर सर्वर पर एक टीएलएस 1.3 अनुरोध भेजा जिसमें एसएनआई फ़ील्ड को पिछले चरण (पैकेट #22) में प्राप्त सार्वजनिक कुंजी के साथ एन्क्रिप्ट किया गया था। लेकिन, ईएसएनआई फ़ील्ड के अलावा, एसएसएल-हैलो पैकेट में सामान्य - खुले एसएनआई के साथ एक फ़ील्ड भी शामिल है, जिसे हम किसी भी क्रम में निर्दिष्ट कर सकते हैं (इस मामले में - www.hello-rkn.ru).

क्लाउडफ्लेयर सर्वर द्वारा संसाधित करते समय इस खुले एसएनआई फ़ील्ड को किसी भी तरह से ध्यान में नहीं रखा गया था और केवल प्रदाता डीपीआई के लिए एक मुखौटा के रूप में कार्य किया गया था। क्लाउडफ्लेयर सर्वर ने हमारा एसएसएल-हैलो पैकेट प्राप्त किया, ईएसएनआई को डिक्रिप्ट किया, वहां से मूल एसएनआई निकाला और इसे संसाधित किया जैसे कि कुछ भी नहीं हुआ था (इसने ईएसएनआई विकसित करते समय योजना के अनुसार सब कुछ किया)।

इस मामले में डीपीआई के दृष्टिकोण से जो एकमात्र चीज पकड़ी जा सकती है, वह है _esni.cloudflare.com के लिए प्राथमिक DNS अनुरोध। लेकिन हमने DNS अनुरोध को केवल यह दिखाने के लिए खुला रखा कि यह तंत्र अंदर से कैसे काम करता है।

अंततः डीपीआई के नीचे से गलीचे को बाहर निकालने के लिए, हम पहले से उल्लिखित डीएनएस-ओवर-एचटीटीपीएस तंत्र का उपयोग करते हैं। थोड़ा स्पष्टीकरण - डीओएच एक प्रोटोकॉल है जो आपको एचटीटीपीएस पर डीएनएस अनुरोध भेजकर मैन-इन-द-मिडिल हमले से बचाने की अनुमति देता है।

आइए अनुरोध को फिर से निष्पादित करें, लेकिन इस बार हमें DNS नहीं, बल्कि https प्रोटोकॉल के माध्यम से सार्वजनिक eSNI कुंजियाँ प्राप्त होंगी:

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

अनुरोध ट्रैफ़िक डंप नीचे स्क्रीनशॉट में दिखाया गया है:

यह देखा जा सकता है कि कर्ल पहले DoH प्रोटोकॉल (सर्वर 104.16.249.249 से https कनेक्शन) के माध्यम से mozilla.cloudflare-dns.com सर्वर तक पहुंचता है ताकि उनसे SNI एन्क्रिप्शन के लिए सार्वजनिक कुंजी के मान प्राप्त किए जा सकें और फिर गंतव्य तक पहुंचा जा सके। सर्वर, डोमेन के पीछे छिपा हुआ www.hello-rkn.ru.

उपरोक्त DoH रिज़ॉल्वर mozilla.cloudflare-dns.com के अलावा, हम अन्य लोकप्रिय DoH सेवाओं का उपयोग कर सकते हैं, उदाहरण के लिए, प्रसिद्ध दुष्ट निगम से।
आइए निम्नलिखित क्वेरी चलाएँ:

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

और हमें उत्तर मिलता है:

< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH

इस मामले में, हमने DoH रिज़ॉल्वर dns.google का उपयोग करके अवरुद्ध rutracker.nl सर्वर की ओर रुख किया (यहां कोई टाइपो नहीं है, अब प्रसिद्ध निगम का अपना प्रथम-स्तरीय डोमेन है) और खुद को एक अन्य डोमेन के साथ कवर किया, जो सख्ती से है सभी डीपीआई के लिए मृत्यु के दर्द के तहत ब्लॉक करना निषिद्ध है। प्राप्त प्रतिक्रिया के आधार पर, आप समझ सकते हैं कि हमारा अनुरोध सफलतापूर्वक संसाधित किया गया था।

एक अतिरिक्त जांच के रूप में कि प्रदाता का डीपीआई खुले एसएनआई पर प्रतिक्रिया करता है, जिसे हम एक कवर के रूप में प्रसारित करते हैं, हम किसी अन्य निषिद्ध संसाधन की आड़ में rutracker.nl से अनुरोध कर सकते हैं, उदाहरण के लिए, एक और "अच्छा" टोरेंट ट्रैकर:

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

हमें सर्वर से कोई प्रतिक्रिया नहीं मिलेगी, क्योंकि... हमारा अनुरोध डीपीआई सिस्टम द्वारा अवरुद्ध कर दिया जाएगा।

पहले भाग का संक्षिप्त निष्कर्ष

इसलिए, हम ओपनएसएल और कर्ल का उपयोग करके ईएसएनआई की कार्यक्षमता को प्रदर्शित करने और ईएसएनआई के आधार पर डोमेन फ्रंटिंग के संचालन का परीक्षण करने में सक्षम थे। उसी तरह, हम अपने पसंदीदा टूल को अनुकूलित कर सकते हैं जो अन्य डोमेन की "आड में" काम करने के लिए ओपनएसएल लाइब्रेरी का उपयोग करते हैं। इसके बारे में अधिक जानकारी हमारे अगले लेखों में।

स्रोत: www.habr.com

टीएलएस 1.3 पर आधारित डोमेन फ़्रंटिंग

परिचय

प्रौद्योगिकी को समझना

ईएसएनआई के साथ डोमेन फ्रंटिंग

पहले भाग का संक्षिप्त निष्कर्ष

एक टिप्पणी जोड़ें उत्तर रद्द