Увод
Савремени системи за филтрирање корпоративног садржаја реномираних произвођача као што су Цисцо, БлуеЦоат, ФиреЕие имају доста заједничког са својим моћнијим колегама - ДПИ системима, који се активно имплементирају на националном нивоу. Суштина рада и једног и другог је да прегледају долазни и одлазни Интернет саобраћај и на основу црних/белих листа донесу одлуку о забрани интернет везе. А пошто се и једни и други ослањају на сличне принципе у основама свог рада, методе за њихово заобилажење ће такође имати много заједничког.
Једна од технологија која вам омогућава да прилично ефикасно заобиђете и ДПИ и корпоративне системе је технологија фронтинг домена. Његова суштина је да идемо на блокирани ресурс, скривајући се иза другог, јавног домена са добром репутацијом, који очигледно неће бити блокиран ни од једног система, на пример гоогле.цом.
О овој технологији је већ написано доста чланака и дато је много примера. Међутим, популарне и недавно разматране технологије ДНС-овер-ХТТПС и шифрованих-СНИ, као и нова верзија ТЛС 1.3 протокола, омогућавају разматрање друге опције за фронтинг домена.
Разумевање технологије
Прво, хајде да дефинишемо мало основне појмове како би сви разумели ко је ко и зашто је све ово потребно. Поменули смо механизам еСНИ, о чијем раду ће бити речи даље. Механизам еСНИ (индикација шифрованог имена сервера) је безбедна верзија СНИ, доступна само за ТЛС 1.3 протокол. Основна идеја је шифровање, између осталог, информација о томе на који домен се шаље захтев.
Погледајмо сада како механизам еСНИ функционише у пракси.
Рецимо да имамо Интернет ресурс који је блокиран модерним ДПИ решењем (узмимо, на пример, чувени торрент трацкер рутрацкер.нл). Када покушамо да приступимо веб локацији торрент трацкер-а, видимо стандардни стуб добављача који показује да је ресурс блокиран:
На сајту РКН-а овај домен је заправо наведен у стоп листама:
Када поставите упит вхоис, можете видети да је сам домен „скривен“ иза добављача облака Цлоудфларе.
Али за разлику од „специјалиста“ из РКН-а, технички поткованији запослени из Беелине-а (или поучени горким искуством нашег познатог регулатора) нису глупо забранили сајт по ИП адреси, већ су додали име домена на стоп листу. Ово можете лако да проверите ако погледате који су други домени скривени иза исте ИП адресе, посетите један од њих и видите да приступ није блокиран:
Како се ово дешава? Како ДПИ провајдера зна на ком домену је мој претраживач, пошто се сва комуникација одвија преко хттпс протокола, а ми још нисмо приметили замену хттпс сертификата од Беелине-а? Да ли је он видовит или ме прате?
Покушајмо да одговоримо на ово питање гледајући саобраћај кроз виресхарк
Снимак екрана показује да прво претраживач добија ИП адресу сервера преко ДНС-а, затим долази до стандардног ТЦП руковања са одредишним сервером, а затим претраживач покушава да успостави ССЛ везу са сервером. Да би то урадио, шаље ССЛ Цлиент Хелло пакет, који садржи име изворног домена у чистом тексту. Ово поље је потребно за цлоудфларе фронтенд сервер да би исправно усмерио везу. Овде нас провајдер ДПИ ухвати, прекидајући нашу везу. У исто време, не добијамо никакав стуб од провајдера и видимо стандардну грешку прегледача као да је сајт онемогућен или једноставно не ради:
Сада омогућимо еСНИ механизам у претраживачу, као што је написано у упутствима за :
Да бисмо то урадили, отварамо страницу са конфигурацијом Фирефок-а абоут: цонфиг и активирајте следећа подешавања:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Након овога, проверићемо да ли подешавања исправно функционишу на веб локацији цлоудфларе. и хајде да поново пробамо трик са нашим торрент трацкером.
Воила. Наш омиљени трацкер отворен је без икаквог ВПН-а или прокси сервера. Хајде сада да погледамо депонију саобраћаја у Виресхарк-у да видимо шта се догодило.
Овог пута, ссл клијент хелло пакет не садржи експлицитно одредишни домен, али се уместо тога појавило ново поље у пакету - енцриптед_сервер_наме - овде је садржана вредност рутрацкер.нл и само цлоудфларе фронтенд сервер може да дешифрује ово поље. А ако јесте, онда провајдер ДПИ нема другог избора него да опере руке и дозволи такав саобраћај. Не постоје друге опције са шифровањем.
Дакле, погледали смо како технологија функционише у претраживачу. Сада покушајмо да га применимо на конкретније и занимљивије ствари. И прво, научићемо исти цурл да користи еСНИ за рад са ТЛС 1.3, а у исто време ћемо видети како функционише сама еСНИ-базирана фронтинг домена.
Представљање домена са еСНИ
Због чињенице да цурл користи стандардну опенссл библиотеку за повезивање преко хттпс протокола, пре свега морамо да обезбедимо еСНИ подршку тамо. Још нема еСНИ подршке у опенссл мастер гранама, тако да морамо да преузмемо посебну опенссл грану, компајлирамо је и инсталирамо.
Клонирамо спремиште са ГитХуб-а и компајлирамо као и обично:
$ 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
Овде је важно правилно навести све директоријуме у којима се налази опенссл (у нашем случају то је /опт/опенссл/) и уверити се да процес конфигурације прође без грешака.
Ако је конфигурација успешна, видећемо ред:
УПОЗОРЕЊЕ: есни ЕСНИ је омогућен, али означен као ЕКСПЕРИМЕНТАЛНО. Користите са опрезом!
$ makeНакон успешне изградње пакета, користићемо посебну басх датотеку из опенссл да конфигуришемо и покренемо цурл. Копирајмо га у директоријум са цурл ради погодности:
cp /opt/openssl/esnistuff/curl-esni и направите тест хттпс захтев серверу цлоудфларе, док истовремено снимате ДНС и ТЛС пакете у Виресхарку.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/У одговору сервера, поред много информација за отклањање грешака из опенссл-а и цурл-а, добићемо ХТТП одговор са кодом 301 од цлоудфларе-а.
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/
што указује да је наш захтев успешно достављен на одредишни сервер, саслушан и обрађен.
Погледајмо сада депонију саобраћаја у виресхарк-у, тј. шта је провајдер ДПИ видео у овом случају.
Може се видети да се цурл прво окренуо ка ДНС серверу за јавни еСНИ кључ за цлоудфларе сервер – ТКСТ ДНС захтев за _есни.цлоудфларе.цом (пакет бр. 13). Затим, користећи опенссл библиотеку, цурл је послао ТЛС 1.3 захтев серверу цлоудфларе у којем је СНИ поље шифровано јавним кључем добијеним у претходном кораку (пакет #22). Али, поред еСНИ поља, ССЛ-хелло пакет је укључивао и поље са уобичајеним - отвореним СНИ, које можемо навести било којим редоследом (у овом случају - ).
Ово отворено СНИ поље ни на који начин није узето у обзир када су га обрађивали цлоудфларе сервери и служило је само као маска за ДПИ провајдера. Цлоудфларе сервер је примио наш ссл-хелло пакет, дешифровао еСНИ, извукао оригинални СНИ одатле и обрадио га као да се ништа није догодило (урадио је све тачно како је планирано када је развијао еСНИ).
Једина ствар која се у овом случају може ухватити са ДПИ тачке гледишта је примарни ДНС захтев за _есни.цлоудфларе.цом. Али отворили смо ДНС захтев само да бисмо показали како овај механизам функционише изнутра.
Да бисмо коначно извукли тепих испод ДПИ-а, користимо већ поменути механизам ДНС-овер-ХТТПС. Мало објашњење - ДОХ је протокол који вам омогућава да се заштитите од напада човека у средини слањем ДНС захтева преко ХТТПС-а.
Хајде да поново извршимо захтев, али овог пута ћемо добити јавне еСНИ кључеве преко хттпс протокола, а не ДНС-а:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Думп саобраћаја захтева је приказан на слици испод:
Види се да цурл прво приступа мозилла.цлоудфларе-днс.цом серверу преко ДоХ протокола (хттпс веза са сервером 104.16.249.249) да би од њих добио вредности јавних кључева за СНИ енкрипцију, а затим до одредишта сервер, који се крије иза домена .
Поред горе наведеног ДоХ резолвера мозилла.цлоудфларе-днс.цом, можемо користити и друге популарне ДоХ сервисе, на пример, из познате зла корпорације.
Покренимо следећи упит:
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
У овом случају, обратили смо се блокираном серверу рутрацкер.нл, користећи ДоХ ресолвер днс.гоогле (овде нема грешке у куцању, сада позната корпорација има свој домен првог нивоа) и покрили се другим доменом, што је стриктно забрањено за све ДПИ да блокирају под претњом смрти. На основу примљеног одговора, можете схватити да је наш захтев успешно обрађен.
Као додатну проверу да ли ДПИ провајдера одговара на отворени СНИ, који преносимо као маску, можемо да упутимо захтев рутрацкер.нл под маском неког другог забрањеног ресурса, на пример, другог „доброг“ торрент трацкера:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Нећемо добити одговор са сервера, јер... наш захтев ће бити блокиран од стране ДПИ система.
Кратак закључак првог дела
Дакле, успели смо да демонстрирамо функционалност еСНИ користећи опенссл и цурл и тестирамо рад фронтинга домена заснованог на еСНИ. На исти начин, можемо прилагодити наше омиљене алате који користе опенссл библиотеку да раде „под маском“ других домена. Више детаља о томе у нашим следећим чланцима.
Извор: ввв.хабр.цом