Bevezetés
Az olyan neves gyártók modern vállalati tartalomszűrő rendszerei, mint a Cisco, BlueCoat, FireEye, meglehetősen sok közös vonást mutatnak erősebb társaikkal - a DPI rendszerekkel, amelyeket országos szinten is aktívan alkalmaznak. Mindkettő munkájának lényege, hogy megvizsgálják a bejövő és kimenő internetes forgalmat, és fekete-fehér listák alapján döntést hoznak az internetkapcsolat tiltásáról. És mivel munkájuk alapjaiban mindketten hasonló elvekre támaszkodnak, az ezek megkerülésének módszereiben is sok közös lesz.
Az egyik olyan technológia, amely lehetővé teszi a DPI és a vállalati rendszerek meglehetősen hatékony megkerülését, a domain-fronting technológia. Lényege, hogy egy blokkolt erőforráshoz megyünk, egy másik, jó hírű közkincs mögé bújva, amit nyilván semmilyen rendszer nem fog blokkolni, például a google.com.
Elég sok cikket írtak már erről a technológiáról, és számos példát hoztak. A népszerű és a közelmúltban tárgyalt DNS-over-HTTPS és titkosított SNI technológiák, valamint a TLS 1.3 protokoll új verziója azonban lehetővé teszi egy másik lehetőség megfontolását a domain fronting számára.
A technológia megértése
Először is definiáljunk egy kis alapfogalmat, hogy mindenki megértse, ki kicsoda és miért van erre szükség. Említettük az eSNI mechanizmust, melynek működéséről a továbbiakban még lesz szó. Az eSNI (titkosított kiszolgálónév-jelzés) mechanizmus az SNI biztonságos verziója, amely csak a TLS 1.3 protokollhoz érhető el. A fő ötlet az, hogy titkosítsák többek között azt az információt, hogy melyik tartományba küldik a kérést.
Most nézzük meg, hogyan működik az eSNI mechanizmus a gyakorlatban.
Tegyük fel, hogy van egy internetes erőforrásunk, amelyet egy modern DPI-megoldás blokkol (vegyük például a híres torrentkövetőt, a rutracker.nl-t). Amikor megpróbálunk elérni egy torrentkövető webhelyét, a szolgáltató szabványos csonkját látjuk, amely jelzi, hogy az erőforrás le van tiltva:
Az RKN webhelyén ez a domain valóban szerepel a stoplistákban:
Amikor lekérdezi a whois-t, láthatja, hogy maga a tartomány a felhőszolgáltató Cloudflare mögé van „rejtve”.
De az RKN „specialistáival” ellentétben a Beeline technikailag hozzáértőbb munkatársai (vagy híres szabályozónk keserű tapasztalatai alapján) nem ostoba módon tiltották le az oldalt IP-cím alapján, hanem a domain nevet a stoplistára adták. Ezt egyszerűen ellenőrizheti, ha megnézi, hogy ugyanazon IP-cím mögött milyen más domainek rejtőznek, felkeresi valamelyiket, és megnézi, hogy a hozzáférés nincs-e letiltva:
Hogyan történik ez? Honnan tudja a szolgáltató DPI-je, hogy a böngészőm melyik tartományban van, mivel minden kommunikáció a https protokollon keresztül történik, és még nem vettük észre a https-tanúsítványok cseréjét a Beeline-től? Tisztánlátó, vagy engem követnek?
Próbáljunk meg válaszolni erre a kérdésre a wiresharkon keresztüli forgalom vizsgálatával
A képernyőképen látható, hogy a böngésző először DNS-en keresztül szerzi meg a szerver IP-címét, majd egy szabványos TCP-kézfogás történik a célszerverrel, majd a böngésző megpróbál SSL kapcsolatot létesíteni a szerverrel. Ehhez egy SSL Client Hello csomagot küld, amely a forrástartomány nevét tartalmazza tiszta szöveggel. Ezt a mezőt a cloudflare előtér-kiszolgálónak meg kell adnia a kapcsolat megfelelő irányításához. Itt kap el minket a szolgáltató DPI, megszakítva a kapcsolatunkat. Ugyanakkor nem kapunk csonkot a szolgáltatótól, és azt a normál böngésző hibát látjuk, mintha az oldal le van tiltva, vagy egyszerűen nem működik:
Most engedélyezzük az eSNI-mechanizmust a böngészőben, ahogyan az utasításokban le van írva :
Ehhez megnyitjuk a Firefox konfigurációs oldalát about: config és aktiválja a következő beállításokat:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Ezt követően ellenőrizzük, hogy a beállítások megfelelően működnek-e a cloudflare webhelyen. és próbáljuk ki újra a trükköt a torrentkövetőnkkel.
Voálá. Kedvenc nyomkövetőnk VPN vagy proxyszerver nélkül nyílt meg. Nézzük meg most a wireshark forgalmi dumpját, hogy lássuk, mi történt.
Az ssl kliens hello csomag ezúttal nem kifejezetten tartalmazza a céltartományt, hanem egy új mező jelent meg a csomagban - titkosított_szerver_neve - itt található a rutracker.nl értéke, és ezt csak a cloudflare frontend szerver tudja visszafejteni. terület. És ha igen, akkor a szolgáltató DPI-nek nincs más választása, mint kezet mosni és engedélyezni az ilyen forgalmat. Nincs más lehetőség a titkosítással kapcsolatban.
Tehát megvizsgáltuk, hogyan működik a technológia a böngészőben. Most próbáljuk meg konkrétabb és érdekesebb dolgokra alkalmazni. Először is megtanítjuk ugyanezt a curl-t az eSNI használatára a TLS 1.3-mal való együttműködéshez, és egyúttal látni fogjuk, hogyan működik maga az eSNI-alapú domain fronting.
Domain fronting eSNI-vel
Tekintettel arra, hogy a curl a szabványos openssl könyvtárat használja a https protokollon keresztüli csatlakozáshoz, mindenekelőtt ott kell biztosítanunk az eSNI támogatást. Az openssl master ágakban még nincs eSNI támogatás, ezért le kell töltenünk egy speciális openssl ágat, azt le kell fordítani és telepíteni.
A GitHubból klónozzuk a tárolót, és a szokásos módon fordítjuk le:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Ezután klónozzuk a tárat curl-lel, és konfiguráljuk a fordítását a lefordított openssl könyvtárunk segítségével:
$ 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
Itt fontos helyesen megadni az összes könyvtárat, ahol az openssl található (esetünkben ez az /opt/openssl/), és győződjön meg arról, hogy a konfigurációs folyamat hiba nélkül megy végbe.
Ha a konfiguráció sikeres, a következő sort fogjuk látni:
FIGYELMEZTETÉS: az esni ESNI engedélyezve van, de KÍSÉRLETI jelzéssel. Használja óvatosan!
$ makeA csomag sikeres felépítése után egy speciális bash fájlt fogunk használni az openssl-ből a curl konfigurálásához és futtatásához. A kényelem kedvéért másoljuk be a curl könyvtárba:
cp /opt/openssl/esnistuff/curl-esni és küldjön egy teszt https kérést a cloudflare szervernek, miközben egyidejűleg rögzíti a DNS- és TLS-csomagokat a Wiresharkban.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/A szerver válaszában az openssl és curl sok hibakeresési információja mellett egy 301-es kódú HTTP választ is kapunk a cloudflare-től.
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/
ami azt jelzi, hogy kérésünket sikeresen kézbesítettük a célszerverre, meghallgattuk és feldolgoztuk.
Most nézzük meg a wireshark forgalmi dumpját, i.e. amit a szolgáltató DPI látott ebben az esetben.
Látható, hogy a curl először a DNS-kiszolgálóhoz fordult nyilvános eSNI-kulcsért a cloudflare-kiszolgálóhoz – egy TXT DNS-kérés a _esni.cloudflare.com-nak (13-as csomag). Ezután az openssl könyvtár használatával a curl TLS 1.3 kérést küldött a cloudflare szervernek, amelyben az SNI mezőt az előző lépésben kapott nyilvános kulccsal (22-es csomag) titkosították. De az SSL-hello csomag az eSNI mező mellett tartalmazott egy mezőt is a szokásos - nyitott SNI-vel, amit tetszőleges sorrendben megadhatunk (jelen esetben - ).
Ezt a nyitott SNI-mezőt semmilyen módon nem vették figyelembe, amikor a cloudflare szerverek feldolgozták, és csak a szolgáltató DPI maszkjaként szolgált. A cloudflare szerver megkapta az ssl-hello csomagunkat, dekódolta az eSNI-t, onnan kinyerte az eredeti SNI-t, és úgy dolgozta fel, mintha mi sem történt volna (az eSNI fejlesztésénél mindent pontosan úgy csinált, ahogy azt elterveztük).
Az egyetlen dolog, amit ebben az esetben meg lehet fogni DPI szempontból, az az elsődleges DNS-kérés a _esni.cloudflare.com-nak. De a DNS-kérést csak azért nyitottuk meg, hogy megmutassuk, hogyan működik ez a mechanizmus belülről.
Hogy végre kihúzzuk a szőnyeget a DPI alól, használjuk a már említett DNS-over-HTTPS mechanizmust. Egy kis magyarázat - A DOH egy protokoll, amely lehetővé teszi, hogy védelmet nyújtson a köztes támadások ellen DNS-kérés HTTPS-en keresztüli küldésével.
Hajtsuk végre újra a kérést, de ezúttal a nyilvános eSNI kulcsokat https protokollon keresztül kapjuk, nem DNS-en keresztül:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/A kérés forgalmi dumpja az alábbi képernyőképen látható:
Látható, hogy a curl először a DoH protokollon keresztül éri el a mozilla.cloudflare-dns.com szervert (https kapcsolat a szerverhez 104.16.249.249), hogy megszerezze tőlük az SNI titkosításhoz szükséges nyilvános kulcsok értékeit, majd a célállomást. szerver, a domain mögé bújva .
A fenti mozilla.cloudflare-dns.com DoH-feloldón kívül más népszerű DoH-szolgáltatásokat is igénybe vehetünk, például a híres gonosz cégtől.
Futtassuk a következő lekérdezést:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/És megkapjuk a választ:
< 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
Ebben az esetben a blokkolt rutracker.nl szerverhez fordultunk, a dns.google DoH megoldó segítségével (itt nincs elírás, most már saját első szintű domainnel rendelkezik a híres cég) és lefedtük magunkat egy másik domainnel, ami szigorúan tilos az összes DPI blokkolása halálfájdalom alatt. A kapott válasz alapján megértheti, hogy kérésünket sikeresen feldolgoztuk.
Annak további ellenőrzéseként, hogy a szolgáltató DPI-je válaszol-e a nyitott SNI-re, amelyet fedezetként továbbítunk, kérést intézhetünk a rutracker.nl-hez valamilyen más tiltott erőforrás, például egy másik „jó” torrentkövető leple alatt:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/A szervertől nem kapunk választ, mert... kérésünket a DPI rendszer blokkolja.
Rövid lezárás az első részhez
Így demonstrálhattuk az eSNI funkcionalitását openssl és curl segítségével, és tesztelhettük az eSNI alapú domain fronting működését. Ugyanígy adaptálhatjuk kedvenc, az openssl könyvtárat használó eszközeinket is, hogy más tartományok „álarca alatt” működjenek. Erről további részletek a következő cikkeinkben.
Forrás: will.com