Úvod
Moderné systémy na filtrovanie firemného obsahu od takých renomovaných výrobcov ako Cisco, BlueCoat, FireEye majú pomerne veľa spoločného s ich výkonnejšími kolegami - DPI systémami, ktoré sa aktívne implementujú na národnej úrovni. Podstatou práce oboch je kontrolovať prichádzajúcu a odchádzajúcu internetovú prevádzku a na základe čiernych/bielych zoznamov rozhodnúť o zákaze internetového pripojenia. A keďže obaja sa v základoch svojej práce spoliehajú na podobné princípy, aj metódy na ich obchádzanie budú mať veľa spoločného.
Jednou z technológií, ktorá vám umožňuje pomerne efektívne obísť DPI aj podnikové systémy, je technológia čeliaca doméne. Jeho podstatou je, že ideme na zablokovaný zdroj, ktorý sa skrýva za inou verejnou doménou s dobrou povesťou, ktorú samozrejme nezablokuje žiadny systém, napríklad google.com.
O tejto technológii už bolo napísaných pomerne veľa článkov a bolo uvedených veľa príkladov. Populárne a nedávno diskutované technológie DNS-over-HTTPS a šifrované-SNI, ako aj nová verzia protokolu TLS 1.3 však umožňujú zvážiť ďalšiu možnosť frontingu domény.
Pochopenie technológie
Najprv si definujme trochu základných pojmov, aby každý pochopil, kto je kto a prečo je to všetko potrebné. Spomenuli sme mechanizmus eSNI, o fungovaní ktorého sa bude diskutovať ďalej. Mechanizmus eSNI (encrypted Server Name Indication) je zabezpečená verzia SNI, dostupná len pre protokol TLS 1.3. Hlavnou myšlienkou je okrem iného zašifrovať informácie o tom, na ktorú doménu je požiadavka odoslaná.
Teraz sa pozrime na to, ako mechanizmus eSNI funguje v praxi.
Povedzme, že máme internetový zdroj, ktorý je blokovaný moderným riešením DPI (vezmime si napríklad slávny torrent tracker rutracker.nl). Keď sa pokúšame o prístup na webovú stránku sledovača torrentov, vidíme štandardný útržok poskytovateľa, ktorý naznačuje, že zdroj je zablokovaný:
Na webovej stránke RKN je táto doména skutočne uvedená v zoznamoch zastávok:
Keď zadáte otázku whois, môžete vidieť, že samotná doména je „skrytá“ za poskytovateľom cloudu Cloudflare.
Na rozdiel od „špecialistov“ z RKN však technicky zdatnejší zamestnanci z Beeline (alebo poučení trpkou skúsenosťou nášho slávneho regulátora) hlúpo nezakázali stránku podľa IP adresy, ale pridali názov domény na stoplist. Môžete si to ľahko overiť, ak sa pozriete na to, aké ďalšie domény sa skrývajú za tou istou IP adresou, navštívite jednu z nich a zistíte, že prístup nie je zablokovaný:
Ako sa to stane? Ako DPI poskytovateľa vie, na ktorej doméne je môj prehliadač, keďže všetka komunikácia prebieha cez protokol https a zatiaľ sme nezaznamenali náhradu https certifikátov od Beeline? Je jasnovidec alebo ma sledujú?
Skúsme si na túto otázku odpovedať pohľadom na premávku cez wireshark
Snímka obrazovky ukazuje, že najprv prehliadač získa IP adresu servera cez DNS, potom dôjde k štandardnému TCP handshake s cieľovým serverom a potom sa prehliadač pokúsi nadviazať SSL spojenie so serverom. Na tento účel odošle paket SSL Client Hello, ktorý obsahuje názov zdrojovej domény ako čistý text. Toto pole vyžaduje frontend server cloudflare, aby správne smeroval pripojenie. Tu nás zastihne poskytovateľ DPI a preruší naše spojenie. Zároveň od poskytovateľa nedostávame žiadne útržky a vidíme štandardnú chybu prehliadača, ako keby bola stránka zakázaná alebo jednoducho nefunguje:
Teraz povoľme mechanizmus eSNI v prehliadači, ako je napísané v pokynoch pre :
Za týmto účelom otvoríme konfiguračnú stránku Firefoxu about: config a aktivujte 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 fungujú správne na webovej stránke cloudflare. a skúsme trik s naším sledovačom torrentov znova.
Voila. Náš obľúbený sledovač sa otvoril bez akýchkoľvek serverov VPN alebo proxy. Poďme sa teraz pozrieť na dopravnú skládku v wireshark, aby sme videli, čo sa stalo.
Tentoraz balík ssl klient hello neobsahuje explicitne cieľovú doménu, ale namiesto toho sa v balíku objavilo nové pole - encrypted_server_name - tu je obsiahnutá hodnota rutracker.nl a dešifrovať ju môže iba frontend server cloudflare lúka. A ak áno, tak poskytovateľovi DPI nezostáva nič iné, len si umyť ruky a povoliť takúto prevádzku. Neexistujú žiadne iné možnosti so šifrovaním.
Pozreli sme sa teda na to, ako táto technológia funguje v prehliadači. Teraz to skúsme aplikovať na konkrétnejšie a zaujímavejšie veci. A najprv naučíme tú istú vlnu používať eSNI na prácu s TLS 1.3 a zároveň uvidíme, ako funguje samotný fronting domény na báze eSNI.
Fronting domény s eSNI
Vzhľadom na to, že curl používa na pripojenie cez protokol https štandardnú knižnicu openssl, musíme tam v prvom rade poskytnúť podporu eSNI. V hlavných vetvách openssl zatiaľ nie je podpora eSNI, takže si musíme stiahnuť špeciálnu vetvu openssl, skompilovať a nainštalovať.
Klonujeme úložisko z GitHubu a kompilujeme ako zvyčajne:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Ďalej naklonujeme úložisko pomocou curl a nakonfigurujeme jeho kompiláciu pomocou 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
Tu je dôležité správne zadať všetky adresáre, kde sa openssl nachádza (v našom prípade je to /opt/openssl/) a uistiť sa, že proces konfigurácie prebehne bez chýb.
Ak je konfigurácia úspešná, uvidíme riadok:
UPOZORNENIE: esni ESNI povolené, ale označené EXPERIMENTÁLNE. Používajte opatrne!
$ makePo úspešnom zostavení balíka použijeme špeciálny bash súbor z openssl na konfiguráciu a spustenie curl. Skopírujeme to do adresára s curl pre pohodlie:
cp /opt/openssl/esnistuff/curl-esni a vykonajte testovaciu https požiadavku na server cloudflare a súčasne zaznamenávajte pakety DNS a TLS vo Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/V odpovedi servera dostaneme okrem množstva ladiacich informácií z openssl a curl aj 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 znamená, že naša požiadavka bola úspešne doručená na cieľový server, vypočutá a spracovaná.
Teraz sa pozrime na dopravnú skládku vo wireshark, t.j. čo poskytovateľ DPI videl v tomto prípade.
Je vidieť, že curl sa najprv obrátil na DNS server pre verejný eSNI kľúč pre cloudflare server – TXT DNS požiadavka na _esni.cloudflare.com (balíček č. 13). Potom curl pomocou knižnice openssl odoslal požiadavku TLS 1.3 na server cloudflare, v ktorom bolo pole SNI zašifrované verejným kľúčom získaným v predchádzajúcom kroku (paket #22). Okrem poľa eSNI však paket SSL-hello obsahoval aj pole s obvyklým - otvoreným SNI, ktoré môžeme špecifikovať v ľubovoľnom poradí (v tomto prípade - ).
Toto otvorené pole SNI nebolo pri spracovaní servermi cloudflare žiadnym spôsobom zohľadnené a slúžilo iba ako maska pre poskytovateľa DPI. Server cloudflare prijal náš paket ssl-hello, dešifroval eSNI, extrahoval odtiaľ pôvodný SNI a spracoval ho, akoby sa nič nestalo (pri vývoji eSNI urobil všetko presne podľa plánu).
Jediné, čo sa dá v tomto prípade z pohľadu DPI zachytiť, je primárna DNS požiadavka na _esni.cloudflare.com. Požiadavku DNS sme však otvorili len preto, aby sme ukázali, ako tento mechanizmus funguje zvnútra.
Aby sme konečne vytiahli koberček spod DPI, používame už spomínaný mechanizmus DNS-over-HTTPS. Malé vysvetlenie – DOH je protokol, ktorý umožňuje chrániť sa pred útokom typu man-in-the-middle odoslaním požiadavky DNS cez HTTPS.
Spravme požiadavku znova, ale tentoraz dostaneme verejné kľúče eSNI cez protokol https, nie DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Výpis návštevnosti žiadosti je zobrazený na snímke obrazovky nižšie:
Je vidieť, že curl najprv pristupuje k serveru mozilla.cloudflare-dns.com cez protokol DoH (https pripojenie k serveru 104.16.249.249), aby od neho získal hodnoty verejných kľúčov pre šifrovanie SNI a potom do cieľa server, ktorý sa skrýva za doménou .
Okrem vyššie uvedeného DoH resolvera mozilla.cloudflare-dns.com môžeme využiť ďalšie obľúbené DoH služby, napríklad od známej zlej korporácie.
Spustíme nasledujúci dotaz:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/A dostávame 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 obrátili na zablokovaný server rutracker.nl pomocou DoH resolvera dns.google (tu nie je žiadny preklep, teraz má slávna korporácia vlastnú doménu prvej úrovne) a pokryli sme sa inou doménou, ktorá je striktne zakázané všetkým DPI blokovať pod trestom smrti. Na základe prijatej odpovede môžete pochopiť, že naša žiadosť bola úspešne spracovaná.
Ako dodatočnú kontrolu, či DPI poskytovateľa reaguje na otvorený SNI, ktorý prenášame ako krytie, môžeme požiadať rutracker.nl pod zámienkou nejakého iného zakázaného zdroja, napríklad iného „dobrého“ sledovača torrentov:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Zo servera nedostaneme odpoveď, pretože... naša požiadavka bude zablokovaná systémom DPI.
Krátky záver prvej časti
Podarilo sa nám demonštrovať funkčnosť eSNI pomocou openssl a curl a otestovať fungovanie frontingu domény založeného na eSNI. Rovnakým spôsobom môžeme prispôsobiť naše obľúbené nástroje, ktoré využívajú knižnicu openssl, aby fungovali „pod rúškom“ iných domén. Podrobnejšie o tom v našich ďalších článkoch.
Zdroj: hab.com