TLS 1.3 põhine domeenifronting

Sissejuhatus

Moodne ettevõtte sisu filtreerimise süsteemid, nagu Cisco, BlueCoat ja FireEye, omavad palju ühist oma võimsamate kolleegidega — DPI süsteemidega, mis on laialdaselt kasutusele võetud riiklikul tasandil. Nende töö tuumik on sama: uurida saabuvat ja väljaminevat interneti liiklust ning mustade/valgete serverite põhjal otsustada internetiühenduse blokeerimise üle. Kuna mõlemad tuginevad oma töös sarnastele põhimõtetele, on ka nende ületamise viisidel palju ühist.

Üks tehnoloogiatest, mis võimaldab tõhusalt vältida nii DPI-d kui ka ettevõtte süsteeme, on domeenifrontimine. Selle olemus seisneb selles, et me pääseme blokeeritud ressursile, varjates end teise, avaliku domeeni, hea mainega, millel ei ole mingit süsteemi poolt blokeerimise ohtu, näiteks google.com.

Selle tehnoloogia kohta on juba kirjutatud piisavalt palju artikleid ja toodud esile palju näiteid. Kuid populaarsed ja viimastel aegadel arutelud teema DNS-over-HTTPS ja krüptitud SNI, samuti uus protokoll TLS 1.3 annavad võimaluse vaadelda veel ühte domeenide peitmise varianti.

Uurime tehnoloogiat

Alustame natuke põhimõistetega, et kõigil oleks arusaam, kes on kes ja miks see kõik vajalik on. Oleme maininud eSNI mehhanismi, mille tööle saab edaspidi lähemalt vaatama. eSNI (krüptitud Server Name Indication) on SNI kaitstud variant, mis on saadaval ainult protokolli TLS 1.3 jaoks. Põhimõte on selles, et krüptida ka teavet selle kohta, millisele domeenile päring saadetakse.

Nüüd vaatame eSNI mehhanismi tööd praktikas.

Oletame, et meil on internetiressurss, mis on blokeeritud kaasaegse DPI lahendusega (võtame näiteks kuulus torrentide jälgija — rutracker.nl). Kui proovime külastada torrentide jälgija saiti, näeme teenusepakkuja tavalist teavitust, et ressurss on blokeeritud:

RKNi lehelt on see domeen tõepoolest mustades nimekirjades:

Whois päringut tehes on näha, et domeen on „peidetud“ Cloudflare'i pilveteenuse pakkuja taha.

Kuid erinevalt RKN-i „spetsialistidest“ ei otsustanud tehniliselt paremini haritud töötajad Beeline'is (või kellel on olnud valusat kogemust meie tuntud regulaatoriga) lihtsalt IP-aadressi põhjal saiti blokeerida, vaid lisasid musta nimekirja just domeeninime. Selle tõelisusesse veendumiseks vaadake, millised teised domeenid on sama IP-aadressiga, külastage ühte neist ja näete, et juurdepääs ei ole blokeeritud:

Kuidas see nii juhtub? Kuidas teab teenusepakkuja DPI, kuhu minu brauser suundub, kui kõik suhtlused toimuvad https-protokolli kaudu, ja Beeline'i poolt sertifikaatide valevahetust me siiani pole märganud? Kas ta on kaugeleulatuv või jälgib keegi mind?

Proovime sellele küsimusele vastata, vaadates liiklust Wiresharki kaudu.

Ekraanipildil on näha, et esmalt saab brauser DNS-i kaudu serveri IP-aadresse, seejärel toimub standardne TCP kätlemine sihiserveriga, ja siis püüab brauser SSL-ühendust serveriga luua. Selleks edastab ta paketi SSL Client Hello, milles on algse domeeni nimi avatud kujul. See väli on vajalik cloudflare'i esirakenduse serverile, et korralikult suunata ühendust. Just siin tabab meid teenusepakkuja DPI, katkestades meie ühenduse. Sel juhul me ei saa teenusepakkujalt mingit tõkestust ja näeme standardset brauseri viga justkui sait oleks välja lülitatud või lihtsalt ei tööta:

Nüüd lülitame brauseris sisse eSNI mehhanismi, nagu on kirjutatud juhendis Firefox :
Selleks avame Firefoxi konfiguratsioonilehe about:config ja aktiveerime järgmised seaded:

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

Pärast seda kontrollime seadete õigsust cloudflare'i saidil lingi kaudu ja proovime meie torrent-trackeriga trikki veel kord.

Voilà. Meie lemmik tracker avanes, ilma igasuguste VPNide ja proksiserveriteta. Vaatame nüüd wireshark'is liiklusdummit, mis juhtus.

Sel korral ssl kliendi tervituse pakett ei sisalda selgesõnaliselt sihtdomeeni, vaid selle asemel on paketi koostises uus väli — encrypted_server_name — just seal paikneb väärtus rutracker.nl, ning seda välja suudab dekrüpteerida ainult Cloudflare'i frontend-server. Seega ei jää teenusepakkuja DPI-le muud üle, kui käed üles tõsta ja selline liiklus lubada. Teisi šifreerimise variante pole.

Nüüd, kui me oleme vaadanud, kuidas tehnoloogia brauseris töötab, proovime rakendada seda spetsiifilisematel ja huvitavatel viisidel. Esmalt õpetame curl'i kasutama eSNI-d TLS 1.3 puhul ning vaatame, kuidas toimib domeenifronting eSNI alusel.

Domeenifronting eSNI-ga

Kuna curl kasutab https-protokolli jaoks standardset OpenSSL teeki, peame kõigepealt tagama eSNI toe just seal. OpenSSL-i master-haru ei toeta veel eSNI-d, seega peame laadima alla erilise OpenSSL haru, selle kompileerima ja installima.

Kloonime GitHubi hoidla ja kompileerime nagu tavaliselt:

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

$ make
$ cd esnistuff
$ make

Seejärel kloonime curl'i reposti ja konfigureerime selle kompileerimise meie kompileeritud openssl teegi kasutamisega:

$ 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

Siin on oluline õigesti näidata kõik kataloogid, kus openssl asub (meie korral on see /opt/openssl/) ja veenduda, et konfigureerimisprotsess kulgeb ilma vigadeta.

Edasi, kui konfigureerimine õnnestus — näeme rida:

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

$ make

Pärast paketi eduka koostamise lõpetamist kasutame openssl'i koosseisust spetsiaalset bash-faili curl'i seadistamiseks ja käivitamiseks. Kopeerime selle curl'i katalooge mugavuse huvides:

cp /opt/openssl/esnistuff/curl-esni 

ja teeme testimise https-päringu cloudflare'i serverisse, samal ajal salvestades DNS ja TLS pakette Wireshark'i.

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

Serveri vastuses lisaks paljudele avastusinfodele openssl'ilt ja curl'ilt saame HTTP-vastuse 301 koodiga cloudflare'ilt.

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/

mis näitab, et meie päring on edukalt jõudnud sihtserverisse, kuulatud ja töödeldud.

Nüüd vaatame Wiresharkis liiklust, st mida nägi antud juhul teenusepakkuja DPI.

On näha, et esmalt küsis curl DNS-serverilt avalike eSNI võtmete kohta Cloudflare'i serveri jaoks – TXT DNS-küsimus _esni.cloudflare.com (pakett nr 13). Seejärel saatis curl, kasutades openssl-i teeki, TLS 1.3 päringu Cloudflare'i serverile, kus SNI väli oli krüpteeritud eelnevalt saadud avaliku võtmega (pakett nr 22). Kuid lisaks eSNI väljale oli SSL-hello paketi koostisesse lisatud veel ka tavapärase, avaliku SNI väli, mille saame määrata suvalises järjekorras (antud juhul – www.hello-rkn.ru).

Antud avaliku SNI väli ei mõjutanud Cloudflare'i serverites töötlemist ja see oli lihtsalt teenusepakkuja DPI jaoks maskeeriv. Cloudflare'i server võttis meie ssl-hello paketi vastu, dekrüpteeris eSNI, ekstrakteeris sealt algse SNI ja töötles selle nagu tavaliselt (tegi kõik just nii, nagu eSNI väljatöötamisel oli planeeritud).

Ainus, millele sellisel juhul DPI mõttes toetuda, on esmase DNS-päringu tegemine _esni.cloudflare.com. Kuid me tegime DNS-päringu avalikuks vaid selleks, et näidata, kuidas see mehhanism seestpoolt töötab.

DPI alt väljasaamiseks kasutame juba mainitud DNS-over-HTTPS mehhanismi. Väike selgitus – DOH on protokoll, mis kaitseb keskmise inimese rünnaku eest, edastades DNS-päringu HTTPS-protokolli kaudu.

Teeme päringu uuesti, kuid seekord saame avalikud eSNI võtmed HTTPS-protokolli, mitte DNS kaudu:

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

Päringu liikluse dump on esitatud alloleval ekraanipiltidel:

On näha, et esmalt pöördub curl serveri mozilla.cloudflare-dns.com poole DoH protokolli kaudu (HTTPS-ühendus serveriga 104.16.249.249), et saada neilt avalikud võtmed SNI krüpteerimiseks, ning seejärel juba sihtserveri poole, kaitstes end samas domeeni kaudu. www.hello-rkn.ru.

Lisaks eelnevale DoH resolvijale mozilla.cloudflare-dns.com saame kasutada ka teisi populaarseid DoH teenuseid, näiteks ühte kurikuulsast kurjast ettevõttest.
Teeme sellise päringu:

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

Ja saame vastuse:

< 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

Antud juhul pöördusime blokeeritud serveri rutracker.nl poole, kasutades DoH-resolutsiooni dns.google (siin pole trükiviga, nüüd on kuulsal korporatsioonil oma tippdomeen) ja kattisime end teise domeeniga, mille blokeerimine on kõigile DPI-dele rangelt keelatud surmaohuga. Saadud vastusest saab aru, et meie päring töötati edukalt läbi.

Lisaks selle kontrollimiseks, et teenusepakkuja DPI reageerib avatud SNI-le, mida me varjuna edastame — saame esitada päringu rutracker.nl-le, kattudes mõne muu keelatud ressursiga, näiteks teise "heade" torrentide jälgijaga:

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

Serverilt vastust ei saa, kuna meie päring blokeeritakse DPI-süsteemi poolt.

Lühike kokkuvõte esimesele osale

Nii õnnestus meil demonstreerida eSNI toimimist openssl ja curl abil ning kontrollida eSNI-põhise domeeni esiotsa töökindlust. Samamoodi saame kohandada oma lemmikinstrumente, mis kasutavad openssl raamatukogu, et töötada "varjatult" teiste domeenide all. Rohkem teavet selle kohta leiate meie järgmistest artiklitest.

Allikas: habr.com