Sučelje domene temeljeno na TLS 1.3

Uvod

Suvremeni korporativni sustavi za filtriranje sadržaja renomiranih proizvođača kao što su Cisco, BlueCoat, FireEye imaju mnogo toga zajedničkog sa svojim moćnijim pandanima - DPI sustavima, koji se aktivno implementiraju na nacionalnoj razini. Bit rada obojice je provjera dolaznog i odlaznog internetskog prometa te na temelju crnih/bijelih lista donijeti odluku o zabrani internetske veze. A budući da se i jedni i drugi u osnovi svog rada oslanjaju na slična načela, metode za njihovo zaobilaženje također će imati mnogo toga zajedničkog.

Jedna od tehnologija koja vam omogućuje da prilično učinkovito zaobiđete i DPI i korporativne sustave je tehnologija usmjerena na domenu. Njegova je bit da idemo na blokirani resurs, skrivajući se iza druge, javne domene s dobrom reputacijom, koju očito neće blokirati niti jedan sustav, na primjer google.com.

O ovoj tehnologiji već je napisano dosta članaka i dato je mnogo primjera. Međutim, popularne i nedavno raspravljane tehnologije DNS-over-HTTPS i encrypted-SNI, kao i nova verzija protokola TLS 1.3, omogućuju razmatranje druge opcije za fronting domene.

Razumijevanje tehnologije

Prvo, definirajmo malo osnovne pojmove kako bi svatko razumio tko je tko i zašto je sve to potrebno. Spomenuli smo mehanizam eSNI, o čijem ćemo radu još biti riječi. Mehanizam eSNI (encrypted Server Name Indication) je sigurna verzija SNI-ja, dostupna samo za protokol TLS 1.3. Glavna ideja je šifrirati, između ostalog, informacije o tome na koju domenu je zahtjev poslan.

Sada pogledajmo kako eSNI mehanizam funkcionira u praksi.

Recimo da imamo internetski resurs koji je blokiran modernim DPI rješenjem (uzmimo, na primjer, poznati torrent tracker rutracker.nl). Kada pokušamo pristupiti web stranici torrent trackera, vidimo standardni stub pružatelja koji pokazuje da je resurs blokiran:

Na web stranici RKN ova je domena zapravo navedena na stop listama:

Kada postavite upit whois, možete vidjeti da je sama domena "skrivena" iza pružatelja usluga oblaka Cloudflare.

Ali za razliku od “specijalaca” iz RKN-a, tehnički potkovaniji zaposlenici Beeline-a (ili poučeni gorkim iskustvom našeg slavnog regulatora) nisu glupo zabranili stranicu po IP adresi, već su naziv domene dodali na stop listu. To možete lako provjeriti ako pogledate koje se druge domene kriju iza iste IP adrese, posjetite neku od njih i vidite da pristup nije blokiran:

Kako se to događa? Kako DPI provajdera zna na kojoj je domeni moj preglednik, budući da se sva komunikacija odvija preko https protokola, a još nismo primijetili zamjenu https certifikata od Beeline? Je li on vidovit ili me netko prati?

Pokušajmo odgovoriti na ovo pitanje promatrajući promet putem wiresharka

Snimka zaslona pokazuje da preglednik prvo dobiva IP adresu poslužitelja putem DNS-a, zatim se standardno TCP rukovanje događa s odredišnim poslužiteljem, a zatim preglednik pokušava uspostaviti SSL vezu s poslužiteljem. Da bi to učinio, šalje SSL Client Hello paket koji sadrži naziv izvorne domene u čistom tekstu. Ovo polje zahtijeva cloudflare frontend poslužitelj kako bi ispravno usmjerio vezu. Ovdje nas hvata DPI pružatelja usluga, prekidajući našu vezu. Istodobno, ne primamo nikakav stub od davatelja i vidimo standardnu ​​pogrešku preglednika kao da je web mjesto onemogućeno ili jednostavno ne radi:

Sada omogućimo eSNI mehanizam u pregledniku, kao što je napisano u uputama za Firefox :
Da bismo to učinili, otvorimo konfiguracijsku stranicu Firefoxa about: config i aktivirajte sljedeće postavke:

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

Nakon toga ćemo provjeriti rade li postavke ispravno na web stranici cloudflare. link i pokušajmo ponovno s našim torrent trackerom.

Evo. Naš omiljeni tracker otvorio se bez VPN-a ili proxy poslužitelja. Pogledajmo sada promet u Wiresharku da vidimo što se dogodilo.

Ovog puta, pozdravni paket ssl klijenta ne sadrži eksplicitno odredišnu domenu, ali umjesto toga, u paketu se pojavilo novo polje - encrypted_server_name - ovo je mjesto gdje se nalazi vrijednost rutracker.nl, a samo cloudflare frontend server može to dekriptirati polje. A ako je tako, onda provajderu DPI ne preostaje ništa drugo nego oprati ruke i dopustiti takav promet. Nema drugih opcija s enkripcijom.

Dakle, pogledali smo kako tehnologija funkcionira u pregledniku. Sada pokušajmo to primijeniti na konkretnije i zanimljivije stvari. I prvo, naučit ćemo isti curl da koristi eSNI za rad s TLS 1.3, a u isto vrijeme ćemo vidjeti kako radi sam fronting domene temeljen na eSNI-ju.

Sučelje domene s eSNI

Zbog činjenice da curl koristi standardnu ​​openssl biblioteku za povezivanje preko https protokola, prije svega moramo tamo osigurati eSNI podršku. Još nema eSNI podrške u openssl master granama, pa moramo preuzeti posebnu openssl granu, kompajlirati je i instalirati.

Kloniramo repozitorij iz GitHuba i kompajliramo kao i obično:

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

$ make
$ cd esnistuff
$ make

Zatim kloniramo repozitorij s curl i konfiguriramo njegovu kompilaciju pomoću naše kompilirane openssl biblioteke:

$ 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

Ovdje je važno točno navesti sve direktorije u kojima se openssl nalazi (u našem slučaju to je /opt/openssl/) i pobrinuti se da proces konfiguracije prođe bez grešaka.

Ako je konfiguracija uspješna, vidjet ćemo redak:

UPOZORENJE: esni ESNI omogućen, ali označen kao EKSPERIMENTALNO. Koristite s oprezom!

$ make

Nakon uspješne izgradnje paketa, koristit ćemo posebnu bash datoteku iz openssl-a za konfiguraciju i pokretanje curla. Kopirajmo ga u direktorij s curl radi praktičnosti:

cp /opt/openssl/esnistuff/curl-esni 

i napravite probni https zahtjev prema cloudflare poslužitelju, dok istovremeno snimate DNS i TLS pakete u Wiresharku.

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

U odgovoru poslužitelja, uz mnoštvo informacija o otklanjanju pogrešaka iz openssl-a i curla, primit ćemo HTTP odgovor s kodom 301 od cloudflarea.

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/

što označava da je naš zahtjev uspješno isporučen odredišnom poslužitelju, saslušan i obrađen.

Sada pogledajmo prometni dump u wiresharku, tj. što je pružatelj DPI vidio u ovom slučaju.

Vidi se da se curl prvo obratio DNS serveru za javni eSNI ključ za cloudflare server - TXT DNS zahtjev prema _esni.cloudflare.com (paket br. 13). Zatim je, koristeći openssl biblioteku, curl poslao TLS 1.3 zahtjev cloudflare serveru u kojem je SNI polje šifrirano s javnim ključem dobivenim u prethodnom koraku (paket #22). No, uz eSNI polje, SSL-hello paket je sadržavao i polje s uobičajenim - otvorenim SNI-jem, koje možemo odrediti bilo kojim redoslijedom (u ovom slučaju - www.hello-rkn.ru).

Ovo otvoreno polje SNI nije ni na koji način uzeto u obzir prilikom obrade poslužitelja cloudflarea i služilo je samo kao maska ​​za DPI pružatelja usluga. Cloudflare poslužitelj primio je naš ssl-hello paket, dekriptirao eSNI, izvukao izvorni SNI od tamo i obradio ga kao da se ništa nije dogodilo (napravio je sve točno onako kako je planirano prilikom razvoja eSNI-ja).

Jedina stvar koja se u ovom slučaju može uhvatiti s DPI točke gledišta je primarni DNS zahtjev prema _esni.cloudflare.com. Ali DNS zahtjev smo otvorili samo da pokažemo kako ovaj mehanizam funkcionira iznutra.

Kako bismo konačno izvukli tepih ispod DPI-ja, koristimo već spomenuti DNS-over-HTTPS mehanizam. Malo objašnjenje - DOH je protokol koji vam omogućuje zaštitu od napada čovjeka u sredini slanjem DNS zahtjeva preko HTTPS-a.

Izvršimo zahtjev ponovo, ali ovaj put ćemo javne eSNI ključeve dobiti putem https protokola, a ne DNS-a:

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

Dump prometa zahtjeva prikazan je na snimci zaslona u nastavku:

Vidljivo je da curl prvo pristupa poslužitelju mozilla.cloudflare-dns.com putem DoH protokola (https veza na poslužitelj 104.16.249.249) kako bi od njih dobio vrijednosti javnih ključeva za SNI enkripciju, a zatim do odredišta poslužitelj, koji se skriva iza domene www.hello-rkn.ru.

Osim gore navedenog DoH rezolvera mozilla.cloudflare-dns.com, možemo koristiti i druge popularne DoH usluge, na primjer, poznate zle korporacije.
Pokrenimo sljedeći upit:

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

I dobijamo odgovor:

< 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

U ovom slučaju, okrenuli smo se blokiranom poslužitelju rutracker.nl, koristeći DoH resolver dns.google (ovdje nema greške pri upisu, sada poznata korporacija ima svoju vlastitu domenu prve razine) i pokrili smo se drugom domenom, koja je striktno zabranjeno za sve DPI blokirati pod prijetnjom smrti. Na temelju primljenog odgovora možete zaključiti da je naš zahtjev uspješno obrađen.

Kao dodatnu provjeru odgovara li DPI pružatelja na otvoreni SNI, koji prenosimo kao pokriće, možemo podnijeti zahtjev rutracker.nl pod krinkom nekog drugog zabranjenog izvora, na primjer, drugog "dobrog" torrent trackera:

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

Nećemo dobiti odgovor od poslužitelja, jer... naš zahtjev će biti blokiran od strane DPI sustava.

Kratak zaključak prvog dijela

Dakle, uspjeli smo demonstrirati funkcionalnost eSNI-ja koristeći openssl i curl i testirati rad frontinga domene temeljenog na eSNI-ju. Na isti način možemo prilagoditi svoje omiljene alate koji koriste openssl biblioteku da rade "ispod krinke" drugih domena. Više detalja o tome u našim sljedećim člancima.

Izvor: www.habr.com