Sissejuhatus
Kaasaegsetel ettevõtete sisu filtreerimissüsteemidel sellistelt tunnustatud tootjatelt nagu Cisco, BlueCoat, FireEye on üsna palju ühist võimsamate kolleegidega - DPI süsteemidega, mida riiklikul tasandil aktiivselt juurutatakse. Mõlema töö sisuks on sissetuleva ja väljamineva internetiliikluse kontrollimine ning mustade/valgete nimekirjade põhjal internetiühenduse keelustamise otsus. Ja kuna mõlemad tuginevad oma töö põhitõdedes sarnastele põhimõtetele, on ka nendest möödahiilimise meetoditel palju ühist.
Üks tehnoloogiatest, mis võimaldab üsna tõhusalt mööda minna nii DPI-st kui ka ettevõtte süsteemidest, on domeeni eesmise tehnoloogia. Selle olemus seisneb selles, et me läheme blokeeritud ressursile, peitudes teise, hea mainega avaliku domeeni taha, mida ilmselt ei blokeeri ükski süsteem, näiteks google.com.
Selle tehnoloogia kohta on juba kirjutatud üsna palju artikleid ja toodud palju näiteid. Populaarsed ja hiljuti arutatud DNS-üle-HTTPS ja krüpteeritud SNI-tehnoloogiad, samuti TLS 1.3 protokolli uus versioon võimaldavad aga kaaluda teist võimalust domeeni esinduseks.
Tehnoloogia mõistmine
Kõigepealt defineerime veidi põhimõisteid, et kõik saaksid aru, kes on kes ja milleks seda kõike vaja on. Mainisime eSNI mehhanismi, mille toimimist arutatakse edasi. Mehhanism eSNI (krüpteeritud serverinime indikatsioon) on SNI turvaline versioon, mis on saadaval ainult protokolli TLS 1.3 jaoks. Põhiidee on krüpteerida muuhulgas teave selle kohta, millisesse domeeni päring saadetakse.
Nüüd vaatame, kuidas eSNI mehhanism praktikas töötab.
Oletame, et meil on Interneti-ressurss, mille kaasaegne DPI-lahendus blokeerib (võtame näiteks kuulsa torrentide jälgija rutracker.nl). Kui proovime pääseda juurde torrenti jälgija veebisaidile, näeme teenusepakkuja standardset tünni, mis näitab, et ressurss on blokeeritud:
RKN-i veebisaidil on see domeen tegelikult loetletud stoppide loendites:
Kui küsite whois'i, näete, et domeen ise on pilveteenuse pakkuja Cloudflare'i taga "peidetud".
Kuid erinevalt RKN-i “spetsialistidest” ei keelanud Beeline'i tehniliselt taibukamad töötajad (või õpetasid meie kuulsa regulaatori kibe kogemus) saiti IP-aadressi järgi rumalalt ära, vaid lisasid domeeninime stopp-loendisse. Saate seda hõlpsalt kontrollida, kui vaatate, millised teised domeenid on sama IP-aadressi taga peidus, külastate mõnda neist ja näete, et juurdepääs pole blokeeritud:
Kuidas see juhtub? Kuidas teenusepakkuja DPI teab, millises domeenis minu brauser on, kuna kogu suhtlus toimub https-protokolli kaudu ja me pole veel märganud https-sertifikaatide asendamist Beeline'ilt? Kas ta on selgeltnägija või mind jälgitakse?
Proovime sellele küsimusele vastata, vaadates Wiresharki kaudu toimuvat liiklust
Ekraanipilt näitab, et esmalt saab brauser DNS-i kaudu serveri IP-aadressi, seejärel toimub standardne TCP-käepigistus sihtserveriga ja seejärel proovib brauser luua serveriga SSL-ühendust. Selleks saadab ta SSL Client Hello paketi, mis sisaldab selge tekstina lähtedomeeni nime. Seda välja nõuab cloudflare'i esiserver, et ühendus õigesti marsruutida. See on koht, kus teenusepakkuja DPI püüab meid kinni, katkestades meie ühenduse. Samal ajal ei saa me teenusepakkujalt ühtegi tünga ja näeme standardset brauseri viga, justkui sait on keelatud või lihtsalt ei tööta:
Nüüd lubame brauseris eSNI mehhanismi, nagu on kirjutatud juhistes :
Selleks avame Firefoxi konfiguratsioonilehe about: config ja aktiveerige 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, kas seaded töötavad pilvflare'i veebisaidil õigesti. ja proovime seda trikki oma torrentijälgijaga uuesti.
Voila. Meie lemmikjälgija avanes ilma VPN-i või puhverserveriteta. Vaatame nüüd Wiresharki liiklust, et näha, mis juhtus.
Seekord ei sisalda ssl-kliendi hello pakett otseselt sihtdomeeni, vaid selle asemel ilmus paketti uus väli - krüptitud_serveri_nimi - siin sisaldub rutracker.nl väärtus ja seda saab dekrüpteerida ainult cloudflare'i esiserver. valdkonnas. Ja kui nii, siis ei jää pakkujal DPI üle muud, kui käsi pesta ja sellist liiklust lubada. Krüpteerimisel pole muid võimalusi.
Niisiis, vaatasime, kuidas see tehnoloogia brauseris töötab. Nüüd proovime seda rakendada spetsiifilisemate ja huvitavamate asjade puhul. Ja kõigepealt õpetame sama lokki kasutama eSNI-d TLS 1.3-ga töötamiseks ja samal ajal näeme, kuidas eSNI-põhine domeenifront ise töötab.
Domeeni fronting eSNI-ga
Kuna curl kasutab https-protokolli kaudu ühenduse loomiseks standardset openssl teeki, peame esmalt pakkuma seal eSNI tuge. Openssl põhiharudes eSNI tugi veel puudub, seega peame alla laadima spetsiaalse openssl haru, selle kompileerima ja installima.
Kloonime hoidla GitHubist ja kompileerime nagu tavaliselt:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Järgmisena kloonime hoidla curl'iga ja konfigureerime selle kompileerimise, kasutades meie kompileeritud openssl teeki:
$ 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 määrata kõik kataloogid, kus openssl asub (meie puhul on see /opt/openssl/) ja veenduda, et konfiguratsiooniprotsess kulgeb vigadeta.
Kui seadistamine õnnestub, näeme rida:
HOIATUS: esni ESNI on lubatud, kuid märgitud EKSPERIMENTALSELT. Kasutage ettevaatlikult!
$ makePärast paketi edukat koostamist kasutame curli konfigureerimiseks ja käivitamiseks spetsiaalset bash-faili openssl-st. Kopeerime selle mugavuse huvides curl-iga kataloogi:
cp /opt/openssl/esnistuff/curl-esni ja esitage cloudflare'i serverile test https-päring, salvestades samal ajal DNS- ja TLS-pakette Wiresharkis.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Serveri vastuses saame lisaks suurele hulgale openssl ja curl silumisinfole ka HTTP vastuse koodiga 301 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 saadeti edukalt sihtserverisse, kuulati ära ja töödeldi.
Vaatame nüüd Wiresharkis liiklusprügi, st. mida pakkuja DPI sel juhul nägi.
On näha, et curl pöördus esmalt DNS-serveri poole, et saada pilvflare'i serveri avaliku eSNI-võti - TXT DNS-i päring aadressile _esni.cloudflare.com (pakett nr 13). Seejärel saatis curl openssl teeki kasutades cloudflare'i serverile TLS 1.3 päringu, milles SNI väli krüpteeriti eelmises etapis saadud avaliku võtmega (pakett nr 22). Kuid lisaks eSNI väljale sisaldas SSL-tere pakett ka välja tavalise - avatud SNI-ga, mida saame määrata mis tahes järjekorras (antud juhul - ).
Seda avatud SNI-välja ei võetud pilvflare'i serverite töötlemisel mingil viisil arvesse ja see toimis ainult pakkuja DPI maskina. Cloudflare server sai meie ssl-hello paketi vastu, dekrüpteeris eSNI, ekstraheeris sealt algse SNI ja töötles seda nii, nagu poleks midagi juhtunud (tegi kõik täpselt nii, nagu eSNI arendamisel ette nähtud).
Ainus asi, mida sel juhul DPI vaatepunktist tabada saab, on esmane DNS-i päring aadressile _esni.cloudflare.com. Kuid tegime DNS-i päringu avatuks ainult selleks, et näidata, kuidas see mehhanism seestpoolt töötab.
Et lõpuks DPI alt vaip välja tõmmata, kasutame juba mainitud DNS-over-HTTPS mehhanismi. Väike selgitus – DOH on protokoll, mis võimaldab kaitsta end-in-the-middle rünnaku eest, saates DNS päringu HTTPS-i kaudu.
Teostame päringu uuesti, kuid seekord saame avalikud eSNI-võtmed https-protokolli, mitte DNS-i kaudu:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Taotluse liiklustõrjund on näidatud alloleval ekraanipildil:
On näha, et curl pääseb esmalt DoH-protokolli kaudu (https-ühendus serveriga 104.16.249.249) serverile mozilla.cloudflare-dns.com, et saada neilt SNI-krüptimise avalike võtmete väärtused ja seejärel sihtkohta. server, peitub domeeni taha .
Lisaks ülaltoodud DoH lahendajale mozilla.cloudflare-dns.com saame kasutada teisi populaarseid DoH teenuseid, näiteks kuulsalt kurjalt ettevõttelt.
Käivitame järgmise 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
Sel juhul pöördusime blokeeritud serveri rutracker.nl poole, kasutades DoH lahendajat dns.google (siin pole kirjaviga, nüüd on kuulsal korporatsioonil oma esmatasandi domeen) ja katsime end teise domeeniga, mis on rangelt kõigi DPI-de blokeerimine surmavalu all on keelatud. Saadud vastuse põhjal saate aru, et meie taotlust menetleti edukalt.
Täiendava kontrollina, kas pakkuja DPI reageerib avatud SNI-le, mille me kattena edastame, saame teha rutracker.nl-le päringu mõne muu keelatud ressursi, näiteks mõne teise “hea” torrenti jälgija varjus:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Me ei saa serverilt vastust, kuna... DPI-süsteem blokeerib meie taotluse.
Lühike kokkuvõte esimesele osale
Nii saime demonstreerida eSNI funktsionaalsust openssl ja curl abil ning testida eSNI-l põhineva domeeni frontingi toimimist. Samamoodi saame kohandada oma lemmiktööriistu, mis kasutavad openssl teeki, töötama teiste domeenide varjus. Lisateavet selle kohta leiate meie järgmistest artiklitest.
Allikas: www.habr.com