Predstavljanje domena bazirano na TLS 1.3

Uvod

Moderni sistemi za filtriranje korporativnog sadržaja renomiranih proizvođača kao što su Cisco, BlueCoat, FireEye imaju dosta zajedničkog sa svojim moćnijim kolegama - DPI sistemima, koji se aktivno implementiraju na nacionalnom nivou. Suština rada i jednog i drugog je da pregledaju dolazni i odlazni internet saobraćaj i da na osnovu crnih/belih lista donesu odluku o zabrani internet konekcije. A budući da se obojica oslanjaju na slične principe u osnovama svog rada, metode za njihovo zaobilaženje će također imati mnogo zajedničkog.

Jedna od tehnologija koja vam omogućava da prilično efikasno zaobiđete i DPI i korporativne sisteme je tehnologija koja se odnosi na domen. Njegova suština je da idemo na blokirani resurs, skrivajući se iza drugog, javnog domena sa dobrom reputacijom, koji očito neće biti blokiran od strane bilo kojeg sistema, na primjer google.com.

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

Razumijevanje tehnologije

Prvo, hajde da definišemo malo osnovne pojmove kako bi svi shvatili ko je ko i zašto je sve ovo potrebno. Spomenuli smo eSNI mehanizam, o čijem će se djelovanju dalje govoriti. Mehanizam eSNI (šifrovana oznaka imena servera) je sigurna verzija SNI, dostupna samo za TLS 1.3 protokol. Osnovna ideja je šifriranje, između ostalog, informacija o tome na koji domen se zahtjev šalje.

Pogledajmo sada 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 dobavljača koji pokazuje da je resurs blokiran:

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

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

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

Kako se to događa? Kako DPI provajdera zna na kojoj domeni je moj pretraživač, budući da se sva komunikacija odvija preko https protokola, a mi još nismo primetili zamenu https sertifikata od Beeline-a? Je li on vidovit ili me prate?

Pokušajmo odgovoriti na ovo pitanje gledajući promet kroz wireshark

Snimak ekrana pokazuje da prvo pretraživač dobija IP adresu servera preko DNS-a, zatim dolazi do standardnog TCP rukovanja sa odredišnim serverom, a zatim pretraživač pokušava da uspostavi SSL vezu sa serverom. Da bi to uradio, šalje SSL Client Hello paket, koji sadrži naziv izvorne domene u čistom tekstu. Ovo polje je potrebno za cloudflare frontend server da bi ispravno usmjerio vezu. Ovdje nas provajder DPI uhvati, prekidajući našu vezu. Istovremeno, ne primamo nikakav stub od provajdera, a vidimo standardnu ​​grešku preglednika kao da je stranica onemogućena ili jednostavno ne radi:

Sada omogućimo eSNI mehanizam u pretraživaču, kao što je napisano u uputstvima za Firefox :
Da bismo to učinili otvaramo stranicu za konfiguraciju Firefoxa o: konfiguraciji 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 da li postavke ispravno rade na web stranici cloudflare. link i hajde da ponovo probamo trik sa našim torrent trackerom.

Voila. Naš omiljeni tracker otvoren je bez VPN ili proxy servera. Pogledajmo sada saobracajnu deponiju u wireshark-u da vidimo sta se desilo.

Ovaj put, ssl klijent hello paket ne sadrži eksplicitno odredišnu domenu, ali umjesto toga, pojavilo se novo polje u paketu - encrypted_server_name - ovdje je sadržana vrijednost rutracker.nl, a samo cloudflare frontend server to može dešifrirati polje. A ako je tako, onda provajder DPI nema drugog izbora nego da opere ruke i dozvoli takav promet. Nema drugih opcija sa enkripcijom.

Dakle, pogledali smo kako tehnologija radi u pretraživaču. Sada pokušajmo to primijeniti na konkretnije i zanimljivije stvari. I prvo, naučit ćemo isti curl da koristi eSNI za rad sa TLS 1.3, a u isto vrijeme ćemo vidjeti kako funkcionira sam fronting domena baziran na eSNI.

Predstavljanje domena sa eSNI

Zbog činjenice da curl koristi standardnu ​​openssl biblioteku za povezivanje putem https protokola, prije svega moramo tu pružiti podršku za eSNI. Još nema eSNI podrške u openssl master granama, tako da moramo preuzeti posebnu openssl granu, kompajlirati je i instalirati.

Kloniramo spremište sa GitHub-a i kompajliramo kao i obično:

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

$ make
$ cd esnistuff
$ make

Zatim, kloniramo spremište sa curl-om i konfiguriramo njegovu kompilaciju koristeći našu kompajliranu openssl biblioteku:

$ 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 ispravno specificirati sve direktorije u kojima se nalazi openssl (u našem slučaju to je /opt/openssl/) i osigurati da proces konfiguracije prođe bez grešaka.

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

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

$ make

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

cp /opt/openssl/esnistuff/curl-esni 

i napravite test https zahtjev na cloudflare serveru, dok istovremeno snimate DNS i TLS pakete u Wiresharku.

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

U odgovoru servera, pored mnogo informacija o otklanjanju grešaka iz openssl-a i curl-a, dobićemo HTTP odgovor sa kodom 301 od cloudflare-a.

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 ukazuje da je naš zahtjev uspješno dostavljen na odredišni server, saslušan i obrađen.

Pogledajmo sada deponiju saobraćaja u wireshark-u, tj. šta je provajder DPI vidio u ovom slučaju.

Vidi se da se curl prvo okrenuo DNS serveru za javni eSNI ključ za cloudflare server - TXT DNS zahtjev za _esni.cloudflare.com (paket br. 13). Zatim, koristeći openssl biblioteku, curl je poslao TLS 1.3 zahtjev na cloudflare server u kojem je SNI polje šifrirano javnim ključem dobijenim u prethodnom koraku (paket #22). Ali, pored eSNI polja, SSL-hello paket je uključivao i polje sa uobičajenim - otvorenim SNI, koje možemo navesti bilo kojim redosledom (u ovom slučaju - www.hello-rkn.ru).

Ovo otvoreno SNI polje ni na koji način nije uzeto u obzir kada ga obrađuju cloudflare serveri i služilo je samo kao maska ​​za DPI provajdera. Cloudflare server je primio naš ssl-hello paket, dešifrirao eSNI, izvukao originalni SNI odatle i obradio ga kao da se ništa nije dogodilo (uradio je sve tačno kako je planirano prilikom razvoja eSNI).

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

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

Izvršimo zahtjev ponovo, ali ovaj put ćemo javne eSNI ključeve dobiti preko 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 snimku ekrana ispod:

Vidi se da curl prvo pristupa mozilla.cloudflare-dns.com serveru preko DoH protokola (https veza sa serverom 104.16.249.249) kako bi od njih dobio vrijednosti javnih ključeva za SNI enkripciju, a zatim do odredišta server, koji se krije iza domena www.hello-rkn.ru.

Osim gore navedenog DoH rezolvera mozilla.cloudflare-dns.com, možemo koristiti i druge popularne DoH servise, na primjer, iz poznate zla 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, obratili smo se blokiranom serveru rutracker.nl, koristeći DoH resolver dns.google (ovdje nema greške u kucanju, sada poznata korporacija ima svoju domenu prvog nivoa) i pokrili se drugom domenom, koja je striktno zabranjeno za sve DPI da blokiraju pod pretnjom smrti. Na osnovu primljenog odgovora, možete shvatiti da je naš zahtjev uspješno obrađen.

Kao dodatnu provjeru da li provajderov DPI odgovara na otvoreni SNI, koji prenosimo kao masku, možemo uputiti zahtjev rutracker.nl pod krinkom nekog drugog zabranjenog resursa, 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 sa servera, jer... naš zahtjev će biti blokiran od strane DPI sistema.

Kratak zaključak prvog dijela

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

izvor: www.habr.com