Predstavitev
Sodobni korporativni sistemi za filtriranje vsebin priznanih proizvajalcev, kot so Cisco, BlueCoat, FireEye, imajo kar nekaj skupnega s svojimi zmogljivejšimi kolegi - sistemi DPI, ki se aktivno uvajajo na nacionalni ravni. Bistvo delovanja obeh je pregledovanje dohodnega in odhodnega internetnega prometa ter na podlagi črnih/belih seznamov sprejetje odločitve o prepovedi internetne povezave. In ker oba v osnovah svojega dela slonita na podobnih načelih, bodo imele tudi metode za njihovo izogibanje veliko skupnega.
Ena od tehnologij, ki vam omogoča, da precej učinkovito zaobidete tako DPI kot korporativne sisteme, je tehnologija domene. Njegovo bistvo je, da gremo na blokiran vir, ki se skriva za drugo, javno domeno z dobrim ugledom, ki je očitno ne bo blokiral noben sistem, na primer google.com.
O tej tehnologiji je bilo napisanih že kar nekaj člankov in navedenih je bilo veliko primerov. Vendar priljubljeni in nedavno razpravljani tehnologiji DNS-over-HTTPS in šifrirani SNI, kot tudi nova različica protokola TLS 1.3, omogočata razmisliti o drugi možnosti za fronting domene.
Razumevanje tehnologije
Najprej malo definirajmo osnovne pojme, da bo vsakdo razumel, kdo je kdo in zakaj je vse to potrebno. Omenili smo mehanizem eSNI, o delovanju katerega bomo še govorili. Mehanizem eSNI (encrypted Server Name Indication) je varna različica SNI, ki je na voljo samo za protokol TLS 1.3. Bistvo je med drugim šifriranje informacij o tem, na katero domeno je poslana zahteva.
Zdaj pa poglejmo, kako mehanizem eSNI deluje v praksi.
Recimo, da imamo internetni vir, ki ga blokira sodobna rešitev DPI (vzemimo, na primer, slavni torrent tracker rutracker.nl). Ko poskušamo dostopati do spletnega mesta sledilnika torrentov, vidimo standardno škrbino ponudnika, ki označuje, da je vir blokiran:
Na spletni strani RKN je ta domena dejansko uvrščena na stop sezname:
Ko poizvedujete whois, lahko vidite, da je sama domena »skrita« za ponudnikom oblaka Cloudflare.
Toda za razliko od "strokovnjakov" iz RKN bolj tehnično podkovani uslužbenci Beeline (ali poučeni z grenkimi izkušnjami našega slavnega regulatorja) spletnega mesta niso neumno prepovedali po naslovu IP, ampak so ime domene dodali na stop listo. To lahko preprosto preverite, če pogledate, katere druge domene se skrivajo za istim naslovom IP, obiščete eno od njih in vidite, da dostop ni blokiran:
Kako se to zgodi? Kako DPI ponudnika ve, na kateri domeni je moj brskalnik, saj vsa komunikacija poteka preko https protokola, zamenjave https certifikatov Beeline pa še nismo opazili? Ali je jasnoviden ali mi sledijo?
Poskusimo odgovoriti na to vprašanje s pogledom na promet prek wiresharka
Posnetek zaslona prikazuje, da brskalnik najprej pridobi naslov IP strežnika prek DNS, nato pride do standardnega rokovanja TCP s ciljnim strežnikom, nato pa brskalnik poskuša vzpostaviti povezavo SSL s strežnikom. Da bi to naredil, pošlje paket SSL Client Hello, ki vsebuje ime izvorne domene v čistem besedilu. To polje zahteva čelni strežnik cloudflare za pravilno usmerjanje povezave. Tu nas ujame ponudnik DPI in prekine našo povezavo. Hkrati od ponudnika ne prejmemo nobene škrbine in vidimo standardno napako brskalnika, kot da je spletno mesto onemogočeno ali preprosto ne deluje:
Zdaj pa omogočimo mehanizem eSNI v brskalniku, kot je zapisano v navodilih za :
Za to odpremo konfiguracijsko stran Firefoxa about: config in aktivirajte 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, ali nastavitve na spletnem mestu cloudflare delujejo pravilno. in poskusimo znova z našim sledilnikom torrentov.
Voila. Naš najljubši sledilnik se je odprl brez VPN ali proxy strežnikov. Zdaj pa poglejmo prometno deponijo v Wiresharku, da vidimo, kaj se je zgodilo.
Tokrat pozdravni paket odjemalca ssl ne vsebuje eksplicitno ciljne domene, temveč se je v paketu pojavilo novo polje - encrypted_server_name - tukaj je vrednost rutracker.nl in le čelni strežnik cloudflare lahko to dešifrira polje. In če že, potem ponudniku DPI ne preostane drugega, kot da si umije roke in dovoli tak promet. Pri šifriranju ni drugih možnosti.
Torej, pogledali smo, kako tehnologija deluje v brskalniku. Zdaj pa ga poskusimo uporabiti za bolj specifične in zanimive stvari. In najprej bomo isti curl naučili uporabljati eSNI za delo s TLS 1.3, hkrati pa bomo videli, kako deluje sam fronting domene, ki temelji na eSNI.
Fronting domene z eSNI
Ker curl uporablja standardno knjižnico openssl za povezovanje preko https protokola, moramo najprej tam zagotoviti podporo za eSNI. V glavnih vejah openssl še ni podpore za eSNI, zato moramo prenesti posebno vejo openssl, jo prevesti in namestiti.
Repozitorij kloniramo iz GitHuba in prevedemo kot običajno:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Nato kloniramo repozitorij s curl in konfiguriramo njegovo kompilacijo z našo prevedeno knjižnico 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
Pri tem je pomembno, da pravilno navedete vse imenike, kjer se nahaja openssl (v našem primeru je to /opt/openssl/) in poskrbite, da konfiguracijski proces poteka brez napak.
Če je konfiguracija uspešna, bomo videli vrstico:
OPOZORILO: esni ESNI omogočen, vendar označen s EKSPERIMENTALNO. Uporabljajte previdno!
$ makePo uspešni izgradnji paketa bomo uporabili posebno datoteko bash iz openssl za konfiguracijo in zagon curl. Kopirajmo ga v imenik s curl za udobje:
cp /opt/openssl/esnistuff/curl-esni in naredite testno zahtevo https do strežnika cloudflare, hkrati pa snemajte pakete DNS in TLS v Wiresharku.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/V odgovoru strežnika bomo poleg številnih informacij o odpravljanju napak iz openssl in curl prejeli odgovor HTTP s kodo 301 iz cloudflareja.
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 pomeni, da je bila naša zahteva uspešno dostavljena ciljnemu strežniku, slišana in obdelana.
Zdaj pa poglejmo deponijo prometa v wiresharku, tj. kaj je v tem primeru videl ponudnik DPI.
Vidimo, da se je curl najprej obrnil na DNS strežnik za javni ključ eSNI za strežnik cloudflare - TXT DNS zahtevo na _esni.cloudflare.com (paket št. 13). Nato je curl s pomočjo knjižnice openssl strežniku cloudflare poslal zahtevo TLS 1.3, v kateri je bilo polje SNI šifrirano z javnim ključem, pridobljenim v prejšnjem koraku (paket #22). Vendar pa je paket SSL-hello poleg polja eSNI vključeval tudi polje z običajnim - odprtim SNI, ki ga lahko podamo v poljubnem vrstnem redu (v tem primeru - ).
To odprto polje SNI ni bilo na noben način upoštevano pri obdelavi s strežniki cloudflare in je služilo le kot maska za DPI ponudnika. Strežnik cloudflare je prejel naš paket ssl-hello, dešifriral eSNI, od tam izvlekel izvirni SNI in ga obdelal, kot da se ni nič zgodilo (vse je naredil točno tako, kot je bilo načrtovano pri razvoju eSNI).
Edina stvar, ki jo je v tem primeru mogoče ujeti z vidika DPI, je primarna zahteva DNS za _esni.cloudflare.com. Vendar smo naredili zahtevo DNS odprto samo zato, da pokažemo, kako ta mehanizem deluje od znotraj.
Da končno potegnemo preprogo izpod DPI, uporabimo že omenjeni mehanizem DNS-over-HTTPS. Majhna razlaga - DOH je protokol, ki vam omogoča zaščito pred napadom človeka v sredini s pošiljanjem zahteve DNS prek HTTPS.
Ponovno izvedemo zahtevo, vendar bomo tokrat javne ključe eSNI prejeli preko https protokola, ne DNS:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Izpis prometa zahteve je prikazan na spodnjem posnetku zaslona:
Vidimo, da curl najprej dostopa do strežnika mozilla.cloudflare-dns.com prek protokola DoH (https povezava s strežnikom 104.16.249.249), da od njih pridobi vrednosti javnih ključev za šifriranje SNI, nato pa do cilja. strežnik, ki se skriva za domeno .
Poleg zgornjega razreševalnika DoH mozilla.cloudflare-dns.com lahko uporabimo tudi druge priljubljene storitve DoH, na primer znane zlobne korporacije.
Zaženimo naslednjo poizvedbo:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/In dobimo 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 blokirani strežnik rutracker.nl z DoH razreševalcem dns.google (tu ni nobene tipkarske napake, zdaj ima slavna korporacija svojo prvonivojsko domeno) in se pokrili z drugo domeno, ki je strogo prepovedano blokirati vse DPI pod grožnjo smrti. Na podlagi prejetega odgovora lahko razumete, da je bila naša zahteva uspešno obdelana.
Kot dodatno preverjanje, ali se ponudnikov DPI odziva na odprti SNI, ki ga posredujemo kot krinko, lahko na rutracker.nl pošljemo zahtevo pod krinko kakšnega drugega prepovedanega vira, na primer drugega "dobrega" sledilnika torrentov:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Od strežnika ne bomo prejeli odgovora, ker... našo zahtevo bo blokiral sistem DPI.
Kratek zaključek prvega dela
Tako smo lahko prikazali funkcionalnost eSNI z uporabo openssl in curl ter preizkusili delovanje frontinga domene na podlagi eSNI. Na enak način lahko prilagodimo naša priljubljena orodja, ki uporabljajo knjižnico openssl, da delujejo »pod krinko« drugih domen. Več o tem v naših naslednjih člankih.
Vir: www.habr.com