परिचय
Cisco, BlueCoat, FireEye जस्ता प्रसिद्ध निर्माताहरूबाट आधुनिक कर्पोरेट सामग्री फिल्टरिङ प्रणालीहरू तिनीहरूका शक्तिशाली समकक्षहरू - DPI प्रणालीहरू, जुन राष्ट्रिय स्तरमा सक्रिय रूपमा लागू भइरहेका छन्। दुबैको कामको सार भनेको आगमन र बाहिर जाने इन्टरनेट ट्राफिकको निरीक्षण गर्नु र कालो/सेतो सूचीको आधारमा इन्टरनेट जडानमा प्रतिबन्ध लगाउने निर्णय गर्नु हो। र तिनीहरू दुवैले आफ्नो कामको आधारभूत कुराहरूमा समान सिद्धान्तहरूमा भर परेको हुनाले, तिनीहरूलाई रोक्ने तरिकाहरू पनि धेरै समान हुनेछन्।
DPI र कर्पोरेट प्रणालीहरू दुवैलाई प्रभावकारी रूपमा बाइपास गर्न अनुमति दिने प्रविधिहरू मध्ये एउटा डोमेन-फ्रन्टिङ प्रविधि हो। यसको सार यो हो कि हामी ब्लक गरिएको स्रोतमा जान्छौं, अर्को पछाडि लुकेर, राम्रो प्रतिष्ठाको साथ सार्वजनिक डोमेन, जुन स्पष्ट रूपमा कुनै पनि प्रणाली द्वारा अवरुद्ध हुनेछैन, उदाहरणका लागि google.com।
यस प्रविधिको बारेमा धेरै लेखहरू लेखिएका छन् र धेरै उदाहरणहरू दिइएका छन्। यद्यपि, लोकप्रिय र भर्खरै चर्चा गरिएको DNS-over-HTTPS र एन्क्रिप्टेड-SNI प्रविधिहरू, साथै TLS 1.3 प्रोटोकलको नयाँ संस्करणले डोमेन फ्रन्टिङको लागि अर्को विकल्प विचार गर्न सम्भव बनाउँछ।
प्रविधि बुझ्दै
पहिले, थोरै आधारभूत अवधारणाहरू परिभाषित गरौं ताकि सबैलाई को हो र किन यो सबै आवश्यक छ भन्ने कुरा बुझ्दछ। हामीले eSNI संयन्त्र उल्लेख गर्यौं, जसको सञ्चालन थप छलफल गरिनेछ। eSNI (इन्क्रिप्टेड सर्भर नेम इन्डिकेशन) मेकानिजम SNI को सुरक्षित संस्करण हो, TLS 1.3 प्रोटोकलको लागि मात्र उपलब्ध छ। मुख्य विचार इन्क्रिप्ट गर्नु हो, अन्य चीजहरू मध्ये, कुन डोमेनमा अनुरोध पठाइन्छ भन्ने बारे जानकारी।
अब हेरौं कसरी eSNI संयन्त्रले व्यवहारमा काम गर्छ।
मानौं हामीसँग इन्टरनेट स्रोत छ जुन आधुनिक DPI समाधान द्वारा अवरुद्ध छ (उदाहरणका लागि, प्रसिद्ध टोरेन्ट ट्र्याकर rutracker.nl लिनुहोस्)। जब हामी टोरेन्ट ट्र्याकरको वेबसाइटमा पहुँच गर्ने प्रयास गर्छौं, हामी प्रदायकको मानक स्टब देख्छौं कि स्रोत अवरुद्ध छ:
RKN वेबसाइटमा यो डोमेन वास्तवमा स्टप सूचीहरूमा सूचीबद्ध छ:
जब तपाइँ whois को प्रश्न गर्नुहुन्छ, तपाइँ देख्न सक्नुहुन्छ कि डोमेन आफै क्लाउड प्रदायक Cloudflare पछि "लुकेको" छ।
तर RKN का "विशेषज्ञहरू" को विपरीत, Beeline (वा हाम्रो प्रसिद्ध नियामकको तीतो अनुभवबाट सिकाइएको) का अधिक प्राविधिक रूपमा जानकार कर्मचारीहरूले IP ठेगानाद्वारा साइटलाई मूर्खतापूर्वक प्रतिबन्धित गरेनन्, तर डोमेन नामलाई स्टप सूचीमा थपे। यदि तपाइँ उही आईपी ठेगाना पछाडि लुकेका अन्य डोमेनहरू हेर्नुभयो भने, तपाइँ ती मध्ये एकमा जानुहोस् र पहुँच अवरुद्ध गरिएको छैन हेर्नुहोस् भने तपाइँ यसलाई सजिलै प्रमाणित गर्न सक्नुहुन्छ:
यो कसरी हुन्छ? प्रदायकको DPI लाई मेरो ब्राउजर कुन डोमेनमा छ भनेर कसरी थाहा हुन्छ, किनकि सबै सञ्चारहरू https प्रोटोकल मार्फत हुन्छ, र हामीले Beeline बाट https प्रमाणपत्रहरूको प्रतिस्थापनलाई अझै याद गरेका छैनौं? उहाँ दावेदार हुनुहुन्छ वा मलाई पछ्याइएको छ?
यस प्रश्नको उत्तर दिने प्रयास गरौं, वायरसर्क मार्फत ट्राफिक हेरेर
स्क्रिनसटले देखाउँछ कि पहिले ब्राउजरले DNS मार्फत सर्भरको IP ठेगाना प्राप्त गर्छ, त्यसपछि गन्तव्य सर्भरसँग मानक TCP ह्यान्डशेक हुन्छ, र त्यसपछि ब्राउजरले सर्भरसँग SSL जडान स्थापना गर्ने प्रयास गर्छ। यो गर्नको लागि, यसले SSL क्लाइन्ट हेलो प्याकेट पठाउँछ, जसमा स्पष्ट पाठमा स्रोत डोमेनको नाम समावेश हुन्छ। यो फिल्ड क्लाउडफ्लेयर फ्रन्टएन्ड सर्भरद्वारा जडानलाई सही तरिकाले रुट गर्न आवश्यक छ। यो जहाँ प्रदायक DPI ले हामीलाई समात्छ, हाम्रो जडान तोड्छ। एकै समयमा, हामीले प्रदायकबाट कुनै स्टब प्राप्त गर्दैनौं, र हामीले मानक ब्राउजर त्रुटि देख्छौं यदि साइट असक्षम गरिएको छ वा मात्र काम गर्दैन:
अब ब्राउजरमा eSNI मेकानिजम सक्षम गरौं, जसको लागि निर्देशनहरूमा लेखिएको छ :
यो गर्नको लागि हामी फायरफक्स कन्फिगरेसन पृष्ठ खोल्छौं बारेमा: कन्फिगर गर्नुहोस् र निम्न सेटिङहरू सक्रिय गर्नुहोस्:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
यस पछि, हामी क्लाउडफ्लेयर वेबसाइटमा सेटिङहरू सही रूपमा काम गरिरहेको छ भनेर जाँच गर्नेछौं। र हाम्रो टोरेन्ट ट्र्याकरसँग यो ट्रिक फेरि प्रयास गरौं।
भोइला। हाम्रो मनपर्ने ट्रयाकर कुनै पनि VPN वा प्रोक्सी सर्भर बिना खोलियो। अब के भयो हेर्न वायरशार्कमा ट्राफिक डम्प हेरौं।
यस पटक, ssl ग्राहक नमस्कार प्याकेजले स्पष्ट रूपमा गन्तव्य डोमेन समावेश गर्दैन, तर यसको सट्टा, प्याकेजमा एउटा नयाँ फिल्ड देखा पर्यो - encrypted_server_name - यो जहाँ rutracker.nl को मान समावेश छ, र केवल क्लाउडफ्लेयर फ्रन्टएन्ड सर्भरले यसलाई डिक्रिप्ट गर्न सक्छ। क्षेत्र। र यदि त्यसो हो भने, तब प्रदायक DPI सँग हात धुनु र यस्तो ट्राफिकलाई अनुमति दिनुको विकल्प छैन। एन्क्रिप्शनको साथ कुनै अन्य विकल्पहरू छैनन्।
त्यसोभए, हामीले ब्राउजरमा टेक्नोलोजीले कसरी काम गर्छ भनेर हेर्यौं। अब यसलाई थप विशिष्ट र रोचक कुराहरूमा लागू गर्ने प्रयास गरौं। र पहिले, हामी समान कर्ललाई TLS 1.3 सँग काम गर्न eSNI प्रयोग गर्न सिकाउनेछौं, र एकै समयमा हामी eSNI-आधारित डोमेन फ्रन्टिङ आफैले कसरी काम गर्छ भनेर देख्नेछौं।
eSNI सँग डोमेन फ्रन्टिङ
तथ्यको कारणले कि कर्लले https प्रोटोकल मार्फत जडान गर्न मानक openssl पुस्तकालय प्रयोग गर्दछ, सबै भन्दा पहिले हामीले त्यहाँ eSNI समर्थन प्रदान गर्न आवश्यक छ। Openssl मास्टर शाखाहरूमा अझै कुनै eSNI समर्थन छैन, त्यसैले हामीले एउटा विशेष openssl शाखा डाउनलोड गर्न, कम्पाइल र स्थापना गर्न आवश्यक छ।
हामी GitHub बाट भण्डार क्लोन गर्छौं र सामान्य रूपमा कम्पाइल गर्छौं:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
अर्को, हामी कर्लको साथ भण्डार क्लोन गर्छौं र हाम्रो कम्पाइल गरिएको openssl पुस्तकालय प्रयोग गरेर यसको संकलन कन्फिगर गर्छौं:
$ 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
यहाँ Openssl स्थित सबै डाइरेक्टरीहरू सही रूपमा निर्दिष्ट गर्न महत्त्वपूर्ण छ (हाम्रो अवस्थामा, यो /opt/openssl/ हो) र कन्फिगरेसन प्रक्रिया त्रुटिहरू बिना जान्छ भनेर सुनिश्चित गर्नुहोस्।
यदि कन्फिगरेसन सफल छ भने, हामी रेखा देख्नेछौं:
चेतावनी: esni ESNI सक्षम तर प्रयोगात्मक चिन्ह लगाइयो। सावधानीपूर्वक प्रयोग गर्नुहोस्!
$ makeप्याकेज सफलतापूर्वक निर्माण गरेपछि, हामी कन्फिगर गर्न र कर्ल चलाउन openssl बाट विशेष bash फाइल प्रयोग गर्नेछौं। सुविधाको लागि कर्लको साथ डाइरेक्टरीमा प्रतिलिपि गरौं:
cp /opt/openssl/esnistuff/curl-esni र क्लाउडफ्लेयर सर्भरमा परीक्षण https अनुरोध गर्नुहोस्, जबकि एकै साथ Wireshark मा DNS र TLS प्याकेटहरू रेकर्ड गर्दै।
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/सर्भर प्रतिक्रियामा, openssl र curl बाट धेरै डिबगिङ जानकारीको अतिरिक्त, हामीले क्लाउडफ्लेयरबाट कोड 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/
जसले हाम्रो अनुरोधलाई गन्तव्य सर्भरमा सफलतापूर्वक डेलिभर गरिएको, सुनेको र प्रशोधन गरिएको संकेत गर्छ।
अब वायरशार्कमा ट्राफिक डम्पलाई हेरौं, अर्थात्। यस मामला मा प्रदायक DPI के देख्यो।
यो देख्न सकिन्छ कि कर्लले क्लाउडफ्लेयर सर्भरको लागि सार्वजनिक eSNI कुञ्जीको लागि DNS सर्भरमा पहिलो पटक फर्कियो - _esni.cloudflare.com (प्याकेज नम्बर 13) मा TXT DNS अनुरोध। त्यसपछि, openssl पुस्तकालय प्रयोग गरेर, कर्लले क्लाउडफ्लेयर सर्भरमा TLS 1.3 अनुरोध पठायो जसमा SNI फिल्डलाई अघिल्लो चरण (प्याकेट #22) मा प्राप्त सार्वजनिक कुञ्जीसँग इन्क्रिप्ट गरिएको थियो। तर, eSNI क्षेत्रको अतिरिक्त, SSL-hello प्याकेटले सामान्य - खुला SNI सँग फिल्ड पनि समावेश गर्दछ, जुन हामीले कुनै पनि क्रममा निर्दिष्ट गर्न सक्छौं (यस अवस्थामा - ).
क्लाउडफ्लेयर सर्भरहरूद्वारा प्रशोधन गर्दा र प्रदायक DPI को लागि मास्कको रूपमा मात्र सेवा गर्दा यो खुला SNI क्षेत्रलाई कुनै पनि हिसाबले ध्यानमा राखिएको थिएन। क्लाउडफ्लेयर सर्भरले हाम्रो ssl-hello प्याकेट प्राप्त गर्यो, eSNI डिक्रिप्ट गर्यो, त्यहाँबाट मूल SNI निकाल्यो र यसलाई केही भएको थिएन जस्तो गरी प्रशोधन गर्यो (यसले eSNI विकास गर्दा योजना अनुसार सबै काम गर्यो)।
DPI बिन्दुबाट यस केसमा समात्न सकिने एक मात्र कुरा _esni.cloudflare.com मा प्राथमिक DNS अनुरोध हो। तर हामीले यो मेकानिजमले भित्रबाट कसरी काम गर्छ भनेर देखाउनको लागि मात्र DNS अनुरोध खुला गर्यौं।
अन्ततः DPI अन्तर्गत गलीचा बाहिर निकाल्न, हामी पहिले नै उल्लेख गरिएको DNS-over-HTTPS मेकानिजम प्रयोग गर्छौं। थोरै व्याख्या - DOH एक प्रोटोकल हो जसले तपाईंलाई HTTPS मा DNS अनुरोध पठाएर म्यान-इन-द-मिडल आक्रमणबाट जोगाउन अनुमति दिन्छ।
फेरि अनुरोध कार्यान्वयन गरौं, तर यस पटक हामी https प्रोटोकल मार्फत सार्वजनिक eSNI कुञ्जीहरू प्राप्त गर्नेछौं, DNS होइन:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/अनुरोध ट्राफिक डम्प तलको स्क्रिनसटमा देखाइएको छ:
यो देख्न सकिन्छ कि कर्लले पहिले Mozilla.cloudflare-dns.com सर्भर DoH प्रोटोकल मार्फत पहुँच गर्दछ (सर्भर 104.16.249.249 मा https जडान) तिनीहरूबाट SNI इन्क्रिप्शनका लागि सार्वजनिक कुञ्जीहरूको मानहरू प्राप्त गर्न, र त्यसपछि गन्तव्यमा। सर्भर, डोमेन पछाडि लुकेको .
माथिको 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 सर्भरमा फर्कियौं (यहाँ कुनै टाइपो छैन, अब प्रसिद्ध निगमको आफ्नै पहिलो-स्तर डोमेन छ) र आफूलाई अर्को डोमेनमा ढाक्यौं, जुन कडाईका साथ छ। सबै DPIs लाई मृत्युको पीडा अन्तर्गत ब्लक गर्न निषेध गरिएको छ। प्राप्त प्रतिक्रियाको आधारमा, तपाइँ बुझ्न सक्नुहुन्छ कि हाम्रो अनुरोध सफलतापूर्वक प्रशोधन गरिएको थियो।
प्रदायकको DPI ले खुला SNI लाई जवाफ दिन्छ भनेर थप जाँचको रूपमा, जुन हामीले कभरको रूपमा प्रसारण गर्छौं, हामी rutracker.nl लाई केही अन्य निषेधित स्रोतको आडमा अनुरोध गर्न सक्छौं, उदाहरणका लागि, अर्को "राम्रो" टोरेन्ट ट्र्याकर:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/हामीले सर्भरबाट प्रतिक्रिया प्राप्त गर्ने छैनौं, किनभने... हाम्रो अनुरोध DPI प्रणाली द्वारा अवरुद्ध हुनेछ।
पहिलो भागको छोटो निष्कर्ष
त्यसैले, हामीले openssl र curl प्रयोग गरेर eSNI को कार्यक्षमता प्रदर्शन गर्न र eSNI मा आधारित डोमेन फ्रन्टिङको सञ्चालन परीक्षण गर्न सक्षम भयौं। त्यसै गरी, हामी हाम्रो मनपर्ने उपकरणहरू अनुकूलन गर्न सक्छौं जुन अन्य डोमेनहरूको "आडमा" काम गर्न openssl पुस्तकालय प्रयोग गर्दछ। हाम्रो अर्को लेखहरूमा यस बारे थप विवरणहरू।
स्रोत: www.habr.com