Domenové frontování na bázi TLS 1.3

Úvod

Moderní korporátní systémy filtrace obsahu, od známých výrobců jako Cisco, BlueCoat, FireEye, mají mnoho společného s jejich výkonnějšími protějšky — DPI systémy, které jsou aktivně zaváděny na národní úrovni. Podstatou práce obou systémů je provádět inspekci příchozího a odchozího internetového provozu a na základě černých/bílých seznamů rozhodovat o zablokování internetového spojení. A protože oba systémy vycházejí ze stejných principů, budou mít i způsoby jejich obcházení mnoho společného.

Jednou z technologií, která umožňuje efektivně obcházet jak DPI, tak korporátní systémy, je technologie doménového frontingu. Jejím základem je, že se dostáváme na zablokovaný zdroj, přičemž se skrýváme za jinou veřejnou doménou s dobrou pověstí, která nebude zablokována žádným systémem, například google.com.

O této technologii bylo napsáno již dostatek článků a uvedeno mnoho příkladů. Nicméně populární a nedávno diskutované technologie DNS-over-HTTPS a encrypted-SNI, stejně jako nová verze protokolu TLS 1.3, umožňují prozkoumat ještě jeden variant doménového frontingu.

Pojďme se podívat na technologii

Nejprve si stručně objasníme základní pojmy, aby všichni rozuměli, kdo je kdo a k čemu je to všechno potřeba. Zmínili jsme mechanismus eSNI, jehož fungování bude podrobněji probráno. Mechanismus eSNI (encrypted Server Name Indication) – zabezpečená varianta SNI, dostupná pouze pro protokol TLS 1.3. Hlavní podstatou je šifrování také informací o tom, na jakou doménu je zaslán požadavek.

A nyní se podíváme na praktickou funkci mechanismu eSNI.

Představme si, že máme internetový zdroj, který je blokován moderním DPI řešením (vezměme si například slavný torrent tracker — rutracker.nl). Při pokusu o návštěvu webu torrent trackeru vidíme standardní vzkaz od poskytovatele, že je zdroj blokován:

Na webu RKN je tato doména skutečně uvedena na blacklistu:

Při dotazu whois je vidět, že samotná doména je "schována" za cloudovým poskytovatelem Cloudflare.

Ale na rozdíl od „specialistů“ z RKN, technicky zdatnější pracovníci z Beeline (nebo poučeni hořkou zkušeností našeho slavného regulátora) se nerozhodli prostě blokovat web podle IP adresy, ale zařadili do černé listiny právě doménové jméno. To lze snadno ověřit, pokud se podíváte, jaké další domény se skrývají za tímto IP adresou, navštívíte jednu z nich a uvidíte, že přístup není zablokován:

Jak to tedy funguje? Jakým způsobem provider DPI zjistí, na kterou z domén můj prohlížeč směřuje, když všechny komunikace probíhají podle protokolu https, a zatím jsme si nevšimli žádné podvodné certifikace https od Beeline? Není snad vidící, nebo za mnou probíhá sledování?

Zkusíme odpovědět na tuto otázku pohledem na provoz přes Wireshark

Na screenshotu je vidět, že nejprve prohlížeč získává IP adresu serveru přes DNS, potom probíhá standardní TCP handshake se cílovým serverem, a poté se prohlížeč pokouší navázat ssl spojení se serverem. K tomu přenáší paket SSL Client Hello, jehož součástí je název zdrojové domény v otevřené podobě. Toto pole je nezbytné pro front-end server Cloudflare, aby správně směroval spojení. Právě zde nás chytí poskytovatel DPI, přeruší naše spojení. Přitom nedostáváme žádnou zástupnou stránku od poskytovatele, a vidíme standardní chybu prohlížeče, jako by byl web vypnutý nebo prostě nefungoval:

Teď zapneme mechanismus eSNI v prohlížeči, jak je uvedeno v návodu pro Firefox :
K tomu otevřeme stránku nastavení Firefoxu about:config a aktivujeme následující nastavení:

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

Poté zkontrolujeme správnost nastavení na webu Cloudflare podle odkazu a zkusíme trik s naším torrent trackerem ještě jednou.

Voila. Náš oblíbený tracker se otevřel, bez jakýchkoliv VPN a proxy serverů. Teď se podívejme na dump provozu ve Wiresharku, co se vlastně stalo.

Tentokrát paket ssl client hello neobsahuje jasně uvedenou doménu určení, místo toho se v rámci paketu objevilo nové pole — encrypted_server_name — právě tam je obsažena hodnota rutracker.nl a dešifrovat toto pole může pouze front-end server Cloudflare. A jelikož je tomu tak, poskytovateli DPI nezůstává nic jiného, než si umýt ruce a povolit takový provoz. A jiná řešení s šifrováním nejsou.

Takže, jak technologie funguje v prohlížeči — to jsme prozkoumali. Nyní se pokusíme použít ji pro specifické a zajímavější věci. A jako první naučíme stejný curl používat eSNI pro práci s TLS 1.3, a zároveň se podíváme, jak funguje samotné domain fronting na základě eSNI.

Domain fronting s eSNI

Vzhledem k tomu, že curl pro připojení protokolem https používá standardní knihovnu openssl, musíme nejprve zajistit podporu eSNI právě tam. V master větvích openssl podpora eSNI zatím není, takže si musíme stáhnout speciální větev openssl, zkompilovat ji a nainstalovat.

Klonujeme repozitář z githubu a kompilujeme jako obvykle:

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

Dále – klonujeme repozitář s curl a konfigurujeme jeho kompilaci s použitím naší zkompilované openssl knihovny:

$ 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

Tady je důležité správně uvést všechny adresáře, kde se nachází openssl (v našem případě je to /opt/openssl/) a zajistit, aby proces konfigurace proběhl bez chyb.

V případě úspěšné konfigurace uvidíme řádek:

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

$ make

Po úspěšném sestavení balíčku použijeme speciální bash soubor z balíku openssl pro nastavení a spuštění curl. Zkopírujeme jej do adresáře s curl pro pohodlí:

cp /opt/openssl/esnistuff/curl-esni 

a provedeme testovací https požadavek na server cloudflare, zároveň zaznamenáme DNS a TLS pakety ve Wireshark.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

Ve odpovědi serveru kromě spousty ladících informací od openssl a curl obdržíme HTTP odpověď s kódem 301 od 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/

což svědčí o tom, že náš požadavek byl úspěšně doručen na cílový server, slyšen a zpracován.

Nyní se podíváme na dump provozu ve Wiresharku, tj. co v tomto případě viděl poskytovatel DPI.

Je jasné, že se curl nejprve obrátil na DNS server pro veřejné eSNI klíče pro server cloudflare – TXT DNS dotaz na _esni.cloudflare.com (paket č. 13). Poté, s využitím knihovny openssl, curl odeslal TLS 1.3 dotaz na server cloudflare, ve kterém bylo pole SNI zašifrováno veřejným klíčem získaným v předchozím kroku (paket č. 22). Ale kromě pole eSNI byl do SSL-hello paketu vložen také obvyklý – otevřený SNI, který můžeme uvést v libovolném pořadí (v tomto případě – www.hello-rkn.ru).

Toto pole otevřeného SNI nebylo při zpracování servery cloudflare nijak zohledněno a sloužilo pouze jako maskovací prvek pro poskytovatelské DPI. Server cloudflare přijal náš ssl-hello paket, dešifroval eSNI, extrahoval z něj původní SNI a zpracoval ho, jako by se nic nestalo (udělal to přesně tak, jak bylo plánováno při vývoji eSNI).

Jediné, čeho se v tomto případě může DPI chytit, je primární DNS dotaz na _esni.cloudflare.com. Ale my jsme udělali DNS dotaz otevřeným pouze proto, abychom ukázali, jak tento mechanismus funguje z vnitřní perspektivy.

Abychom definitivně podkopali půdu pod nohama DPI, používáme již zmíněný mechanismus DNS-over-HTTPS. Krátké vysvětlení – DOH – protokol, který umožňuje chránit se před útoky „člověk uprostřed“ díky zasílání DNS dotazů prostřednictvím protokolu HTTPS.

Dotaz provedeme znovu, ale tentokrát veřejné eSNI klíče získáme prostřednictvím protokolu https, nikoli DNS:

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

Dump provozu dotazu je uveden na screenshotu níže:

Jak je vidět, nejprve se curl obrací na server mozilla.cloudflare-dns.com prostřednictvím protokolu DoH (https spojení na server 104.16.249.249), aby od nich získal hodnoty veřejných klíčů pro šifrování SNI, a teprve poté se obrátil na cílový server, přičemž se skrýval za doménou. www.hello-rkn.ru.

Kromě výše uvedeného DoH resolveru mozilla.cloudflare-dns.com můžeme využít i další populární služby DoH, například od slavné „zlé“ korporace.
Provedeme takový dotaz:

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

A dostaneme odpověď:

< 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

V tomto případě jsme se obrátili na zablokovaný server rutracker.nl, přičemž jsme použili DoH resolver dns.google (není zde chyba, nyní má slavná korporace svou doménu nejvyšší úrovně) a schovali se za jinou doménou, jejíž blokace je všemi DPI striktně zakázána pod hrozbou přísných trestů. Z obdržené odpovědi lze pochopit, že náš požadavek byl úspěšně zpracován.

Jako dodatečnou kontrolu toho, že providerní DPI reaguje na otevřený SNI, který poskytujeme jako krytí — můžeme provést požadavek na rutracker.nl tak, že se schováme za nějaký jiný zakázaný zdroj, například další 'dobrý' torrent tracker:

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

Odpověď od serveru nedostaneme, protože náš požadavek bude zablokován systémem DPI.

Malé závěrečné slovo k první části

Takže se nám podařilo ukázat funkčnost eSNI pomocí openssl a curl a ověřit funkci doménového frontingu založeného na eSNI. Stejným způsobem můžeme přizpůsobit naše oblíbené nástroje využívající knihovnu openssl pro práci 'pod krytím' jiných domén. Více o tom v našich dalších článcích.

Zdroj: habr.com