Вовед
Современите корпоративни системи за филтрирање на содржина од такви реномирани производители како Cisco, BlueCoat, FireEye имаат доста заедничко со нивните помоќни колеги - DPI системи, кои активно се имплементираат на национално ниво. Суштината на работата на двајцата е да го проверат дојдовниот и појдовниот интернет сообраќај и врз основа на црно/бели списоци да донесат одлука за забрана на интернет конекцијата. И бидејќи и двајцата се потпираат на слични принципи во основите на нивната работа, методите за нивно заобиколување исто така ќе имаат многу заедничко.
Една од технологиите што ви овозможува доста ефективно да ги заобиколите и DPI и корпоративните системи е технологијата на домен-фронт. Нејзината суштина е дека одиме до блокиран ресурс, криејќи се зад друг, јавен домен со добра репутација, кој очигледно нема да биде блокиран од ниту еден систем, на пример google.com.
За оваа технологија веќе се напишани доста статии и дадени се многу примери. Сепак, популарните и неодамна дискутирани DNS-over-HTTPS и шифрирани-SNI технологии, како и новата верзија на протоколот TLS 1.3, овозможуваат да се разгледа друга опција за фронтирање на доменот.
Разбирање на технологијата
Прво, да дефинираме малку основни концепти за секој да има разбирање за тоа кој е кој и зошто е потребно сето ова. Го споменавме механизмот eSNI, чие функционирање ќе се дискутира понатаму. Механизмот eSNI (шифрирана индикација за името на серверот) е безбедна верзија на SNI, достапна само за протоколот TLS 1.3. Главната идеја е да се шифрираат, меѓу другото, информации за тоа до кој домен е испратено барањето.
Сега да погледнеме како функционира механизмот eSNI во пракса.
Да речеме дека имаме интернет ресурс што е блокиран од модерно решение за DPI (да го земеме, на пример, познатиот torrent tracker rutracker.nl). Кога се обидуваме да пристапиме до веб-страницата на тракерот за торенти, го гледаме стандардниот никулец на давателот што покажува дека ресурсот е блокиран:
На веб-страницата на RKN овој домен е всушност наведен во стоп листите:
Кога прашувате whois, можете да видите дека самиот домен е „скриен“ зад провајдерот на облак Cloudflare.
Но, за разлика од „специјалистите“ од РКН, технички поискусните вработени од Билинг (или оние научени од горчливото искуство на нашиот познат регулатор) не само што ја забранија страницата по IP адреса, туку ја додадоа конкретно на листата за стопирање име на доменОва лесно може да се потврди со гледање кои други домени се скриени зад истиот овој. IP-адреса, посетете еден од нив и проверете дали пристапот не е блокиран:
Како се случува ова? Како DPI на провајдерот знае на кој домен е мојот прелистувач, бидејќи сите комуникации се случуваат преку протоколот https, а сè уште не сме забележале замена на сертификати https од Beeline? Дали тој е видовит или ме следат?
Ајде да се обидеме да одговориме на ова прашање гледајќи го сообраќајот преку wireshark
Сликата од екранот покажува дека прелистувачот прво ја добива IP адресата на серверот преку DNS, потоа се случува стандардно TCP ракување со дестинацискиот сервер, а потоа прелистувачот се обидува да воспостави SSL врска со серверот. За да го направи ова, тој пренесува пакет SSL Клиентот Hello, кој го содржи името на изворниот домен во јасен текст. Ова поле е потребно за предниот сервер на Cloudflare за правилно насочување на врската. Тука нè фаќа DPI на интернет-провајдерот, прекинувајќи ја нашата врска. Сепак, не добиваме никаков стат од интернет-провајдерот и гледаме стандардна грешка во прелистувачот, како да страницата не работи или едноставно не работи:
Сега да го овозможиме механизмот eSNI во прелистувачот, како што е напишано во упатствата за Firefox :
За да го направите ова, ја отвораме страницата за конфигурација на Firefox за: конфиг и активирајте ги следните поставки:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
После ова, ќе провериме дали поставките работат правилно на веб-страницата cloudflare. линк и ајде повторно да го пробаме трикот со нашиот torrent tracker.
Voila. Нашиот омилен тракер се отвори без никаков VPN или прокси-сервер. Ајде сега да ја погледнеме сообраќајната депонија во wireshark за да видиме што се случило.
Овој пат, пакетот ssl клиент здраво не го содржи експлицитно доменот одредиште, туку наместо тоа, се појави ново поле во пакетот - encrypted_server_name - тука е содржана вредноста на rutracker.nl и само фронтен серверот cloudflare може да го дешифрира ова Поле. И ако е така, тогаш провајдерот DPI нема друг избор освен да ги мие рацете и да дозволи таков сообраќај. Нема други опции со шифрирање.
Значи, погледнавме како функционира технологијата во прелистувачот. Сега да се обидеме да го примениме на поконкретни и интересни работи. И прво, ќе го научиме истиот curl да користи eSNI за да работи со TLS 1.3, а во исто време ќе видиме како функционира самиот домен заснован на eSNI.
Формирање на домен со eSNI
Поради фактот што curl ја користи стандардната библиотека openssl за поврзување преку протоколот https, прво треба да обезбедиме поддршка за eSNI таму. Сè уште нема поддршка за eSNI во главните гранки на openssl, затоа треба да преземеме посебна гранка на 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По успешното градење на пакетот, ќе користиме специјална bash-датотека од openssl за конфигурирање и извршување на curl. Ајде да го копираме во директориумот со curl за погодност:
cp /opt/openssl/esnistuff/curl-esni и направете тест https барање до серверот cloudflare, додека истовремено снимате DNS и TLS пакети во Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Во одговорот на серверот, покрај многу информации за дебагирање од openssl и curl, ќе добиеме и HTTP одговор со код 301 од cloudflare.
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 прво се сврте кон серверот DNS за јавен eSNI клуч за серверот cloudflare - барање за TXT DNS до _esni.cloudflare.com (пакет бр. 13). Потоа, користејќи ја библиотеката openssl, curl испрати барање TLS 1.3 до серверот cloudflare во кој полето SNI беше шифрирано со јавниот клуч добиен во претходниот чекор (пакет #22). Но, покрај полето eSNI, пакетот SSL-hello вклучуваше и поле со вообичаеното - отворено SNI, кое можеме да го наведеме по кој било редослед (во овој случај - www.hello-rkn.ru).
Ова отворено SNI поле не беше земено предвид на кој било начин кога се обработуваше од серверите на cloudflare и служеше само како маска за DPI на давателот. Серверот cloudflare го прими нашиот пакет ssl-hello, го дешифрираше eSNI, го извади оригиналниот SNI од таму и го обработи како ништо да не се случило (тој направи сè точно како што беше планирано кога го развиваше eSNI).
Единственото нешто што може да се фати во овој случај од гледна точка на DPI е примарното барање за DNS до _esni.cloudflare.com. Но, го направивме барањето за DNS отворено само за да покажеме како функционира овој механизам одвнатре.
За конечно да го извлечеме тепихот од под DPI, го користиме веќе споменатиот механизам DNS-over-HTTPS. Мало објаснување - DOH е протокол кој ви овозможува да се заштитите од напад од човек во средината со испраќање на барање за DNS преку HTTPS.
Ајде повторно да го извршиме барањето, но овој пат ќе добиеме јавни клучеви eSNI преку протоколот https, а не преку DNS:
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 (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
Во овој случај, се обративме до блокираниот сервер rutracker.nl, користејќи го решавачот на DoH dns.google (тука нема печатна грешка, сега познатата корпорација има свој домен од прво ниво) и се покривме со друг домен, кој е строго забрането е блокирање на сите DPI под смртна болка. Врз основа на добиениот одговор, можете да разберете дека нашето барање е успешно обработено.
Како дополнителна проверка дали DPI на провајдерот реагира на отворениот SNI, што го пренесуваме како покритие, можеме да поднесеме барање до rutracker.nl под маската на некој друг забранет ресурс, на пример, друг „добар“ torrent tracker:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Од серверот нема да добиеме одговор, бидејќи ... нашето барање ќе биде блокирано од системот DPI.
Краток заклучок за првиот дел
Така, можевме да ја демонстрираме функционалноста на eSNI користејќи openssl и curl и тестирање на работата на предниот дел на доменот врз основа на eSNI. На ист начин, можеме да ги приспособиме нашите омилени алатки кои ја користат библиотеката openssl да работат „под маската“ на други домени. Повеќе детали за ова во нашите следни написи.
Извор: www.habr.com
