Përfaqësimi i domenit bazuar në TLS 1.3

Paraqitje

Sistemet moderne të filtrimit të përmbajtjes së korporatave nga prodhues të tillë të njohur si Cisco, BlueCoat, FireEye kanë mjaft të përbashkëta me homologët e tyre më të fuqishëm - sistemet DPI, të cilat po zbatohen në mënyrë aktive në nivel kombëtar. Thelbi i punës së të dyve është të inspektojnë trafikun hyrës dhe dalës të internetit dhe, bazuar në listat e zeza / të bardha, të marrin një vendim për të ndaluar lidhjen në internet. Dhe duke qenë se të dy mbështeten në parime të ngjashme në bazat e punës së tyre, metodat për t'i anashkaluar ato do të kenë gjithashtu shumë të përbashkëta.

Një nga teknologjitë që ju lejon të anashkaloni në mënyrë mjaft efektive si sistemet DPI ashtu edhe ato të korporatave është teknologjia e ballafaqimit me domenin. Thelbi i tij është se ne shkojmë në një burim të bllokuar, duke u fshehur pas një domeni tjetër publik me një reputacion të mirë, i cili padyshim nuk do të bllokohet nga asnjë sistem, për shembull google.com.

Tashmë janë shkruar mjaft artikuj rreth kësaj teknologjie dhe janë dhënë shumë shembuj. Megjithatë, teknologjitë e njohura dhe të diskutuara së fundmi DNS-mbi-HTTPS dhe SNI të koduara, si dhe versioni i ri i protokollit TLS 1.3, bëjnë të mundur shqyrtimin e një opsioni tjetër për ballafaqimin e domenit.

Kuptimi i teknologjisë

Së pari, le të përcaktojmë pak koncepte bazë në mënyrë që të gjithë të kuptojnë se kush është kush dhe pse është e nevojshme e gjithë kjo. Përmendëm mekanizmin eSNI, funksionimi i të cilit do të diskutohet më tej. Mekanizmi eSNI (Tregimi i emrit të serverit të koduar) është një version i sigurt i SNI, i disponueshëm vetëm për protokollin TLS 1.3. Ideja kryesore është që, ndër të tjera, të kriptohet informacioni se në cilin domen dërgohet kërkesa.

Tani le të shohim se si funksionon në praktikë mekanizmi eSNI.

Le të themi se kemi një burim interneti që është i bllokuar nga një zgjidhje moderne DPI (le të marrim, për shembull, gjurmuesin e famshëm të torrentit rutracker.nl). Kur përpiqemi të hyjmë në faqen e internetit të një gjurmuesi torrent, shohim cung standard të ofruesit që tregon se burimi është i bllokuar:

Në faqen e internetit të RKN, ky domen është renditur në listat e ndalimit:

Kur kërkoni whois, mund të shihni se vetë domeni është "i fshehur" pas ofruesit të cloud Cloudflare.

Por ndryshe nga "specialistët" nga RKN, punonjësit më të zgjuar teknikisht nga Beeline (ose të mësuar nga përvoja e hidhur e rregullatorit tonë të famshëm) nuk e ndaluan sitin me marrëzi sipas adresës IP, por shtuan emrin e domenit në listën e ndalimit. Mund ta verifikoni lehtësisht këtë nëse shikoni se cilat domene të tjera fshihen pas së njëjtës adresë IP, vizitoni njërën prej tyre dhe shihni që qasja nuk është e bllokuar:

Si ndodh kjo? Si e di DPI-ja e ofruesit se në cilin domen është shfletuesi im, pasi të gjitha komunikimet ndodhin përmes protokollit https dhe ne nuk kemi vërejtur ende zëvendësimin e certifikatave https nga Beeline? A është ai kthjelltësi apo jam duke u ndjekur?

Le të përpiqemi t'i përgjigjemi kësaj pyetjeje duke parë trafikun përmes wireshark

Pamja e ekranit tregon se së pari shfletuesi merr adresën IP të serverit nëpërmjet DNS, më pas ndodh një shtrëngim duarsh standard TCP me serverin e destinacionit dhe më pas shfletuesi përpiqet të krijojë një lidhje SSL me serverin. Për ta bërë këtë, ai dërgon një paketë SSL Client Hello, e cila përmban emrin e domenit burim në tekst të qartë. Kjo fushë kërkohet nga serveri frontend i cloudflare në mënyrë që të drejtojë saktë lidhjen. Këtu na kap ofruesi DPI, duke na prishur lidhjen. Në të njëjtën kohë, ne nuk marrim asnjë cung nga ofruesi dhe shohim gabimin standard të shfletuesit sikur faqja është e çaktivizuar ose thjesht nuk funksionon:

Tani le të aktivizojmë mekanizmin eSNI në shfletues, siç shkruhet në udhëzimet për Firefox :
Për ta bërë këtë hapim faqen e konfigurimit të Firefox-it about: config dhe aktivizoni cilësimet e mëposhtme:

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

Pas kësaj, ne do të kontrollojmë nëse cilësimet po funksionojnë siç duhet në faqen e internetit cloudflare. lidhje dhe le të provojmë mashtrimin me gjurmuesin tonë torrent përsëri.

Voila. Gjurmuesi ynë i preferuar u hap pa asnjë server VPN ose proxy. Le të shohim tani deponinë e trafikut në wireshark për të parë se çfarë ndodhi.

Këtë herë, paketa përshëndetje e klientit ssl nuk përmban në mënyrë eksplicite domenin e destinacionit, por në vend të kësaj, një fushë e re u shfaq në paketë - encrypted_server_name - këtu përmbahet vlera e rutracker.nl dhe vetëm serveri frontend cloudflare mund ta deshifrojë këtë fushë. Dhe nëse po, atëherë ofruesi DPI nuk ka zgjidhje tjetër veçse të lajë duart dhe të lejojë një trafik të tillë. Nuk ka opsione të tjera me kriptim.

Pra, ne shikuam se si funksionon teknologjia në shfletues. Tani le të përpiqemi ta zbatojmë atë në gjëra më specifike dhe interesante. Dhe së pari, ne do të mësojmë të njëjtën curl për të përdorur eSNI për të punuar me TLS 1.3, dhe në të njëjtën kohë do të shohim se si funksionon vetë frontimi i domenit të bazuar në eSNI.

Përfaqësimi i domenit me eSNI

Për shkak të faktit se curl përdor bibliotekën standarde openssl për t'u lidhur përmes protokollit https, para së gjithash duhet të ofrojmë mbështetje eSNI atje. Nuk ka ende mbështetje eSNI në degët kryesore të openssl, kështu që ne duhet të shkarkojmë një degë speciale openssl, ta përpilojmë dhe instalojmë atë.

Ne klonojmë depon nga GitHub dhe përpilojmë si zakonisht:

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

$ make
$ cd esnistuff
$ make

Më pas, ne klonojmë depon me curl dhe konfigurojmë përpilimin e tij duke përdorur bibliotekën tonë të përpiluar 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

Këtu është e rëndësishme të specifikoni saktë të gjitha drejtoritë ku ndodhet openssl (në rastin tonë, kjo është /opt/openssl/) dhe të siguroheni që procesi i konfigurimit të kalojë pa gabime.

Nëse konfigurimi është i suksesshëm, do të shohim rreshtin:

PARALAJMËRIM: esni ESNI është aktivizuar por është shënuar EKSPERIMENTAL. Përdorni me kujdes!

$ make

Pas ndërtimit të suksesshëm të paketës, ne do të përdorim një skedar të veçantë bash nga openssl për të konfiguruar dhe ekzekutuar curl. Le ta kopjojmë atë në drejtorinë me curl për lehtësi:

cp /opt/openssl/esnistuff/curl-esni 

dhe bëni një kërkesë testi https në serverin cloudflare, ndërkohë që regjistroni në të njëjtën kohë paketat DNS dhe TLS në Wireshark.

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

Në përgjigjen e serverit, përveç shumë informacioneve për korrigjimin e gabimeve nga openssl dhe curl, do të marrim një përgjigje HTTP me kodin 301 nga 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/

që tregon se kërkesa jonë është dorëzuar me sukses në serverin e destinacionit, është dëgjuar dhe përpunuar.

Tani le të shohim deponinë e trafikut në wireshark, d.m.th. çfarë pa në këtë rast ofruesi DPI.

Mund të shihet se curl fillimisht u kthye te serveri DNS për një çelës publik eSNI për serverin cloudflare - një kërkesë TXT DNS për _esni.cloudflare.com (paketë nr. 13). Më pas, duke përdorur bibliotekën openssl, curl dërgoi një kërkesë TLS 1.3 në serverin cloudflare në të cilin fusha SNI u kodua me çelësin publik të marrë në hapin e mëparshëm (paketa #22). Por, përveç fushës eSNI, paketa SSL-hello përfshinte gjithashtu një fushë me SNI-në e zakonshme - të hapur, të cilën mund ta specifikojmë në çdo mënyrë (në këtë rast - www.hello-rkn.ru).

Kjo fushë e hapur SNI nuk u mor parasysh në asnjë mënyrë kur përpunohej nga serverët cloudflare dhe shërbeu vetëm si maskë për DPI-në e ofruesit. Serveri cloudflare mori paketën tonë ssl-hello, deshifroi eSNI, nxori SNI-në origjinale prej andej dhe e përpunoi atë sikur asgjë të mos kishte ndodhur (bëri gjithçka saktësisht siç ishte planifikuar kur zhvillonte eSNI).

E vetmja gjë që mund të kapet në këtë rast nga pikëpamja DPI është kërkesa primare DNS për _esni.cloudflare.com. Por ne e bëmë kërkesën DNS të hapur vetëm për të treguar se si funksionon ky mekanizëm nga brenda.

Për të nxjerrë përfundimisht qilimin nga poshtë DPI, ne përdorim mekanizmin e përmendur tashmë DNS-mbi-HTTPS. Një shpjegim i vogël - DOH është një protokoll që ju lejon të mbroni kundër një sulmi njeri në mes duke dërguar një kërkesë DNS përmes HTTPS.

Le ta ekzekutojmë përsëri kërkesën, por këtë herë do të marrim çelësat publikë eSNI përmes protokollit https, jo DNS:

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

Deponimi i trafikut të kërkesës tregohet në pamjen e mëposhtme të ekranit:

Mund të shihet se curl së pari hyn në serverin mozilla.cloudflare-dns.com nëpërmjet protokollit DoH (lidhja https me serverin 104.16.249.249) për të marrë prej tyre vlerat e çelësave publikë për enkriptimin SNI, dhe më pas në destinacionin server, i fshehur pas domenit www.hello-rkn.ru.

Përveç zgjidhësit të mësipërm të DoH mozilla.cloudflare-dns.com, ne mund të përdorim shërbime të tjera të njohura të DoH, për shembull, nga korporata e famshme e keqe.
Le të ekzekutojmë pyetjen e mëposhtme:

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

Dhe marrim përgjigjen:

< 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

Në këtë rast, ne iu drejtuam serverit të bllokuar rutracker.nl, duke përdorur zgjidhësin DoH dns.google (këtu nuk ka asnjë gabim shkrimi, tani korporata e famshme ka domenin e saj të nivelit të parë) dhe u mbuluam me një domen tjetër, i cili është rreptësisht e ndaluar për të gjitha DPI-të të bllokojnë nën dhimbjen e vdekjes. Bazuar në përgjigjen e marrë, mund të kuptoni se kërkesa jonë u përpunua me sukses.

Si një kontroll shtesë që DPI i ofruesit i përgjigjet SNI-së së hapur, të cilën ne e transmetojmë si mbulesë, ne mund t'i bëjmë një kërkesë rutracker.nl nën maskën e një burimi tjetër të ndaluar, për shembull, një gjurmues tjetër "i mirë" torrent:

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

Ne nuk do të marrim përgjigje nga serveri, sepse... kërkesa jonë do të bllokohet nga sistemi DPI.

Një përfundim i shkurtër për pjesën e parë

Pra, ne ishim në gjendje të demonstronim funksionalitetin e eSNI duke përdorur openssl dhe curl dhe të testonim funksionimin e fronting të domenit bazuar në eSNI. Në të njëjtën mënyrë, ne mund të përshtatim mjetet tona të preferuara që përdorin bibliotekën openssl për të punuar "nën maskën" e domeneve të tjera. Më shumë detaje rreth kësaj në artikujt tanë të ardhshëm.

Burimi: www.habr.com