Кіріспе
Cisco, BlueCoat, FireEye сияқты атақты өндірушілердің заманауи корпоративтік мазмұнды сүзгілеу жүйелері ұлттық деңгейде белсенді түрде енгізіліп жатқан олардың анағұрлым қуатты аналогтарымен - DPI жүйелерімен көп ұқсастықтарға ие. Екеуінің жұмысының мәні - кіріс және шығыс интернет-трафикті тексеру және қара/ақ тізімдер негізінде Интернетке қосылуға тыйым салу туралы шешім қабылдау. Және олардың екеуі де өз жұмысының негіздерінде ұқсас принциптерге сүйенетіндіктен, оларды айналып өту әдістері де көп ортақ болады.
DPI және корпоративтік жүйелерді тиімді айналып өтуге мүмкіндік беретін технологиялардың бірі - домендік технология. Оның мәні мынада: біз бұғатталған ресурсқа барамыз, жақсы беделі бар басқа қоғамдық доменге жасырынамыз, оны ешбір жүйе бұғаттамайтыны анық, мысалы google.com.
Бұл технология туралы көптеген мақалалар жазылған және көптеген мысалдар келтірілген. Дегенмен, танымал және жақында талқыланған DNS-over-HTTPS және шифрланған-SNI технологиялары, сондай-ақ TLS 1.3 хаттамасының жаңа нұсқасы доменді анықтаудың басқа нұсқасын қарастыруға мүмкіндік береді.
Технологияны түсіну
Алдымен, кімнің кім екенін және мұның бәрі не үшін қажет екенін түсінуі үшін кішкене негізгі ұғымдарды анықтайық. Біз eSNI механизмін атап өттік, оның жұмысы одан әрі талқыланады. eSNI (шифрланған сервер атауын көрсету) механизмі тек TLS 1.3 протоколы үшін қол жетімді SNI қауіпсіз нұсқасы болып табылады. Негізгі идея - сұраудың қай доменге жіберілетіні туралы ақпаратты шифрлау.
Енді eSNI механизмі іс жүзінде қалай жұмыс істейтінін қарастырайық.
Бізде заманауи DPI шешімімен бұғатталған интернет-ресурс бар делік (мысалы, әйгілі rutracker.nl торрент трекерін алайық). Торрент трекерінің веб-сайтына кіруге тырысқанда, ресурстың бұғатталғанын көрсететін провайдердің стандартты нотасын көреміз:
RKN веб-сайтында бұл домен шын мәнінде тоқтату тізімдерінде көрсетілген:
Whois сұраған кезде, доменнің өзі Cloudflare бұлттық провайдерінің артында «жасырын» тұрғанын көре аласыз.
Бірақ РКН-ның «мамандарынан» айырмашылығы, Beeline-дың техникалық жағынан аса сауатты қызметкерлері (немесе біздің атақты реттеушіміздің ащы тәжірибесінен сабақ алған) сайтқа IP мекенжайы бойынша ақымақтықпен тыйым салмай, домендік атауды тоқтату тізіміне қосты. Бір IP мекенжайының артында қандай басқа домендер жасырылғанын қарасаңыз, олардың біріне кіріп, кіруге тыйым салынбағанын көрсеңіз, мұны оңай тексеруге болады:
Бұл қалай болады? Провайдердің DPI браузері қай домен қосулы екенін қайдан біледі, өйткені барлық байланыс https протоколы арқылы жүреді және біз Beeline-дан https сертификаттарының ауыстырылғанын әлі байқамадық? Ол көріпкел бе, әлде мені аңдып жүр ме?
Wireshark арқылы трафикке қарап, бұл сұраққа жауап беруге тырысайық
Скриншотта алдымен браузер сервердің IP мекенжайын DNS арқылы алатынын, содан кейін тағайындалған сервермен стандартты TCP қол алысуы орын алатынын, содан кейін шолғыш сервермен SSL қосылымын орнатуға тырысатынын көрсетеді. Бұл әрекетті орындау үшін ол анық мәтінде бастапқы домен атауын қамтитын SSL Client Hello пакетін жібереді. Бұл өріс қосылымды дұрыс бағыттау үшін cloudflare серверіне қажет. Дәл осы жерде DPI провайдері байланысымызды үзіп, бізді ұстап алады. Сонымен қатар, біз провайдерден ешқандай түтік алмаймыз және веб-сайт өшірілген немесе жай жұмыс істемейтін сияқты стандартты шолғыш қатесін көреміз:
Енді нұсқаулықта жазылғандай браузерде eSNI механизмін қосайық :
Ол үшін Firefox конфигурациясының бетін ашамыз туралы: config және келесі параметрлерді іске қосыңыз:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Осыдан кейін біз cloudflare веб-сайтында параметрлердің дұрыс жұмыс істеп тұрғанын тексереміз. және торрент-трекерімізбен трюкті қайтадан қолданып көрейік.
Voila. Біздің сүйікті трекер VPN немесе прокси серверсіз ашылды. Енді не болғанын көру үшін Wireshark-тегі трафик қоқысына назар аударайық.
Бұл жолы ssl клиенттік hello бумасында тағайындалған домен анық емес, оның орнына бумада жаңа өріс пайда болды - encrypted_server_name - бұл жерде rutracker.nl мәні қамтылған және тек cloudflare алдыңғы сервері бұның шифрын аша алады. өріс. Ал егер солай болса, онда DPI провайдерінде қолын жуудан және мұндай трафикке рұқсат беруден басқа амал жоқ. Шифрлаудың басқа опциялары жоқ.
Сонымен, біз технологияның браузерде қалай жұмыс істейтінін қарастырдық. Енді оны неғұрлым нақты және қызықты нәрселерге қолдануға тырысайық. Біріншіден, біз сол бұйраны TLS 1.3-пен жұмыс істеу үшін eSNI пайдалануды үйретеміз және сонымен бірге eSNI негізіндегі домен фронтингінің өзі қалай жұмыс істейтінін көреміз.
eSNI арқылы доменді алдын ала қарау
Curl https протоколы арқылы қосылу үшін стандартты openssl кітапханасын пайдаланатынына байланысты, ең алдымен сол жерде eSNI қолдауын қамтамасыз ету керек. Openssl негізгі филиалдарында әлі eSNI қолдауы жоқ, сондықтан арнайы openssl тармағын жүктеп алып, оны құрастырып, орнатуымыз керек.
Біз GitHub репозиторийін клондап, әдеттегідей құрастырамыз:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Әрі қарай, репозиторийді curl көмегімен клондаймыз және компиляцияланған 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-тен арнайы bash файлын қолданамыз. Ыңғайлы болу үшін оны curl бар каталогқа көшірейік:
cp /opt/openssl/esnistuff/curl-esni және Wireshark жүйесінде DNS және TLS пакеттерін бір уақытта жазып алу кезінде cloudflare серверіне сынақ https сұрауын жасаңыз.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Сервер жауабында openssl және curl-дан көптеген жөндеу ақпаратына қоса, біз cloudflare-дан 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/
бұл біздің сұрауымыздың тағайындалған серверге сәтті жеткізілгенін, тыңдалғанын және өңделгенін көрсетеді.
Енді Wireshark-тегі трафик қоқысын қарастырайық, яғни. бұл жағдайда DPI провайдері не көрді.
Curl алдымен cloudflare серверіне арналған жалпыға қолжетімді eSNI кілті үшін DNS серверіне бұрылғанын көруге болады - TXT DNS сұрауы _esni.cloudflare.com (пакет № 13). Содан кейін openssl кітапханасын пайдаланып curl TLS 1.3 сұрауын cloudflare серверіне жіберді, онда SNI өрісі алдыңғы қадамда алынған ашық кілтпен шифрланған (№22 пакет). Бірақ, eSNI өрісінен басқа, SSL-hello пакеті әдеттегі ашық SNI өрісін де қамтиды, біз оны кез келген ретпен көрсете аламыз (бұл жағдайда - ).
Бұл ашық SNI өрісі cloudflare серверлерімен өңделген кезде ешқандай түрде ескерілмеді және тек DPI провайдері үшін маска ретінде қызмет етті. Cloudflare сервері біздің ssl-hello пакетін алды, eSNI шифрын шешті, сол жерден түпнұсқа SNI шығарып, оны ештеңе болмағандай өңдеді (ол eSNI әзірлеу кезінде барлығын дәл жоспарлағандай жасады).
Бұл жағдайда DPI көзқарасы бойынша ұстауға болатын жалғыз нәрсе - _esni.cloudflare.com сайтына бастапқы DNS сұрауы. Бірақ біз бұл механизмнің ішінен қалай жұмыс істейтінін көрсету үшін DNS сұрауын аштық.
DPI астындағы кілемшені алып тастау үшін біз жоғарыда аталған DNS-over-HTTPS механизмін қолданамыз. Кішкене түсініктеме - DOH - бұл HTTPS арқылы DNS сұрауын жіберу арқылы ортадағы адам шабуылынан қорғауға мүмкіндік беретін протокол.
Сұрауды қайтадан орындайық, бірақ бұл жолы біз DNS емес, https протоколы арқылы жалпыға қолжетімді eSNI кілттерін аламыз:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Сұраныс трафик демпі төмендегі скриншотта көрсетілген:
Curl алдымен mozilla.cloudflare-dns.com серверіне DoH протоколы (104.16.249.249 серверіне қосылу) арқылы олардан 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
Бұл жағдайда біз DNS.google DoH шешушісін пайдаланып бұғатталған 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