Формирање на домен базирано на TLS 1.3

Вовед

Современите корпоративни системи за филтрирање на содржина од такви реномирани производители како 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.

Но, за разлика од „специјалистите“ од RKN, технички поупатените вработени од Beeline (или поучени од горчливото искуство на нашиот познат регулатор) не глупаво ја забранија страницата по IP адреса, туку го додадоа името на доменот во списокот за стопирање. Можете лесно да го потврдите ова ако погледнете кои други домени се скриени зад истата IP адреса, посетете еден од нив и видете дека пристапот не е блокиран:

Како се случува ова? Како DPI на провајдерот знае на кој домен е мојот прелистувач, бидејќи сите комуникации се случуваат преку протоколот https, а сè уште не сме забележале замена на сертификати https од Beeline? Дали тој е видовит или ме следат?

Ајде да се обидеме да одговориме на ова прашање гледајќи го сообраќајот преку wireshark

Сликата од екранот покажува дека прво прелистувачот ја добива IP адресата на серверот преку DNS, потоа се случува стандардно TCP ракување со одредишниот сервер, а потоа прелистувачот се обидува да воспостави SSL врска со серверот. За да го направите ова, тој испраќа пакет SSL Client 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