Bevezetés
A modern corporate content filtering system from renowned manufacturers such as Cisco, BlueCoat, and FireEye shares a lot in common with their more powerful counterparts — DPI systems, which are being actively implemented at the national level. The essence of both is to inspect incoming and outgoing internet traffic and, based on black/white lists, decide whether to block an internet connection. And since both rely on similar principles in their operation, the methods of bypassing them will also have much in common.
One of the technologies that allows for effectively bypassing both DPI and corporate systems is domain fronting technology. Its essence lies in accessing a blocked resource by disguising it with another public domain that has a good reputation, which will purposely not be blocked by any system, for example google.com.
A significant number of articles and examples have already been written about this technology. However, the popular and recently discussed technologies DNS-over-HTTPS and encrypted SNI, as well as the new version of the TLS 1.3 protocol, allow us to consider one more option for domain fronting.
Understanding the technology
First, let’s clarify some basic concepts so that everyone understands who is who and why all this is necessary. We mentioned the eSNI mechanism, the operation of which will be discussed further. The eSNI (encrypted Server Name Indication) mechanism is a secure version of SNI available only for the TLS 1.3 protocol. The main point is to encrypt the information regarding which domain the request is sent to.
Now, let’s look at the eSNI mechanism in practice.
Suppose we have an internet resource that is blocked by a modern DPI solution (let's take a famous torrent tracker as an example — rutracker.nl). When trying to access the torrent tracker site, we see the provider’s standard blocking message:
On the RKN website, this domain is indeed listed in the stop lists:
When requesting a whois, it is clear that the domain itself is 'hidden' behind the cloud provider Cloudflare.
De a különböző RKN-es "szakértőktől" eltérően, a technikailag képzettebb belai munkatársak (vagy a híres szabályozónk keserű tapasztalataiból tanulva) nem egyszerűen az IP-cím alapján tiltotta le a weboldalt, hanem a feketelistára pontosan a domain nevet. Ezt könnyen igazolhatjuk, ha megnézzük, hogy milyen más domainek rejtőznek ezen a néven IP-cím, meglátogatunk egyet, és látjuk, hogy a hozzáférés nem blokkolt:
De hogyan lehetséges ez? Hogyan tudja a szolgáltató DPI, hogy melyik domainhez megy a böngészőm, hiszen minden kommunikáció HTTPS protokollon történik, és a belai HTTPS tanúsítványok cseréje eddig nem tűnt fel? Talán látó, vagy követnek engem?
Próbáljunk megválaszolni erre a kérdésre, és nézzük meg a forgalmat a Wireshark segítségével.
A képernyőképen látható, hogy a böngésző először DNS-en keresztül megkapja a szerver IP-címét, majd történik egy szabványos TCP kézfogás a cél szerverrel, ezután a böngésző próbál SSL-kapcsolatot létesíteni a szerverrel. Ehhez elküldi a SSL Client Hello csomagot, amelyben nyíltan szerepel az eredeti domain neve. Ezt a mezőt a Cloudflare frontend szerverének szüksége van a kapcsolat helyes irányításához. Itt ragadja el a kapcsolatot a szolgáltató DPI, megszakítva azt. Miközben nem kapunk semmilyen üzenetet a szolgáltatótól, a böngésző állandó hibát jelez, mintha az oldal le lenne kapcsolva, vagy egyszerűen nem működik:
Most pedig aktiváljuk az eSNI mechanizmust a böngészőben, ahogyan az az Firefox :
Firefox konfigurációs oldalán olvasható. about:config Aktiváljuk 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
Ezután ellenőrizzük a beállítások helyességét a Cloudflare weboldalán a linkre kattintva és próbáljuk meg újra a trükköt a torrent trackerünkkel.
Voilà. A kedvenc trackerünk megnyílt, bármiféle VPN és proxy szerver nélkül. Nézzük meg most a forgalom dumpját a Wiresharkban, mi is történt.
Ezúttal az SSL Client Hello csomag nem tartalmazza nyíltan a cél domaint, helyette egy új mező jelent meg a csomagban - az encrypted_server_name - itt található a rutracker.nl értéke, és ezt a mezőt csak a Cloudflare frontend szerver tudja dekódolni. Így a szolgáltató DPI-nek nem marad más választása, mint kezeit mosni, és engedélyezni ezt a forgalmat. Más titkosítási lehetőség pedig nem létezik.
Tehát megnéztük, hogyan működik a technológia a böngészőben. Most próbáljuk meg alkalmazni ezt specifikusabb és érdekesebb dolgokra. Először is megtanítjuk a curl-t, hogy használja az eSNI-t a TLS 1.3 támogatásához, és közben megnézzük, hogyan működik az eSNI alapú domain-fronting.
Domain-fronting eSNI-vel
Mivel a curl a https protokollhoz az openssl szabványos könyvtárat használja, először is biztosítani kell az eSNI támogatást ott. Az openssl master-ágában még nincs eSNI támogatás, ezért le kell töltenünk egy speciális openssl ágat, le kell fordítanunk és telepítenünk kell.
Klónozzuk a GitHub-tárhelyet és fordítsuk le, ahogy azt szoktuk:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Ezután klónozzuk a curl tárhelyet, és konfiguráljuk a fordítást az általunk fordított openssl könyvtár használatával:
$ 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, hogy helyesen adjuk meg az openssl összes könyvtárát (a mi esetünkben ez a /opt/openssl/), és figyeljünk arra, hogy a konfigurációs folyamat hiba nélkül zajlott.
Sikeres konfiguráció esetén meg fogjuk látni a következő sort:
WARNING: esni ESNI enabled but marked EXPERIMENTAL. Use with caution!
$ makeA csomag sikeres összeállítása után a curl beállításához és elindításához külön bash fájlt használunk az openssl-ből. Másoljuk át a curl könyvtárába az egyszerűség kedvéért:
cp /opt/openssl/esnistuff/curl-esni és végezzünk egy teszt https-kérést a cloudflare szerver felé, miközben rögzítjük a DNS és TLS csomagokat a Wireshark-ban.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/A szerver válaszában, az openssl-től és curl-től származó számos hibakeresési információ mellett, HTTP válasz kódot (301) 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 arról tanúskodik, hogy a kérésünket sikeresen továbbították a cél szerverhez, ahol azt meghallgatták és feldolgozták.
Most nézzük meg a Wireshark forgalmi dumpját, azaz mit látott ebben az esetben a szolgáltató DPI.
Látható, hogy először a curl a DNS szerverhez fordult a cloudflare publikus eSNI kulcsáért — TXT DNS lekérdezés az _esni.cloudflare.com címen (13. csomag). Ezután, az openssl könyvtárat használva, a curl TLS 1.3 lekérdezést küldött a cloudflare szervernek, amelyben az SNI mezőt a korábban kapott publikus kulccsal titkosította (22. csomag). De az eSNI mező mellett a SSL-hello csomagban egy nyílt SNI mező is szerepelt, amit tetszőleges sorrendben megadhatunk (ebben az esetben — www.hello-rkn.ru).
Ez a nyílt SNI mező nem játszott szerepet a cloudflare szerverek általi feldolgozásban, és csak a szolgáltató DPI elől való álcázás céljára szolgált. A cloudflare szerver elfogadta az SSL-hello csomagunkat, dekódolta az eSNI-t, kinyerte belőle az eredeti SNI-t, és mint ha mi sem történt volna, feldolgozta (pontosan úgy, ahogy az eSNI fejlesztésekor tervezve volt).
Az egyetlen tényező, amire ebben az esetben a DPI szempontjából lehetne hivatkozni, az az elsődleges DNS kérés az _esni.cloudflare.com címre. De ennél a kérésnél a nyílt DNS lekérdezést csak azért tettük, hogy bemutassuk, hogyan működik ez a mechanizmus a belső részletekben.
Annak érdekében, hogy végleg eltávolítsuk a talajt a DPI lába alól, a már megemlített DNS-over-HTTPS mechanizmust használjuk. Egy kis magyarázat – a DOH – egy protokoll, amely lehetőséget biztosít a „középső ember” támadások ellen, mivel a DNS lekérdezést HTTPS protokollon keresztül küldjük el.
Ismételjük meg a lekérdezést, de ezúttal a publikus eSNI kulcsokat HTTPS protokollon keresztül kapjuk, nem DNS-en:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/A lekérdezés forgalmának dumpja az alábbi képernyőképen látható:
Látható, hogy először a curl a mozilla.cloudflare-dns.com szerverhez fordul a DoH protokollon (HTTPS kapcsolat a 104.16.249.249 szerverhez), hogy ott megszerezze a SNI titkosításához szükséges publikus kulcsakat, majd ezt követően a célkiszolgálóhoz, miközben a következő domain mögé rejtőzik. www.hello-rkn.ru.
A fent említett mozilla.cloudflare-dns.com DoH feloldó mellett más népszerű DoH szolgáltatásokat is használhatunk, például a híres gonosz vállalatot.
Hajtsuk végre ezt a lekérdezést:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/És választ kapunk:
< 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 szerverre érkeztünk, a DoH-rozolvert dns.google használva (itt nincs elírás, most már a híres vállalatnak van saját első szintű domaine) és egy másik domain mögé bújva, amelynek blokkolása szigorúan tilos minden DPI számára, halálbüntetés terhe mellett. A kapott válaszból megérthetjük, hogy a kérésünket sikeresen feldolgozták.
További ellenőrzésként, hogy a szolgáltató DPI reagál a nyitott SNI-re, amit fedezésként adunk meg, végezhetünk egy kérést a rutracker.nl-re, elbújva egy másik, tiltott forrástól, például egy másik „jó” torrent-tracker mögé:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/A szervertől választ nem kapunk, mivel a kérésünket a DPI rendszer blokkolja.
Rövid következtetés az első részhez
Tehát sikerült bemutatnunk az eSNI működését az openssl és a curl segítségével, és ellenőriznünk az eSNI-re alapozott domain-fronting működését. Ilyen módon adaptálhatjuk kedvenc eszközeinket, amelyek az openssl könyvtárat használják, hogy „más domainok mögött” működjenek. Részletek erről — a következő cikkekben.
Forrás: habr.com
