Domen-frontend na temelju TLS 1.3

Uvod

Moderne korporativne sisteme filtriranja sadržaja, od renomiranih proizvođača poput Cisco, BlueCoat, FireEye, povezuje mnogo sličnosti sa moćnijim srodnicima — DPI sistemima, koji se intenzivno implementiraju na nacionalnom nivou. Suština rada i jednih i drugih leži u pregledu ulaznog i izlaznog internet prometa i, na osnovu crnih/bijelih lista, donosi odluku o zabrani internet veze. Budući da se oboje oslanjaju na slične principe, i načini za zaobilaženje ovih prepreka će također imati mnogo zajedničkog.

Jedna od tehnologija koja omogućava efikasno zaobilaženje i DPI-a i korporativnih sistema je domen-frontalizacija. Njena suština je u tome što se pristupa blokiranoj resursi, skrivajući se iza drugog, javnog domena, s dobrom reputacijom, koji unaprijed neće biti blokiran od strane nijednog sistema, na primjer google.com.

O ovoj tehnologiji je već napisano mnogo članaka i navedeno mnogo primera. Međutim, popularne i u poslednje vreme raspravljane tehnologije DNS-over-HTTPS i encrypted-SNI, kao i nova verzija protokola TLS 1.3, pružaju mogućnost razmatranja još jedne varijante domen-frontalizacije.

Istražujemo tehnologiju

Prvo, malo ćemo definisati osnovne pojmove, kako bismo svi imali razumevanje ko je ko i zašto je sve to potrebno. Pomenuli smo mehanizam eSNI, čiji će rad biti detaljnije objašnjen. Mehanizam eSNI (encrypted Server Name Indication) — zaštićena verzija SNI, dostupna samo za protokol TLS 1.3. Osnovna suština je da šifruje, između ostalog, informacije o tome kojem domenu se šalje zahtev.

A sada ćemo razmotriti rad mehanizma eSNI u praksi.

Pretpostavimo da imamo internet resurs koji je blokiran savremenim DPI rešenjem (uzmimo za primer, poznati torrent tracker — rutracker.nl). Kada pokušamo da pristupimo sajtu torrent trackera — vidimo standardnu blokadu provajdera da je resurs blokiran:

Na sajtu RKN ovaj domen zaista se nalazi na listama zabrana:

Pri zahtevu whois — vidi se da je sam domen 'sakriven' iza cloud provajdera Cloudflare.

Ali za razliku od "stručnjaka" iz RKN-a, tehnički potkovaniji zaposlenici iz Beline (ili poučeni gorkim iskustvom našeg poznatog regulatora) nisu jednostavno blokirali web stranicu prema IP adresi, već su stavili na crnu listu upravo domen. To se lako može provjeriti ako pogledate koji se drugi domene skrivaju iza ovog istog IP adresu, posjetite jednu od njih i vidite da pristup nije blokiran:

Kako to može biti? Kako provajderski DPI saznaje na koji od domena odlazi moj preglednik, budući da se sve komunikacije odvijaju putem protokola https, a ne primjećujemo da Belin manipulira https certifikatima? Je li on vidovnjak ili me netko prati?

Pokušajmo odgovoriti na ovo pitanje, pogledavši promet kroz Wireshark.

Na snimci ekrana vidimo da pregledač prvo dobiva IP adresu servera preko DNS-a, zatim dolazi do standardnog TCP rukovanja s odredišnim serverom, a nakon toga preglednik pokušava uspostaviti ssl vezu sa serverom. Da bi to učinio, šalje paket SSL Client Hello, u kojem se nalazi naziv izvorne domene u otvorenom obliku. Ovo polje je potrebno frontend serveru cloudflare kako bi ispravno usmjerio vezu. Tu nas hvata provajderski DPI, prekinuvši našu vezu. Pri tome ne primamo nikakvu obavijest od provajdera, te vidimo standardnu pogrešku preglednika kao da je stranica isključena ili jednostavno ne radi:

Sada uključimo mehanizam eSNI u pregledniku, kako je opisano u uputama za Firefox :
Zato otvaramo stranicu konfiguracije Firefoxa about:config i aktiviramo sljedeće postavke:

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

Nakon toga ćemo provjeriti ispravnost rada postavki na web stranici cloudflare putem vezi i pokušati trik s našim torrent trackerom još jednom.

Evo ga. Naš omiljeni tracker se otvorio, bez ikakvih VPN-a i proxy servera. Sada pogledajmo dump prometa u Wiresharku, što se dogodilo.

Ovaj put paket ssl client hello ne sadrži izravno odredišnu domenu, već se u paketu pojavilo novo polje — encrypted_server_name — upravo tamo se nalazi vrijednost rutracker.nl, a to polje može dešifrirati samo frontend server cloudflare. Ako je tako, provajderski DPI nema nikakvu drugu mogućnost nego oprati ruke i dopustiti takav promet. A nema drugih opcija s enkripcijom.

Dakle, kako tehnologija funkcioniše u pretraživaču — to smo istražili. Sada hajde da pokušamo da je primenimo na konkretnije i zanimljivije stvari. Za početak, naučićemo kako koristiti curl uz eSNI za rad sa TLS 1.3, a istovremeno ćemo videti kako funkcioniše sam domen-fronting zasnovan na eSNI.

Domen-fronting sa eSNI

S obzirom na to da curl za povezivanje preko https protokola koristi standardnu openssl biblioteku, pre svega, potrebno je osigurati podršku za eSNI upravo tamo. U master granama openssl još uvek nema podrške za eSNI, pa ćemo morati preuzeti posebnu granу openssl, da je iskompajliramo i instaliramo.

Klonićemo repozitorijum sa GitHub-a i kompajlirati kao i obično:

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

$ make
$ cd esnistuff
$ make

Zatim — kloniramo repozitorijum sa curl-a i konfigurišemo njegovu kompilaciju koristeći našu sakupljenu openssl biblioteku:

$ 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

Ovde je važno pravilno navesti sve direktorijume u kojima se nalazi openssl (u našem slučaju — to je /opt/openssl/) i osigurati da proces konfiguracije prođe bez grešaka.

U slučaju uspešne konfiguracije — videćemo red:

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

$ make

Nakon uspešne izrade paketa iskoristićemo poseban bash fajl iz sastava openssl za podešavanje i pokretanje curl-a. Kopiraćemo ga u direktorijum sa curl-om radi lakše upotrebe:

cp /opt/openssl/esnistuff/curl-esni 

i izvršićemo testni https zahteva na cloudflare server, istovremeno beležeći DNS i TLS pakete u Wireshark-u.

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

U odgovoru servera, pored mnoštva informacija za debagovanje od openssl i curl-a, dobićemo HTTP odgovor sa kodom 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/

što ukazuje na to da je naš zahtev uspešno dostavljen do odredišnog servera, čuo i obrađen.

Sada hajde da pogledamo snimak saobraćaja u Wireshark-u, tj. šta je u ovom slučaju video providerov DPI.

Vidljivo je da je prvo curl kontaktirao DNS poslužitelj za javnim eSNI ključem za cloudflare poslužitelj — TXT DNS upit na _esni.cloudflare.com (paket br. 13). Zatim, koristeći openssl biblioteku, curl je poslao TLS 1.3 upit na cloudflare poslužitelj u kojem je SNI polje bilo šifrirano javnim ključem dobivenim u prethodnoj fazi (paket br. 22). Međutim, osim eSNI polja, u SSL-hello paketu umetnuto je i polje s običnim — otvorenim SNI, koje možemo odrediti u proizvoljnom redoslijedu (u ovom slučaju — www.hello-rkn.ru).

Ovo polje otvorenog SNI nije se uzimalo u obzir prilikom obrade od strane cloudflare poslužitelja i samo je služilo kao maskiranje za DPI pružatelja usluga. Cloudflare poslužitelj je prihvatio naš ssl-hello paket, dešifrirao eSNI, izvukao iz njega originalni SNI i obradio ga kao da se ništa nije dogodilo (učinio je sve upravo onako kako je planirano tijekom razvoja eSNI).

Jedina stvar na koju se može obratiti pažnja s aspekta DPI-a je prvotni DNS upit na _esni.cloudflare.com. No, učinili smo DNS upit otvorenim samo kako bismo pokazali kako ovaj mehanizam radi iznutra.

Da bismo konačno srušili temelje DPI-a, koristimo već spomenuti mehanizam DNS-over-HTTPS. Mali podsjetnik – DOH – protokol koji omogućuje zaštitu od napada "čovjeka u sredini" slanjem DNS upita preko HTTPS protokola.

Ponovit ćemo upit, ali ovaj put javne eSNI ključeve dobit ćemo 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/

Damp prometa upita prikazan je na slici ispod:

Vidljivo je da prvo curl pristupa poslužitelju mozilla.cloudflare-dns.com putem DoH protokola (https veza na poslužitelj 104.16.249.249) kako bi od njih dobio vrijednosti javnih ključeva za šifriranje SNI, a zatim se povezuje s odredišnim poslužiteljem, skrivajući se pritom iza domene www.hello-rkn.ru.

Osim gore navedenog DoH resolvera mozilla.cloudflare-dns.com, možemo koristiti i druge popularne DoH usluge, na primjer, iz poznate zle korporacije.
Izvršimo takav zahtjev:

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

I dobit ć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

U ovom slučaju pristupili smo blokiranom serveru rutracker.nl koristeći DoH resolver dns.google (nema greške, sada slavni korporacija ima svoju domenu prvog nivoa) i prikrili se već drugom domenom, čije blokiranje je strogo zabranjeno svim DPI-jevima pod prijetnjom smrtnog kazne. Po dobijenom odgovoru možemo shvatiti da je naš zahtev uspešno obrađen.

Kao dodatna provera da li provajderski DPI reaguje na otvoreni SNI, koji šaljemo kao prikrivač — možemo izvršiti zahtev ka rutracker.nl prikrivajući se nekim drugim zabranjenim resursima, na primer, drugim 'dobrim' torrent trackerima:

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

Odgovor od servera nećemo dobiti, jer će naš zahtev biti blokiran DPI sistemom.

Malo zaključak prve delove

Dakle, uspeli smo pokazati funkcionalnost eSNI pomoću openssl i curl i proveriti rad domen-frontinga zasnovanog na eSNI. Na isti način možemo prilagoditi naše omiljene alate koji koriste openssl biblioteku za rad 'pod prikrivačem' drugih domena. Više o tome u našim narednim člancima.

Izvor: habr.com