Фронтиране на домейн, базирано на 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 решение (да вземем например известния торент тракер - 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 от връзка и опитайте отново трика с нашия торент тракер.

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

Този път пакетът за здравей на ssl клиент не съдържа изрично целевия домейн, но вместо това в пакета се появи ново поле - encrypted_server_name - тук се съдържа стойността rutracker.nl и само предният сървър на cloudflare може да дешифрира това поле. И ако е така, тогава доставчикът на DPI няма друг избор, освен да си измие ръцете и да разреши такъв трафик. И няма други опции с криптиране.

И така, видяхме как работи технологията в браузъра. Сега нека се опитаме да го приложим към по-конкретни и интересни неща. И като начало ще научим същия curl да използва eSNI за работа с TLS 1.3 и в същото време ще видим как работи самият eSNI-базиран fronting домейн.

Фронтиране на домейн с 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, използвайки резолвера dns.google DoH (тук няма правописна грешка, сега известната корпорация има свой собствен домейн от първо ниво) и се покрихме с друг домейн, който е строго забранено да бъде блокиран от всички 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, за да работят „под прикритието“ на други домейни. Повече за това в следващите ни статии.

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