Doménový fronting na základe TLS 1.3

Úvod

Súčasné podnikové systémy na filtrovanie obsahu, od renomovaných výrobcov ako Cisco, BlueCoat, FireEye, majú dosť spoločné s ich mocnejšími náprotivkami - systémami DPI, ktoré sú intenzívne implementované na národnej úrovni. Podstata fungovania oboch typov spočíva v kontrole prichádzajúceho a odchádzajúceho internetového prenosu a na základe čiernych/bielych zoznamov prijímajú rozhodnutia o zákaze internetového pripojenia. A keďže obidva typy sa vo svojich základoch spoliehajú na podobné princípy, aj metódy ich obchádzania budú mať veľa spoločného.

Jednou z technológií, ktorá umožňuje pomerne efektívne obchádzať ako DPI, tak aj podnikové systémy, je technológia doménového frontingu. Jej podstata spočíva v tom, že sa snažíme pristupovať na zablokovaný zdroj, skrytí za inou, verejnou doménou, s dobrou reputáciou, ktorá zaručene nebude zablokovaná žiadnym systémom, ako napríklad google.com.

O tejto technológii už bolo napísaných množstvo článkov a uvedených množstvo príkladov. Avšak populárne a v poslednej dobe diskutované technológie DNS-over-HTTPS a encrypted-SNI, ako aj nová verzia protokolu TLS 1.3, poskytujú možnosť preskúmať ďalšiu variantu doménového frontingu.

Rozoberieme technológiu

Najprv si objasníme základné pojmy, aby všetci mali prehľad o tom, kto je kto a na čo je to všetko potrebné. Spomenuli sme mechanizmus eSNI, ktorého fungovanie bude ďalej preskúmané. Mechanizmus eSNI (encrypted Server Name Indication) je zabezpečená verzia SNI, dostupná len pre protokol TLS 1.3. Hlavná podstata spočíva v šifrovaní vrátane informácií o tom, na akú doménu je poslaná požiadavka.

A teraz sa pozrime na fungovanie mechanizmu eSNI v praxi.

Predpokladajme, že máme internetový zdroj, ktorý je blokovaný moderným DPI riešením (vezmime si napríklad známy torrent tracker - rutracker.nl). Pri pokuse o vstup na stránku torrent trackeru vidíme štandardnú informačnú hlášku poskytovateľa o tom, že zdroj je blokovaný:

Na stránke RKN tento doménový názov skutočne figuruje v čiernych zoznamoch:

Pri dopyte whois je vidno, že samotný doménový názov je 'skrytý' za cloudovým poskytovateľom Cloudflare.

Na rozdiel od "špecialistov" z RKN, technicky zdatnejší zamestnanci z beeline (alebo poučení zlými skúsenosťami nášho známeho regulátora) sa nerozhodli jednostranne zablokovať stránku podľa IP adresy, ale zaradili do stop-listu presne doménové meno. Je to ľahko overiteľné, ak sa pozriete, aké ďalšie domény sú skryté za týmto IP adresou, navštívte jednu z nich a uvidíte, že prístup nie je zablokovaný:

Ako to teda funguje? Akým spôsobom poskytovateľský DPI zistí, na ktorú z domén sa môj prehliadač smeruje, keďže všetky komunikácie prebiehajú cez protokol https, a zatiaľ sme si nepozorovali žiadne podvody so https certifikátmi od beeline? Je to veštec alebo ma niekto sleduje?

Skúsme odpovedať na túto otázku, pohľadom na prenos cez wireshark

Na snímke obrazovky je vidieť, že najprv prehliadač dostane IP adresu servera cez DNS, potom prebieha štandardné TCP handshake so cieľovým serverom, a potom sa prehliadač snaží nadviazať ssl pripojenie so serverom. Za týmto účelom posiela paket SSL Client Hello, v ktorom je prítomné meno zdrojovej domény v otvorenej podobe. Toto pole je potrebné frontend serveru cloudflare pre správne smerovanie pripojenia. A práve tu nás zachytí poskytovateľský DPI, prerušením nášho pripojenia. Pri tom nedostávame od poskytovateľa žiadnu blokáciu, a vidíme štandardnú chybu prehliadača, akoby stránka bola odpojená alebo jednoducho nefungovala:

Teraz aktivujme mechanizmus eSNI v prehliadači, ako je to uvedené v pokynoch pre Firefox :
Za týmto účelom otvoríme stránku konfigurácie Firefox about:config a aktivujeme nasledujúce nastavenia:

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

Potom skontrolujeme, či nastavenia správne fungujú na stránke cloudflare podľa odkaze a skúsime trik s naším torrent trackером ešte raz.

Voilà. Náš obľúbený tracker sa otvoril, bez akýchkoľvek VPN a proxy serverov. Poďme sa teraz pozrieť na dump prenosu v wireshark, čo sa vlastne stalo.

Tentokrát paket ssl client hello neobsahuje v otvorenej forme doménu určenia, miesto toho sa v rámci paketu objavuje nové pole — encrypted_server_name — práve tam je uložená hodnota rutracker.nl, a toto pole môže dešifrovať len frontend server cloudflare. A keďže je to tak, poskytovateľskému DPI nezostáva nič iné, ako si umyť ruky a povoliť takýto prenos. A iné varianty šifrovania ani nie sú.

Takže, ako funguje technológia v prehliadači — to sme si už pozreli. Teraz sa pokúsme použiť ju na špecifickejšie a zaujímavejšie veci. A na začiatok sa naučíme, ako používať curl s eSNI na prácu s TLS 1.3 a zároveň sa pozrieme na to, ako funguje doménový fronting na základe eSNI.

Doménový fronting s eSNI

Keďže curl pre pripojenie cez https protokol využíva štandardnú knižnicu openssl, predovšetkým musíme zabezpečiť podporu eSNI práve tam. V master vetvách openssl zatiaľ podpora eSNI neexistuje, preto si musíme stiahnuť špeciálnu vetvu openssl, skompilovať a nainštalovať ju.

Klóniujeme repozitár z GitHubu a kompilujeme ako obvykle:

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

$ make
$ cd esnistuff
$ make

Ďalej — klonujeme repozitár s curl a konfigurovame jeho kompiláciu s použitím našej zostavenej knižnice 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

Je dôležité správne uviesť všetky adresáre, kde sa nachádza openssl (v našom prípade — je to /opt/openssl/) a dbať na to, aby proces konfigurácie prebehol bez chýb.

V prípade úspešnej konfigurácie — uvidíme riadok:

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

$ make

Po úspešnej zostave balíka využijeme špeciálny bash súbor z openssl na konfiguráciu a spustenie curl. Skopírujeme ho do adresára s curl pre pohodlie:

cp /opt/openssl/esnistuff/curl-esni 

a vykonáme testovací https-dopyt na server cloudflare, pričom zároveň zaznamenáme DNS a TLS pakety vo Wiresharku.

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

V odpovedi servera, okrem množstva ladenia informácií od openssl a curl, dostaneme HTTP odpoveď s kódom 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/

čo svedčí o tom, že náš dopyt bol úspešne doručený na cieľový server, zachytený a spracovaný.

Teraz sa pozrime na dump trafficu vo Wiresharku, t.j. čo videl v tomto prípade poskytovateľský DPI.

Je evidentné, že na začiatku sa curl obrátil na DNS server za verejným eSNI kľúčom pre server Cloudflare – TXT DNS dopyt na _esni.cloudflare.com (paket č. 13). Potom, pomocou knižnice OpenSSL, curl odoslal TLS 1.3 dopyt na server Cloudflare, v ktorom bolo pole SNI zašifrované verejným kľúčom získaným v predchádzajúcom kroku (paket č. 22). No, okrem poľa eSNI, bol v rámci SSL-hello paketu vložený aj obvyklý – otvorený SNI, ktorý môžeme zadať v ľubovoľnom poradí (v tomto prípade – www.hello-rkn.ru).

Toto pole otvoreného SNI nebolo nijako zohľadnené pri spracovaní servermi Cloudflare a iba slúžilo ako maskovanie pre poskytovateľský DPI. Server Cloudflare prijal náš ssl-hello paket, dešifroval eSNI, extrahoval z neho pôvodný SNI a spracoval ho, akoby sa nič nestalo (presne tak, ako bolo naplánované pri vývoji eSNI).

Jediné, za čo sa v tomto prípade dá chytiť z pohľadu DPI – prvotný DNS dopyt na _esni.cloudflare.com. Ale my sme urobili DNS dopyt otvoreným len preto, aby sme ukázali, ako tento mechanizmus funguje zvnútra.

Aby sme úplne podkopali základ pod DPI, používame už spomenutý mechanizmus DNS-over-HTTPS. Malé vysvetlenie – DOH – protokol, ktorý umožňuje chrániť sa pred útokom „človek v strede“ tým, že odosiela DNS dopyt cez protokol HTTPS.

Vyžiadame dopyt opäť, ale tentokrát verejné eSNI kľúče získame cez protokol https, a nie DNS:

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

Dump prenosu dopytu je zobrazený na snímke obrazovky nižšie:

Je vidieť, že najprv sa curl obracia na server mozilla.cloudflare-dns.com cez protokol DoH (https spojenie na server 104.16.249.249), aby od nich získal hodnoty verejných kľúčov na šifrovanie SNI, a až potom na server určenia, pričom sa skrýva za doménou. www.hello-rkn.ru.

Okrem vyššie uvedeného DoH resolvera mozilla.cloudflare-dns.com môžeme použiť aj ďalšie populárne služby DoH, napríklad od známej korporácie zla.
Vyžiadame takýto dopyt:

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

A dostaneme odpoveď:

< 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 prípade sme sa spojili so zablokovaným serverom rutracker.nl, pričom sme použili DoH resolver dns.google (toto nie je preklep, teraz má známa korporácia svoj vlastný doménový názov prvej úrovne) a skryli sme sa za iným doménom, ktorého blokovanie je prísne zakázané všetkým DPI pod hrozbou smrteľného trestu. Z poskytnutej odpovede môžeme pochopiť, že náš dopyt bol úspešne spracovaný.

Ako dodatočnú kontrolu toho, že poskytovateľský DPI reaguje na otvorený SNI, ktorý posielame ako pokrytie — môžeme vykonať dopyt na rutracker.nl zakrývajúc sa nejakým iným zakázaným zdrojom, napríklad ďalším "dobrým" torrentovým trackerom:

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

Odpovedať od servera nedostaneme, pretože náš dopyt bude zablokovaný systémom DPI.

Malé zhrnutie prvej časti

Takže sa nám podarilo ukázať funkčnosť eSNI pomocou openssl a curl a overiť fungovanie doménového frontingu založeného na eSNI. Týmto spôsobom môžeme prispôsobiť naše obľúbené nástroje, ktoré používajú knižnicu openssl, na fungovanie "pod krytím" iných domén. Viac o tom v našich nasledujúcich článkoch.

Zdroj: habr.com