TLS 1.3-n oinarritutako domeinuaren aurrealdea

Sarrera

Cisco, BlueCoat, FireEye bezalako fabrikatzaile entzutetsuen edukiak iragazteko sistema modernoek antzekotasun handia dute beren kontrako indartsuagoekin: nazio mailan aktiboki ezartzen ari diren DPI sistemak. Bien lanaren funtsa Interneteko sarrerako eta irteerako trafikoa ikuskatzea eta, zerrenda zuri/beltzean oinarrituta, Interneteko konexioa debekatzeko erabakia hartzea da. Eta biek beren lanaren oinarrietan antzeko printzipioetan oinarritzen direnez, horiek saihesteko metodoek ere komunean asko izango dute.

DPI eta sistema korporatiboak nahiko modu eraginkorrean saihesteko aukera ematen duen teknologietako bat domeinuari aurre egiteko teknologia da. Bere funtsa da blokeatutako baliabide batera joaten garela, izen ona duen beste domeinu publiko baten atzean ezkutatuta, eta hori, jakina, ez du blokeatuko sistemak, adibidez google.com-ek.

Artikulu dezente idatzi dira dagoeneko teknologia honi buruz eta adibide asko eman dira. Hala ere, DNS-over-HTTPS eta enkriptatutako SNI teknologia ezagunek eta berriki eztabaidatuek, baita TLS 1.3 protokoloaren bertsio berriak ere, domeinu-frontingerako beste aukera bat aztertzea ahalbidetzen dute.

Teknologia ulertzea

Lehenik eta behin, defini ditzagun oinarrizko kontzeptuak, denek nor den nor eta zergatik behar den hau guztia ulertzeko. eSNI mekanismoa aipatu dugu, eta horren funtzionamendua gehiago eztabaidatuko da. eSNI (zerbitzariaren izen-adierazpena enkriptatuta) mekanismoa SNIren bertsio segurua da, TLS 1.3 protokolorako soilik eskuragarri. Ideia nagusia, besteak beste, eskaera zein domeinutara bidaltzen den informazioa enkriptatzea da.

Ikus dezagun orain eSNI mekanismoak praktikan nola funtzionatzen duen.

Demagun DPI irtenbide moderno batek blokeatuta dagoen Interneteko baliabide bat dugula (har dezagun, adibidez, rutracker.nl torrent tracker ospetsua). Torrent tracker baten webgunera sartzen saiatzen garenean, hornitzailearen zirriborro estandarra ikusiko dugu baliabidea blokeatuta dagoela adierazten duena:

RKN webgunean domeinu hau geldiuneen zerrendetan agertzen da:

Whois-a kontsultatzen duzunean, domeinua bera Cloudflare hodeiko hornitzailearen atzean "ezkutatuta" dagoela ikus dezakezu.

Baina RKN-ko "espezialistek" ez bezala, Beelineko teknikari adituagoak diren langileek (edo gure erregulatzaile ospetsuaren esperientzia mingotsak irakatsitakoak) ez zuten ergelki webgunea IP helbidearen arabera debekatu, baina domeinu-izena gehitu zuten stop zerrendara. Erraz egiazta dezakezu IP helbide beraren atzean zer beste domeinu ezkutatuta dauden begiratzen baduzu, horietako bat bisitatu eta sarbidea ez dagoela blokeatuta ikusten baduzu:

Nola gertatzen da hau? Nola daki hornitzailearen DPIak zein domeinutan dagoen nire nabigatzailea, komunikazio guztiak https protokoloaren bidez egiten baitira eta oraindik ez baikara ohartu Beelineren https ziurtagirien ordezkapenik? Argi ikuslea da ala ni jarraitzen ari naiz?

Saia gaitezen galdera honi erantzuten trafikoari wireshark bidez begiratuz

Pantaila-argazkiak erakusten du lehenik arakatzaileak zerbitzariaren IP helbidea DNS bidez lortzen duela, gero TCP esku-emate estandarra gertatzen dela helmugako zerbitzariarekin eta, ondoren, arakatzaileak zerbitzariarekin SSL konexio bat ezartzen saiatzen da. Horretarako, SSL Client Hello pakete bat bidaltzen du, zeina iturburuko domeinuaren izena testu garbian daukana. Eremu hau behar du cloudflare frontend zerbitzariak konexioa behar bezala bideratzeko. Horra hor DPI hornitzaileak harrapatzen gaitu, gure konexioa hautsiz. Aldi berean, ez dugu hornitzailearen zirriborrorik jasotzen, eta arakatzailearen errore estandarra ikusten dugu webgunea desgaituta egongo balitz bezala edo besterik gabe funtzionatuko ez balu bezala:

Orain gaitu dezagun eSNI mekanismoa arakatzailean, argibideetan idatzitako moduan Firefox :
Horretarako Firefox konfigurazio orria irekiko dugu about: config eta aktibatu ezarpen hauek:

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

Horren ondoren, ezarpenak behar bezala funtzionatzen ari direla egiaztatuko dugu cloudflare webgunean. link eta proba dezagun berriro gure torrent trackerarekin trikimailua.

Voila. Gure jarraitzaile gogokoena VPN edo proxy zerbitzaririk gabe ireki zen. Ikus dezagun orain wireshark-eko trafiko-zabortegia zer gertatu den ikusteko.

Oraingoan, ssl client hello paketeak ez du esplizituki helmugako domeinua jasotzen, baina, horren ordez, eremu berri bat agertu da paketean - encrypted_server_name - hor dago rutracker.nl-ren balioa, eta cloudflare frontend zerbitzariak bakarrik deszifratu dezake. eremua. Eta hala bada, DPI hornitzaileak eskuak garbitu eta trafiko hori baimentzea beste aukerarik ez dauka. Enkriptatzearekin ez dago beste aukerarik.

Beraz, arakatzailean teknologiak nola funtzionatzen duen aztertu dugu. Orain saia gaitezen gauza zehatzago eta interesgarriagoetan aplikatzen. Lehenik eta behin, kizkur bera irakatsiko dugu eSNI erabiltzen TLS 1.3-rekin lan egiteko, eta aldi berean ikusiko dugu eSNIn oinarritutako domeinu-frontingak nola funtzionatzen duen.

Domeinu-frontea eSNIrekin

Curl-ek openssl liburutegi estandarra erabiltzen duela https protokoloaren bidez konektatzeko, lehenik eta behin eSNI laguntza eman behar dugu bertan. Openssl adar nagusietan oraindik ez dago eSNI euskarririk, beraz, openssl adar berezi bat deskargatu, konpilatu eta instalatu behar dugu.

GitHub-etik biltegia klonatzen dugu eta ohi bezala konpilatzen dugu:

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

$ make
$ cd esnistuff
$ make

Ondoren, biltegia curl-arekin klonatuko dugu eta konpilazioa konfiguratzen dugu konpilatutako openssl liburutegia erabiliz:

$ 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

Hemen garrantzitsua da openssl dagoen direktorio guztiak behar bezala zehaztea (gure kasuan, hau /opt/openssl/ da) eta ziurtatzea konfigurazio prozesua akatsik gabe egiten dela.

Konfigurazioa arrakastatsua bada, lerroa ikusiko dugu:

OHARRA: esni ESNI gaituta baina ESPERIMENTALA markatuta dago. Erabili kontuz!

$ make

Paketea ongi eraiki ondoren, openssl-eko bash fitxategi berezi bat erabiliko dugu curl konfiguratzeko eta exekutatzeko. Kopiatu ezazu direktoriora curl-arekin erosotasunerako:

cp /opt/openssl/esnistuff/curl-esni 

eta egin proba https eskaera cloudflare zerbitzariari, Wireshark-en DNS eta TLS paketeak aldi berean grabatzen dituzun bitartean.

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

Zerbitzariaren erantzunean, openssl eta curl-en arazketa-informazio askoz gain, HTTP erantzun bat jasoko dugu cloudflare-ren 301 kodearekin.

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/

horrek adierazten du gure eskaera helmugako zerbitzarira behar bezala entregatu dela, entzun eta prozesatu dela.

Ikus dezagun orain wireshark-eko trafiko-zabortegia, hau da. DPI hornitzaileak kasu honetan ikusi duena.

Ikus daiteke curl-ek DNS zerbitzarira jo zuela lehenik cloudflare zerbitzarirako eSNI gako publiko bat lortzeko - _esni.cloudflare.com-i TXT DNS eskaera (13. zk. paketea). Ondoren, openssl liburutegia erabiliz, curl-ek TLS 1.3 eskaera bidali zion cloudflare zerbitzariari, eta bertan SNI eremua aurreko urratsean lortutako gako publikoarekin (#22 paketea) zifratu zen. Baina, eSNI eremuaz gain, SSL-hello paketeak ohiko - open SNI duen eremu bat ere barne hartzen zuen, edozein ordenatan zehaztu dezakeguna (kasu honetan - www.hello-rkn.ru).

SNI eremu ireki hau ez zen inola ere kontuan hartu cloudflare zerbitzariek prozesatzen zutenean eta DPI hornitzailearen maskara gisa soilik balio izan zuen. Cloudflare zerbitzariak gure ssl-hello paketea jaso zuen, eSNIa deszifratu zuen, jatorrizko SNIa bertatik atera zuen eta ezer gertatu ez balitz bezala prozesatu zuen (eSNI garatzean aurreikusitako moduan egin zuen dena).

DPIren ikuspuntutik kasu honetan atzeman daitekeen gauza bakarra _esni.cloudflare.com-era DNS eskaera nagusia da. Baina DNS eskaera ireki genuen mekanismo honek barrutik nola funtzionatzen duen erakusteko soilik.

Azkenean alfonbra DPI azpitik ateratzeko, lehen aipatutako DNS-over-HTTPS mekanismoa erabiltzen dugu. Azalpen txiki bat - DOH gizon-erdiko eraso baten aurka babesteko aukera ematen duen protokoloa da DNS eskaera HTTPS bidez bidaliz.

Exekutatu dezagun eskaera berriro, baina oraingoan eSNI gako publikoak jasoko ditugu https protokoloaren bidez, ez DNS:

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

Trafiko-iraulketa eskaera beheko pantaila-argazkian agertzen da:

Ikusten denez, curl-ek mozilla.cloudflare-dns.com zerbitzarira sartzen du lehenik DoH protokoloaren bidez (https konexioa 104.16.249.249 zerbitzariarekin) haiengandik SNI enkriptatzeko gako publikoen balioak lortzeko, eta gero helmugara. zerbitzaria, domeinuaren atzean ezkutatuta www.hello-rkn.ru.

Goiko DoH konpontzailea mozilla.cloudflare-dns.com gain, beste DoH zerbitzu ezagun batzuk erabil ditzakegu, adibidez, korporazio gaizto ospetsuarenak.
Exekutatu dezagun hurrengo kontsulta:

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

Eta erantzuna jasoko dugu:

< 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

Kasu honetan, blokeatutako rutracker.nl zerbitzarira jo dugu, DoH ebatzailea dns.google erabiliz (hemen ez dago akatsik, orain korporazio ospetsuak bere lehen mailako domeinu propioa du) eta beste domeinu batekin estali ginen, zorrozki. debekatuta dago DPI guztiek heriotzaren penapean blokeatzea. Jasotako erantzunaren arabera, gure eskaera behar bezala prozesatu dela uler dezakezu.

Hornitzailearen DPI-k estalki gisa transmititzen dugun SNI irekiari erantzuten dion egiaztatzeko gehigarri gisa, rutracker.nl-i eskaera bat egin diezaiokegu debekatutako beste baliabide batzuen itxurapean, adibidez, beste torrent jarraitzaile "on" bat:

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

Ez dugu zerbitzariaren erantzunik jasoko, zeren... gure eskaera DPI sistemak blokeatuko du.

Lehenengo zatiari amaiera labur bat

Beraz, eSNIren funtzionaltasuna frogatu ahal izan genuen openssl eta curl erabiliz eta eSNIn oinarritutako domeinu-frontingaren funtzionamendua probatu genuen. Modu berean, openssl liburutegia erabiltzen duten gure tresna gogokoenak molda ditzakegu beste domeinu batzuen "mozorropean" lan egiteko. Honi buruzko xehetasun gehiago gure hurrengo artikuluetan.

Iturria: www.habr.com