TLS 1.3ஐ அடிப்படையாகக் கொண்ட டொமைன் ஃபிரண்டிங்

அறிமுகம்

Cisco, BlueCoat, FireEye போன்ற புகழ்பெற்ற உற்பத்தியாளர்களின் நவீன கார்ப்பரேட் உள்ளடக்க வடிகட்டுதல் அமைப்புகள் அவற்றின் மிகவும் சக்திவாய்ந்த சகாக்களுடன் மிகவும் பொதுவானவை - DPI அமைப்புகள், அவை தேசிய அளவில் தீவிரமாக செயல்படுத்தப்படுகின்றன. இருவரின் பணியின் சாராம்சம் உள்வரும் மற்றும் வெளிச்செல்லும் இணைய போக்குவரத்தை ஆய்வு செய்து, கருப்பு/வெள்ளை பட்டியல்களின் அடிப்படையில், இணைய இணைப்பை தடை செய்ய முடிவெடுப்பதாகும். அவர்கள் இருவரும் தங்கள் வேலையின் அடிப்படைகளில் ஒரே மாதிரியான கொள்கைகளை நம்பியிருப்பதால், அவற்றைத் தவிர்ப்பதற்கான முறைகளும் பொதுவானதாக இருக்கும்.

DPI மற்றும் கார்ப்பரேட் அமைப்புகள் இரண்டையும் மிகவும் திறம்பட புறக்கணிக்க உங்களை அனுமதிக்கும் தொழில்நுட்பங்களில் ஒன்று டொமைன்-ஃப்ரண்டிங் தொழில்நுட்பமாகும். அதன் சாராம்சம் என்னவென்றால், நாம் தடுக்கப்பட்ட ஆதாரத்திற்குச் செல்கிறோம், மற்றொன்றின் பின்னால் ஒளிந்துகொள்கிறோம், ஒரு நல்ல நற்பெயரைக் கொண்ட பொது டொமைன், இது வெளிப்படையாக எந்த அமைப்பாலும் தடுக்கப்படாது, எடுத்துக்காட்டாக google.com.

இந்த தொழில்நுட்பத்தைப் பற்றி ஏற்கனவே நிறைய கட்டுரைகள் எழுதப்பட்டுள்ளன மற்றும் பல எடுத்துக்காட்டுகள் கொடுக்கப்பட்டுள்ளன. இருப்பினும், பிரபலமான மற்றும் சமீபத்தில் விவாதிக்கப்பட்ட DNS-ஓவர்-HTTPS மற்றும் மறைகுறியாக்கப்பட்ட-SNI தொழில்நுட்பங்கள், அத்துடன் TLS 1.3 நெறிமுறையின் புதிய பதிப்பு, டொமைன் ஃபிரண்டிங்கிற்கான மற்றொரு விருப்பத்தை பரிசீலிப்பதை சாத்தியமாக்குகிறது.

தொழில்நுட்பத்தைப் புரிந்துகொள்வது

முதலில், ஒரு சிறிய அடிப்படைக் கருத்துகளை வரையறுப்போம், இதன் மூலம் யார் யார், ஏன் இவை அனைத்தும் தேவை என்பதைப் பற்றிய புரிதல் அனைவருக்கும் இருக்கும். eSNI பொறிமுறையை நாங்கள் குறிப்பிட்டுள்ளோம், அதன் செயல்பாடு மேலும் விவாதிக்கப்படும். eSNI (மறைகுறியாக்கப்பட்ட சேவையக பெயர் அறிகுறி) பொறிமுறையானது SNI இன் பாதுகாப்பான பதிப்பாகும், இது TLS 1.3 நெறிமுறைக்கு மட்டுமே கிடைக்கிறது. கோரிக்கை எந்த டொமைனுக்கு அனுப்பப்படுகிறது என்பது பற்றிய தகவல்களை குறியாக்கம் செய்வதே முக்கிய யோசனை.

இப்போது eSNI பொறிமுறையானது நடைமுறையில் எவ்வாறு செயல்படுகிறது என்பதைப் பார்ப்போம்.

நவீன டிபிஐ தீர்வால் தடுக்கப்பட்ட இணைய ஆதாரம் எங்களிடம் உள்ளது என்று வைத்துக்கொள்வோம் (உதாரணமாக, பிரபலமான டொரண்ட் டிராக்கர் rutracker.nl ஐ எடுத்துக்கொள்வோம்). டொரண்ட் டிராக்கரின் இணையதளத்தை அணுக முயலும்போது, ​​ஆதாரம் தடுக்கப்பட்டிருப்பதைக் குறிக்கும் வழங்குநரின் நிலையான ஸ்டப்பைக் காண்கிறோம்:

RKN இணையதளத்தில் இந்த டொமைன் உண்மையில் நிறுத்தப்பட்டியலில் பட்டியலிடப்பட்டுள்ளது:

நீங்கள் whois ஐ வினவும்போது, ​​கிளவுட் வழங்குநரான Cloudflare க்கு பின்னால் டொமைன் "மறைக்கப்பட்டிருப்பதை" நீங்கள் காணலாம்.

ஆனால் RKN இன் "நிபுணர்கள்" போலல்லாமல், Beeline (அல்லது எங்கள் பிரபலமான கட்டுப்பாட்டாளரின் கசப்பான அனுபவத்தால் கற்பிக்கப்பட்ட) தொழில்நுட்ப ரீதியாக ஆர்வமுள்ள ஊழியர்கள் ஐபி முகவரி மூலம் தளத்தை முட்டாள்தனமாக தடை செய்யவில்லை, ஆனால் நிறுத்தப்பட்டியலில் டொமைன் பெயரைச் சேர்த்தனர். அதே ஐபி முகவரிக்குப் பின்னால் வேறு என்ன டொமைன்கள் மறைக்கப்பட்டுள்ளன என்பதைப் பார்த்தால், அவற்றில் ஒன்றைப் பார்வையிட்டு, அணுகல் தடுக்கப்படவில்லை என்பதை நீங்கள் பார்த்தால், இதை எளிதாகச் சரிபார்க்கலாம்:

இது எப்படி நடக்கிறது? எல்லா தகவல்தொடர்புகளும் https நெறிமுறையின் மூலம் நிகழும், மேலும் Beeline இலிருந்து https சான்றிதழ்களை மாற்றியமைப்பதை நாங்கள் இன்னும் கவனிக்காததால், எனது உலாவி எந்த டொமைனில் உள்ளது என்பதை வழங்குநரின் DPI எவ்வாறு அறிவது? அவர் தெளிவானவரா அல்லது நான் பின்பற்றப்படுகிறாரா?

வயர்ஷார்க் மூலம் போக்குவரத்தைப் பார்த்து இந்த கேள்விக்கு பதிலளிக்க முயற்சிப்போம்

ஸ்கிரீன்ஷாட், முதலில் உலாவி DNS வழியாக சேவையகத்தின் IP முகவரியைப் பெறுகிறது, பின்னர் ஒரு நிலையான TCP ஹேண்ட்ஷேக் இலக்கு சேவையகத்துடன் நிகழ்கிறது, பின்னர் உலாவி சேவையகத்துடன் SSL இணைப்பை நிறுவ முயற்சிக்கிறது. இதைச் செய்ய, இது ஒரு SSL கிளையண்ட் ஹலோ பாக்கெட்டை அனுப்புகிறது, அதில் மூல டொமைனின் பெயர் தெளிவான உரையில் உள்ளது. இணைப்பைச் சரியாக வழிநடத்துவதற்கு, கிளவுட்ஃப்ளேர் ஃப்ரண்ட்எண்ட் சேவையகத்திற்கு இந்தப் புலம் தேவைப்படுகிறது. வழங்குநர் DPI எங்களைப் பிடித்து, எங்கள் இணைப்பை உடைக்கும் இடம் இது. அதே நேரத்தில், வழங்குநரிடமிருந்து நாங்கள் எந்த ஸ்டப்களையும் பெறவில்லை, மேலும் தளம் முடக்கப்பட்டது அல்லது வேலை செய்யாதது போன்ற நிலையான உலாவி பிழையைப் பார்க்கிறோம்:

இப்போது உலாவியில் eSNI பொறிமுறையை இயக்குவோம், அதற்கான வழிமுறைகளில் எழுதப்பட்டுள்ளது Firefox :
இதைச் செய்ய, பயர்பாக்ஸ் உள்ளமைவு பக்கத்தைத் திறக்கிறோம் பற்றி: கட்டமைப்பு மற்றும் பின்வரும் அமைப்புகளை செயல்படுத்தவும்:

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 நெறிமுறை வழியாக இணைக்க curl நிலையான openssl நூலகத்தைப் பயன்படுத்துவதால், முதலில் நாம் அங்கு eSNI ஆதரவை வழங்க வேண்டும். openssl மாஸ்டர் கிளைகளில் இதுவரை eSNI ஆதரவு இல்லை, எனவே நாம் ஒரு சிறப்பு openssl கிளையை பதிவிறக்கம் செய்து, அதை தொகுத்து நிறுவ வேண்டும்.

கிட்ஹப்பில் இருந்து களஞ்சியத்தை குளோன் செய்து வழக்கம் போல் தொகுக்கிறோம்:

$ 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

தொகுப்பை வெற்றிகரமாக உருவாக்கிய பிறகு, curl ஐ உள்ளமைக்கவும் இயக்கவும் openssl இலிருந்து ஒரு சிறப்பு பாஷ் கோப்பைப் பயன்படுத்துவோம். வசதிக்காக அதை கர்ல் மூலம் கோப்பகத்தில் நகலெடுக்கலாம்:

cp /opt/openssl/esnistuff/curl-esni 

வயர்ஷார்க்கில் DNS மற்றும் TLS பாக்கெட்டுகளை ஒரே நேரத்தில் பதிவு செய்யும் போது, ​​cloudflare சேவையகத்திற்கு சோதனை https கோரிக்கையை உருவாக்கவும்.

$ 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 க்கு ஒரு TXT DNS கோரிக்கை (தொகுப்பு எண். 13). பின்னர், openssl நூலகத்தைப் பயன்படுத்தி, Curl ஒரு TLS 1.3 கோரிக்கையை கிளவுட்ஃப்ளேர் சேவையகத்திற்கு அனுப்பியது, அதில் SNI புலமானது முந்தைய படியில் (packet #22) பெறப்பட்ட பொது விசையுடன் குறியாக்கம் செய்யப்பட்டது. ஆனால், eSNI புலத்துடன் கூடுதலாக, SSL-ஹலோ பாக்கெட்டில் வழக்கமான - திறந்த SNI உடன் ஒரு புலம் உள்ளது, அதை நாம் எந்த வரிசையிலும் குறிப்பிடலாம் (இந்த விஷயத்தில் - www.hello-rkn.ru).

கிளவுட்ஃப்ளேர் சேவையகங்களால் செயலாக்கப்படும் போது இந்த திறந்த SNI புலம் எந்த வகையிலும் கணக்கில் எடுத்துக்கொள்ளப்படவில்லை மற்றும் வழங்குநர் DPIக்கான முகமூடியாக மட்டுமே செயல்பட்டது. கிளவுட்ஃப்ளேர் சேவையகம் எங்கள் ssl-hello பாக்கெட்டைப் பெற்று, eSNI ஐ மறைகுறியாக்கி, அங்கிருந்து அசல் SNI ஐ பிரித்தெடுத்து, எதுவும் நடக்காதது போல் செயலாக்கியது (eSNI ஐ உருவாக்கும் போது அது திட்டமிட்டபடி அனைத்தையும் செய்தது).

DPI பார்வையில் இந்த வழக்கில் பிடிக்கக்கூடிய ஒரே விஷயம் _esni.cloudflare.com க்கான முதன்மை DNS கோரிக்கையாகும். ஆனால் இந்த பொறிமுறையானது உள்ளே இருந்து எவ்வாறு செயல்படுகிறது என்பதைக் காண்பிப்பதற்காக மட்டுமே DNS கோரிக்கையை திறந்துள்ளோம்.

இறுதியாக DPI இன் கீழ் இருந்து விரிப்பை வெளியே இழுக்க, ஏற்கனவே குறிப்பிட்டுள்ள DNS-over-HTTPS பொறிமுறையைப் பயன்படுத்துகிறோம். ஒரு சிறிய விளக்கம் - DOH என்பது HTTPS மூலம் DNS கோரிக்கையை அனுப்புவதன் மூலம், மனித-இன்-தி-மிடில் தாக்குதலில் இருந்து உங்களைப் பாதுகாக்க அனுமதிக்கும் ஒரு நெறிமுறை.

கோரிக்கையை மீண்டும் செயல்படுத்துவோம், ஆனால் இந்த முறை பொது eSNI விசைகளை https நெறிமுறை வழியாகப் பெறுவோம், 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 புரோட்டோகால் (https இணைப்பு 104.16.249.249) வழியாக அணுகுவதைக் காணலாம், அவர்களிடமிருந்து 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 சேவையகத்திற்குத் திரும்பினோம் (இங்கே எழுத்துப் பிழை எதுவும் இல்லை, இப்போது பிரபலமான நிறுவனம் அதன் சொந்த முதல்-நிலை டொமைனைக் கொண்டுள்ளது) மற்றும் மற்றொரு டொமைனைக் கொண்டு நம்மை மூடிக்கொண்டோம். மரணத்தின் வலியின் கீழ் அனைத்து DPI களுக்கும் தடை விதிக்கப்பட்டுள்ளது. பெறப்பட்ட பதிலின் அடிப்படையில், எங்கள் கோரிக்கை வெற்றிகரமாக செயல்படுத்தப்பட்டது என்பதை நீங்கள் புரிந்து கொள்ளலாம்.

வழங்குநரின் 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