Домейн-фронтинг на база TLS 1.3

Въведение

Съвременните корпоративни системи за филтриране на съдържание, от такива именити производители като Cisco, BlueCoat и FireEye, имат доста общо с по-мощните си аналози - DPI системите, които усилено се внедряват на национално ниво. Същността на работата и на двата типа системи е да извършват инспекция на входящия и изходящия интернет трафик и на база черни/бели списъци да вземат решение за блокиране на интернет връзката. Тъй като и двете системи разчитат на подобни принципи в основата на своята работа, начините за заобикаляне също ще имат много общо.

Една от технологиите, позволяващи ефективно заобикаляне както на DPI, така и на корпоративни системи, е технологията домейн-фронтинг. Същността ѝ е, че ние се насочваме към блокирания ресурс, прикривайки се с друг, публичен домейн с добра репутация, който със сигурност няма да бъде блокиран от нито една система, например google.com.

За тази технология вече са написани доста статии и предоставени множество примери. Въпреки това, популярните и дискутирани в последно време технологии DNS-over-HTTPS и encrypted-SNI, а също и новата версия на протокола TLS 1.3 дават възможност да разгледаме още един вариант на домейн-фронтинг.

Разглеждаме технологията

Първо, нека да се запознаем с основните понятия, за да имаме разбиране кой е кой и защо всичко това е необходимо. Споменахме механизма eSNI, чиято работа ще разгледаме по-нататък. Механизмът eSNI (encrypted Server Name Indication) е защитена версия на SNI, налична само за протокол TLS 1.3. Основната същност е да се криптира и информацията за това, към кой домейн се изпраща заявката.

А сега нека разгледаме как работи механизмът eSNI на практика.

Да предположим, че имаме интернет ресурс, който се блокира от съвременно решение на DPI (да вземем за пример известния торрент тракер — rutracker.nl). При опит за достъп до сайта на торрент тракера — виждаме стандартната заглушка от провайдера, че ресурсът е блокиран:

На сайта на РКН този домейн наистина фигурира в черните списъци:

При заявка whois — виждаме, че самият домейн е "скрит" зад облачен провайдер Cloudflare.

Но за разлика от "специалистите" от РКН, по-напредничавите служители от Билайн (или поучени от горчивия опит на нашия знаменит регулатор) не изстреляха сайта само по IP адреса, а го включиха в черния списък именно домейн име. Лесно може да се убеди в това, ако погледнете кой още домейни се крият под този същия IP адреса, посетите един от тях и видите, че достъпът не е блокиран:

А как така се получава? Как по дяволите провайдерският DPI разбира на кой от домейните отива моят браузер, след като всичките комуникации се извършват по протокол https, а подмяната на https сертификатите от Билайн все още не сме забелязали? Не е ли ясновидец или някой следи мен?

Нека се опитаме да отговорим на този въпрос, като погледнем трафика през Wireshark

На скриншота е видно, че първо браузерът получава IP адреса на сървъра чрез DNS, след това се извършва стандартно TCP ръкостискане с целевия сървър, а след това браузерът се опитва да установи ssl връзка със сървъра. За целта той предава пакет SSL Client Hello, в който присъства името на изходния домейн в открит вид. Това поле е необходимо на фронтенд сървера Cloudflare, за да маршрутизира правилно връзката. Тук провайдерският DPI ни хваща, прекъсвайки нашата връзка. При това не получаваме никаква блокировка от провайдера и виждаме стандартна грешка на браузера, сякаш сайта е изключен или просто не работи:

Сега нека включим механизма eSNI в браузера, както е написано в инструкциите за Firefox :
За целта отваряме страницата на конфигурацията на Firefox about:config и активираме следните настройки:

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

След това ще проверим коректността на настройките на сайта на Cloudflare по връзка и ще опитаме трика с нашия торрент трекер отново.

Ето я. Нашият любим трекер се отвори, без никакви VPN и прокси сървъри. Нека сега погледнем на дампа на трафика в Wireshark, какво се е случило.

Този път пакетът ssl client hello не съдържа явно домейн цел, а вместо това в състава на пакета се появи ново поле — encrypted_server_name — именно там се съдържа стойността rutracker.nl, и само фронтенд сървърът Cloudflare може да декодира това поле. А щом така, на провайдерския DPI не остава нищо друго, освен да измие ръцете си и да разреши такъв трафик. А няма и други варианти за шифроване.

И така, как работи технологията в браузъра — разгледахме. Сега нека опитаме да я приложим за по-специфични и интересни неща. Първо, ще научим curl да използва eSNI, за да работи с TLS 1.3, а и ще видим как работи самият домейн фронтинг на базата на 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/) и да се уверим, че процесът на конфигуриране е преминал без грешки.

При успешно конфигуриране — ще видим ред:

WARNING: esni ESNI enabled but marked EXPERIMENTAL. Use with caution!

$ 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 Мoved 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, прикривайки се зад друг забранен ресурс, например друг "добър" торрент тракер:

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Няма да получим отговор от сървъра, тъй като нашият запитване ще бъде BLOCKED от DPI системата.

Кратко заключение на първата част

И така, успяхме да демонстрираме функционалността на eSNI с помощта на openssl и curl и да проверим работата на домейн-фронтинга, основан на eSNI. По същия начин можем да адаптираме любимите си инструменти, използващи библиотеката openssl, за работа "под прикритие" на други домейни. Повече за това — в нашите следващи статии.

Източник: habr.com