Domena fronting na osnovi TLS 1.3

Uvod

Sodobni korporativni sistemi filtriranja vsebine, kot so tisti priznanih proizvajalcev, kot so Cisco, BlueCoat in FireEye, imajo precej skupnega z močnejšimi kolegi - sistemi DPI, ki se intenzivno uvajajo na nacionalni ravni. Osnova delovanja obeh je v pregledu vstopnega in izstopnega internetnega prometa ter na podlagi črnih/belih seznamov sprejemanje odločitev o prepovedi internetne povezave. Ker se pri obeh osnovna načela delovanja zanašajo na podobne principe, imajo tudi načini za obhod obeh sistemos veliko skupnega.

Ena izmed tehnologij, ki omogoča dovolj učinkovito obvladovanje tako DPI kot korporativnih sistemov, je tehnologija domenskega frontinga. Njena bistvo je, da dostopamo do blokiranega virov, pri tem pa se skrivamo za drugim, javnim domeno, ki ima dobro reputacijo in ki ne bo blokirana s strani nobenega sistema, na primer google.com.

O tej tehnologiji je bilo že napisanih dovolj člankov in prikazanih veliko primerov. Vendar pa priljubljene in v zadnjem času obravnavane tehnologije DNS-over-HTTPS in encrypted-SNI ter nova različica protokola TLS 1.3 omogočajo razmislek o še eni različici domenskega frontinga.

Poglejmo tehnologijo

Najprej si nekoliko razjasnimo osnovne pojme, da bo vsakdo razumel, kdo je kdo in zakaj je to potrebno. Omenili smo mehanizem eSNI, katerega delovanje bo obravnavano naprej. Mehanizem eSNI (encrypted Server Name Indication) je zaščitena različica SNI, dostopna samo za protokol TLS 1.3. Osnovna ideja je šifriranje tudi informacij o tem, na kateri domeni je poslan zahtevek.

Zdaj pa si poglejmo delovanje mehanizma eSNI v praksi.

Recimo, da imamo internetni vir, ki ga blokira sodobna rešitev DPI (vzemimo za primer znani torrent tracker — rutracker.nl). Ob poskusu obiska spletne strani torrent trackerja — vidimo standardno sporočilo ponudnika o tem, da je vir blokiran:

Na spletnem mestu RKDN je ta domena resnično navedena na seznamu blokiranih:

Pri poizvedbi whois je vidno, da je sama domena 'skrita' za oblačnim ponudnikom Cloudflare.

Vendar v nasprotju s "strokovnjaki" iz RKN, so bolj tehnično usposobljeni zaposleni iz Beeline (ali pa naučeni na grdem izkustvu našega znamenitega regulatorja) namesto da bi preprosto blokirali spletno mesto po IP-naslovu, vključili v črno listo prav domeno. To lahko enostavno vidimo, če pogledamo, katere še druge domene se skrivajo za tem IP-naslovom, obiščemo eno izmed njih in vidimo, da dostop ni blokiran:

Kako je to mogoče? Kako ve DPI ponudnika, na katero od domen gre moj brskalnik, ko pa vse komunikacije potekajo preko protokola https, mi pa zaenkrat nismo opazili nobenih sprememb https certifikatov iz Beeline? Ali ima morda sposobnosti jasnovidca ali sem pod nadzorom?

Poskusimo odgovoriti na to vprašanje, tako da pogledamo promet preko Wiresharka

Na posnetku je razvidno, da brskalnik najprej pridobi IP-naslov strežnika preko DNS, nato poteka standardni TCP handshake s ciljnim strežnikom, po tem pa brskalnik poskuša vzpostaviti ssl povezavo s strežnikom. Za to pošlje paket SSL Client Hello, v katerem je prisotno izvorno ime domene v jasni obliki. To polje je potrebno za frontend strežnik cloudflare, da lahko pravilno usmeri povezavo. Tu nas ujame DPI ponudnika, ker prekine našo povezavo. Pri tem ne dobimo nobene blokade s strani ponudnika, ampak vidimo standardno brskalniško napako, kot da je spletna stran izklopljena ali pa preprosto ne deluje:

Zdaj pa v brskalniku aktivirajmo mehanizem eSNI, kot je opisano v navodilih za Firefox :
Za to odpremo stran za konfiguracijo Firefox about:config in aktiviramo naslednje nastavitve:

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

Po tem bomo preverili pravilno delovanje nastavitev na spletni strani cloudflare po linku in poskusili še enkrat trik z našim torrent trackerjem.

Voilà. Naš ljubимый tracker se je odprl, brez kakršnih koli VPN in proxy strežnikov. Poglejmo sedaj zajem prometa v Wiresharku, kaj se je zgodilo.

Tokrat paket ssl client hello ne vsebuje jasno navedene ciljne domene, ampak namesto tega v paketu nastane novo polje — encrypted_server_name — tam je zapisano vrednost rutracker.nl in to polje lahko dekodira le frontend strežnik cloudflare. In če je tako, DPI ponudnika ne preostane nič drugega, kot da obriše roke in dovoli tak promet. In drugih možnosti s šifriranjem ni.

Torej, kako deluje tehnologija v brskalniku - smo pogledali. Zdaj pa poskusimo uporabiti to za bolj specifične in zanimive stvari. Za začetek bomo naučili curl uporabljati eSNI za delo s TLS 1.3 in obenem pogledali, kako deluje sam domain fronting na osnovi eSNI.

Domain fronting z eSNI

Glede na to, da curl za povezovanje preko protokola https uporablja standardno knjižnico openssl, nam mora najprej zagotoviti podporo za eSNI prav tam. V master vejah openssl trenutno ni podpore za eSNI, zato moramo prenesti posebno vejo openssl, jo sestaviti in namestiti.

Klono iz GitHuba in sestavimo kot običajno:

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

$ make
$ cd esnistuff
$ make

Nato - kloniramo repozitorij curl in konfiguriramo njegovo sestavljanje z uporabo naše zgrajene openssl knjižnice:

$ 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 pomembno pravilno navesti vse mape, kjer se nahaja openssl (v našem primeru je to /opt/openssl/) in poskrbeti, da postopek konfiguracije poteka brez napak.

V primeru uspešne konfiguracije - bomo videli vrstico:

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

$ make

Po uspešnem sestavljanju paketa bomo uporabili poseben bash datoteko iz sklopa openssl za nastavitev in zagon curl. Kopirajmo jo v mapo z curl za enostavno uporabo:

cp /opt/openssl/esnistuff/curl-esni 

in izvedemo testni https-napotek na strežniku cloudflare, hkrati pa zabeležimo DNS in TLS pakete v Wiresharku.

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

V odzivu strežnika poleg mnogih informacij za odpravljanje napak iz openssl in curl prejmemo HTTP-odgovor s kodo 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/

kar dokazuje, da je bila naša zahteva uspešno dostavljena na cilj, slišana in obdelana.

Zdaj si poglejmo prometni dump v wiresharku, tj. kaj je v tem primeru videl ponudnikov DPI.

Vidno je da je prvo curl pristupio DNS serveru za javnim eSNI ključem za cloudflare server — TXT DNS upit na _esni.cloudflare.com (paket br. 13). Zatim je, koristeći openssl biblioteku, curl poslao TLS 1.3 upit na cloudflare server u kojem je polje SNI bilo enkriptovano javnim ključem dobijenim u prethodnoj fazi (paket br. 22). Međutim, osim polja eSNI, u okviru SSL-hello paketa je dodato i polje sa običnim — otvorenim SNI, koje možemo navesti u proizvoljnom redosledu (u ovom slučaju — www.hello-rkn.ru).

Ovo polje otvorenog SNI nije imalo nikakvu ulogu u obradi od strane cloudflare servera i služilo je samo kao maska za provajderski DPI. Cloudflare server je prihvatio naš ssl-hello paket, dekriptovao eSNI, izvukao originalni SNI i obradio ga kao da se ništa nije desilo (učinio je sve onako kako je planirano prilikom razvijanja eSNI).

Jedina stvar na koju se u ovom slučaju može obratiti pažnja sa stanovišta DPI-a je primarni DNS upit na _esni.cloudflare.com. Međutim, učinili smo DNS upit otvorenim samo da bismo pokazali kako ovaj mehanizam funkcioniše iznutra.

Da bismo konačno izbacili tlo ispod nogu DPI-u, koristimo već pominjani mehanizam DNS-over-HTTPS. Malo objašnjenje – DOH – protokol koji omogućava zaštitu od napada "čovek u sredini" slanjem DNS upita putem HTTPS protokola.

Ponovićemo upit, ali ovoga puta ćemo javne eSNI ključeve dobiti putem https protokola, a ne DNS-a:

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

Dump saobraćaja upita je prikazan na screenschotu ispod:

Vidno je da prvo curl pristupa serveru mozilla.cloudflare-dns.com putem DoH (https veza na server 104.16.249.249), kako bi od njih dobio vrednosti javnih ključeva za enkripciju SNI, a zatim već pristupa serveru odredišta, prikrivajući se pritom domenom www.hello-rkn.ru.

Pored gore navedenog DoH rezolera mozilla.cloudflare-dns.com, možemo koristiti i druge popularne DoH servise, na primer, od poznate zle korporacije.
Izvršićemo takav upit:

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

I dobićemo odgovor:

< 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 tem primeru smo se obrnili na blokiran strežnik rutracker.nl, pri tem pa uporabili DoH-rešitelj dns.google (tukaj ni napake, zdaj ima znani korporaciji svoj vrhnji domen) in se skrili za drugim domenom, katerega blokiranje je strogo prepovedano vsem DPI pod grožnjo smrtne kazni. Iz prejetega odgovora lahko razumemo, da je bila naša zahteva uspešno obdelana.

Kot dodatno preverjanje, da avdio DPI reagira na odprti SNI, ki ga prenašamo kot pokritje — lahko izvedemo zahtevo na rutracker.nl, pri tem pa se skrijemo za nekim drugim prepovedanim virom, na primer drugim 'dobrim' torrent trackerjem:

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

Odgovora od strežnika ne bomo prejeli, saj bo naša zahteva blokirana s sistemom DPI.

Kratka zaključek prvega dela

Torej, uspelo nam je pokazati delovanje eSNI s pomočjo openssl in curl ter preveriti delovanje domen-frontalizacije, ki temelji na eSNI. Na enak način lahko prilagodimo naše najljubše pripomočke, ki uporabljajo knjižnico openssl, za delo 'pod pokritjem' drugih domen. Več o tem — v naših naslednjih člankih.

Izvor: habr.com