Доменното фръндинг на базата на 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 използва стандартната библиотека openssl за https връзки, първо трябва да осигурим поддръжка на eSNI именно там. В master клоновете на 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 Преместено постоянно
< Date: Нед, 03 Ное 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Пн, 02-Ное-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/

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

Няколко заключителни думи към първата част

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

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