Hyrje
Sistemat moderne të korporatave për filtrimin e përmbajtjes, nga prodhues si Cisco, BlueCoat, FireEye, kanë shumë gjëra të përbashkëta me homologët e tyre më të fuqishëm - sistemet DPI, të cilat po implementohen në nivel kombëtar. Thelbi i funksionimit të të dyjave është që të monitorojnë trafikun e internetit të ardhur dhe të shkatur, dhe në bazë të listave të zeza/ të bardha, të marrin vendime për bllokimin e lidhjeve të internetit. Dhe duke qenë se të dyja mbështeten në parime të ngjashme, mënyrat e anashkalimit gjithashtu do të kenë shumë ngjasime.
Një nga teknologjitë që lejon të anashkalohet mjaft efektivisht si DPI ashtu edhe sistemet korporative është teknologjia e domain fronting. Thelbi i saj qëndron në faktin se ne shkojmë te një burim të bllokuar, duke u mbuluar pas një domene publik, me reputacion të mirë, i cili me siguri nuk do të bllokohet nga asnjë sistem, për shembull google.com.
ĂshtĂ« shkruar mjaft pĂ«r kĂ«tĂ« teknologji dhe janĂ« dhĂ«nĂ« shumĂ« shembuj. MegjithatĂ«, teknologjitĂ« e fundit si DNS-over-HTTPS dhe encrypted-SNI, si edhe versioni i ri i protokollit TLS 1.3, ofrojnĂ« njĂ« mundĂ«si pĂ«r tĂ« shqyrtuar njĂ« variant tjetĂ«r tĂ« domain fronting.
Le t'i hedhim një sy teknologjisë
Fillimisht, le të përcaktojmë disa koncepte bazë, në mënyrë që të gjithë të kenë një kuptim të qartë se kush është kush dhe përse është e nevojshme kjo. Ne përmendëm mekanizmin e eSNI, puna e së cilit do të shqyrtohet më vonë. Mekanizmi eSNI (encrypted Server Name Indication) është një variant i mbrojtur i SNI, i disponueshëm vetëm për protokollin TLS 1.3. Thelbi është të kriptojë, përfshirë informacionin mbi se në cilin domen po dërgohet kërkesa.
Tani le të shqyrtojmë funksionimin e mekanizmit eSNI në praktikë.
Supozoni se kemi njĂ« burim nĂ« internet, i cili bllokohet nga njĂ« zgjidhje moderne DPI (le tĂ« marrim pĂ«r shembull, torrent tracker-in e njohur â rutracker.nl). Kur pĂ«rpiqemi tĂ« hyjmĂ« nĂ« faqen e torrent tracker-it, ne shohim standardin e mesazhit tĂ« bllokimit nga provajderi:
Në faqen e RKN, ky domen në të vërtetë është i përfshirë në listat e bllokimeve:
Kur kërkoni informacionet whois - duket se domeni është "fshehur" pas shërbimit të shpërndarjes së mjeteve Cloudflare.
Por, përkundër "specialistëve" të RKN-së, punonjësit më teknikë të Beeline (ose të mësuar nga përvoja e hidhur e rregullatorit tonë të njohur) nuk e bllokuan thjesht faqen sipas adresës IP - por e futën në listën e ndalimeve saktësisht emri i domenit. Kjo është e lehtë për t'u verifikuar, nëse shihni se cilat domenet e tjera janë të fshehura pas këtij të njëjtit IP-adresën, për të vizituar njërin prej tyre dhe për të parë se qasja nuk është bllokuar:
Si ndodh kjo? Si e di DPI i ofruesit se në cilin nga domenet është duke shkuar shfletuesi im, duke qenë se të gjitha komunikimet ndodhin përmes protokollit https, dhe deri tani nuk kemi vënë re ndërrime të certifikatave https nga Beeline? A është ai ndonjë formë e parashikueshme apo më ndjekin?
Do të përpiqemi të përgjigjemi në këtë pyetje, duke shqyrtuar trafikun përmes wireshark
Në skrin, duket se fillimisht shfletuesi merr adresën IP të serverit nëpërmjet DNS, më pas ndodh përshkrimi standard TCP me serverin e destinacionit, dhe më pas shfletuesi përpiqet të krijojë një lidhje ssl me serverin. Në këtë mënyrë dërgon një paketë SSL Përshëndetje Klienti, i cili përmban emrin e domain-it origjinal në formë të hapur. Ky fushë është e nevojshme për serverin frontend të cloudflare për të drejtuar në mënyrë të saktë lidhjen. Këtu na kap DPI i ofruesit, duke ndërprerë lidhjen tonë. Në këtë rast, ne nuk marrim asnjë ndihmesë nga ofruesi dhe shohim një gabim standard të shfletuesit, sikur shfaqja të jetë çaktivizuar ose thjesht të mos funksionojë:
Tani le të aktivizojmë mekanizmin e eSNI në shfletues, siç është shkruar në udhëzim për Firefox :
Për këtë, hapim faqen e konfigurimit të Firefox about:config dhe aktivizojmë cilësimet e mëposhtme:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Pasi të bëjmë këtë, do të verifikojmë saktësinë e funksionimit të cilësimeve në faqen e cloudflare në lidhjes dhe do të provojmë trikun me tracker-in tonë të torrentit përsëri.
Voilà . Tracker-i ynë i preferuar u hap, pa asnjë VPN dhe server proxy. Tani le të shohim dumps-in e trafikut në wireshark, çfarë ndodhi.
Tani herĂ« paketi ssl client hello nuk pĂ«rmban qartĂ« domenin destinacion, por nĂ« vend tĂ« kĂ«saj ka njĂ« fushĂ« tĂ« re â encrypted_server_name â dhe aty gjendet vlera rutracker.nl, e cila mund tĂ« dekoduar vetĂ«m nga serveri frontend i cloudflare. Prandaj, DPI i ofruesit nuk ka asnjĂ« mundĂ«si tjetĂ«r pĂ«rveçse tĂ« lĂ«rĂ« tĂ« kalojĂ« kĂ«tĂ« trafik. Nuk ka asnjĂ« opsion tjetĂ«r pĂ«r encryption.
Tani kemi parĂ« se si funksionon teknologjia nĂ« shfletues â le t'i japim njĂ« shans pĂ«r ta aplikuar atĂ« nĂ« gjĂ«ra mĂ« specifike dhe interesante. Fillimisht, do ta mĂ«sojmĂ« curl se si tĂ« pĂ«rdorĂ« eSNI pĂ«r tĂ« punuar me TLS 1.3, dhe gjithashtu do tĂ« shohim si funksionon domen-fronting me eSNI.
Domen-fronting me eSNI
Duke marrë parasysh se curl për lidhjen me protokollin https përdor bibliotekën standarde openssl, së pari është e nevojshme të sigurojmë mbështetje për eSNI aty. Në degët master të openssl, mbështetja për eSNI aktualisht nuk ekziston, kështu që duhet të shkarkojmë një degë speciale openssl, ta kompilohem dhe ta instalojmë.
Klonojmë repositorin nga gitHub dhe e kompilohemi si zakonisht:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Më pas, do të klonojmë ruajtjen me curl dhe do të konfigurojmë kompaktimin e saj duke përdorur bibliotekën tonë të mbledhur 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ë tregoni saktësisht të gjitha katalogët ku ndodhet openssl (në rastin tonë, ky është /opt/openssl/) dhe të siguroheni që procesi i konfigurimit kalon pa gabime.
Nëse konfigurimi përfundon me sukses, do të shohim këtë varg:
WARNING: esni ESNI e aktivizuar por e Markuar si EXPERIMENTAL. PĂ«rdorni me kujdes!
$ makePas përfundimit të suksesshëm të paketës, do të përdorim një skedar të veçantë bash nga openssl për të konfiguruar dhe për të nisur curl. Do ta kopjojmë atë në katalogun me curl për lehtësi:
cp /opt/openssl/esnistuff/curl-esni dhe do të kryejmë një kërkesë https testuese në serverin cloudflare, duke regjistruar njëkohësisht DNS dhe paketa TLS në Wireshark.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Në përgjigjen e serverit, përveç shumë informacionit të ndihmës nga openssl dhe curl, do të marrë 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/
kjo tregon se kërkesa jonë u dorëzua me sukses te serveri i destinacionit, u dëgjua dhe u përpunua.
Tani le të shohim dump-in e trafikut në wireshark, domethënë, atë që pa në këtë rast DPI i ofruesit.
Duket se fillimisht curl iu drejtua serverit DNS pĂ«r çelĂ«sin publik eSNI pĂ«r serverin cloudflare â kĂ«rkesa TXT DNS pĂ«r _esni.cloudflare.com (paketi â13). Pastaj, duke pĂ«rdorur bibliotekĂ«n openssl, curl dĂ«rgoi njĂ« kĂ«rkesĂ« TLS 1.3 te serveri cloudflare, nĂ« tĂ« cilĂ«n fusha SNI ishte e enkriptuar me çelĂ«sin publik tĂ« marrĂ« nĂ« fazĂ«n e mĂ«parshme (paketi â22). Por, pĂ«rveç fushĂ«s eSNI, nĂ« paketĂ«n SSL-hello ishte futur gjithashtu njĂ« fushĂ« me SNI tĂ« zakonshĂ«m â tĂ« hapur, tĂ« cilin mund ta specifikojmĂ« nĂ« njĂ« rend tĂ« çfarĂ«do (nĂ« kĂ«tĂ« rast â www.hello-rkn.ru).
Kjo fushë e SNI të hapur nuk u mor parasysh gjatë përpunimit nga serverat cloudflare dhe ishte vetëm një maskë për DPI-në e ofruesit. Serveri cloudflare pranoi paketën tonë ssl-hello, e dekriptoi eSNI-në, e nxori SNI-në origjinale nga aty dhe e përpunoi atë siç ishte parashikuar (bëri gjithçka ashtu siç ishte planifikuar gjatë zhvillimit të eSNI).
E vetmi që mund të kapim në këtë rast nga këndvështrimi i DPI është kërkesa fillestare 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Ă« hequr pĂ«rfundimisht tokĂ«n nga poshtĂ« DPI, ne pĂ«rdorim mekanizmin e pĂ«rmendur tashmĂ« DNS-over-HTTPS. NjĂ« shpjegim i vogĂ«l â DOH Ă«shtĂ« protokolli qĂ« lejon mbrojtjen nga sulmi "njeri nĂ« mes" duke dĂ«rguar kĂ«rkesat DNS pĂ«rmes protokollit HTTPS.
Do ta kryejmë kërkesën përsëri, por këtë herë çelësat publikë eSNI do t'i marrim 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/Dumpi i trafikut të kërkesës është paraqitur në screenshot-in më poshtë:
Në të duket se fillimisht curl i drejtohet serverit mozilla.cloudflare-dns.com përmes protokollit DoH (konexioni https me serverin 104.16.249.249), për të marrë nga ata vlerat e çelësave publikë për enkriptimin e SNI, dhe pastaj drejtohet te serveri qëllim të mbuluar nga domeni. www.hello-rkn.ru.
Përveç rezolutorit DoH të përmendur më sipër mozilla.cloudflare-dns.com, ne gjithashtu mund të përdorim shërbime të tjera të njohura DoH, për shembull, nga korporata e famshme e së keqes.
Do ta realizojmë një kërkesë të tillë:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Dhe do të marrim një përgjigje:
< 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 një zgjidhës DoH dns.google (këtu nuk ka ndonjë gabim, tani korporata e njohur ka një domene të nivelit të parë) dhe u mbulua me një domene tjetër, bllokimi i të cilit është rreptësisht i ndaluar nga çdo DPI nën kërcënimin e dënimit me vdekje. Nga përgjigja e marrë, mund të kuptohet se kërkesa jonë u përpunua me sukses.
Si njĂ« kontroll tĂ« shtuar pĂ«r tĂ« parĂ« se si DPI e ofruesit reagon ndaj SNI tĂ« hapur, tĂ« cilin e dĂ«rgojmĂ« si mbulesĂ« â ne mund tĂ« bĂ«jmĂ« njĂ« kĂ«rkesĂ« pĂ«r rutracker.nl duke u mbrojtur me ndonjĂ« burim tjetĂ«r tĂ« ndaluar, pĂ«r shembull njĂ« tjetĂ«r 'torrenti i mirĂ«':
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Nuk do të marrim përgjigje nga serveri, pasi kërkesa jonë do të bllokohet nga sistemi DPI.
Një përfundim i vogël për pjesën e parë
Pra, na ka arritur të tregojmë funksionalitetin e eSNI me openssl dhe curl dhe të verifikojmë funksionin e domain fronting bazuar në eSNI. Po ashtu, mund të adaptojmë mjetet tona të preferuara që përdorin bibliotekën openssl për të punuar "në mënyrë të fshehtë" me domene të tjera. Më shumë rreth kësaj - në artikujt tanë të ardhshëm.
Burimi: habr.com
