Domeeni fronting TLS 1.3 baasil

Sissejuhatus

Kaasaegsed ettevõtte sisu filtreerimise süsteemid tuntud tootjatelt nagu Cisco, BlueCoat, FireEye sarnanevad oma võimsamate kolleegidega - DPI süsteemidega, mida kohalikul tasandil laialdaselt juurutatakse. Nende ja teiste tööpõhimõte seisneb siseneva ja väljuva internetiliikluse kontrollimises ning mustade/valgete nimekirjade põhjal internetiühenduste keelamise otsuste tegemises. Kuna nii need kui ka teised tuginevad oma toimimisel sarnastele põhimõtetele, on käigud nende ületamiseks samuti sarnased.

Üks tehnoloogiaid, mis võimaldab tõhusalt nii DPI-d kui ka ettevõtte süsteeme ületada, on domeeni fronting tehnoloogia. Selle põhiolemus seisneb selles, et me pääseme blokeeritud ressursile, kasutades teist, avalikku domeeni, millel on hea maine ja mida ei blokeeri mingisugune süsteem, näiteks google.com.

Selle tehnoloogia kohta on kirjutatud piisavalt palju artikleid ja toodud palju näiteid. Siiski pakuvad hiljuti populaarsust kogunud tehnoloogiad DNS-over-HTTPS ja encrypted-SNI, samuti uus TLS 1.3 protokolli versioon võimaluse käsitleda veel üht domeeni fronting varianti.

Selgitame välja tehnoloogia

Alustame olulisemate terminite selgitamisest, et igaühel oleks arusaam, kes on kes ja miks on see vajalik. Mainisime mehhanismi eSNI, mille toimimist käsitletakse allpool. eSNI (encrypted Server Name Indication) mehhanism on SNI kaitstud versioon, mis on saadaval ainult TLS 1.3 protokollile. Põhiolemus on krüpteerida muu hulgas teave, millise domeeni poole päring saadetakse.

Nüüd vaatame eSNI mehhanismi toimimist praktikas.

Oletame, et meil on internetiresurss, mida blokeerib kaasaegne DPI lahendus (võtame näiteks tuntud torrent-tracker'i - rutracker.nl). Kui proovime pääseda torrent-tracker'i saidile - näeme teenusepakkuja standardset teavitust, et ressurss on blokeeritud:

RKNi saidil on see domeen tõepoolest stopp-nimekirjades:

Whois päringu põhjal on näha, et domeen on 'peidetud' pilvprovideri Cloudflare'i taha.

Kuid erinevalt RKNi "spetsialistidest" ei hakanud Beeline'i rohkem tehniliselt haritud töötajad (või siis meie tuntud regulaatori kibeda kogemuse tõttu) lihtsalt IP-aadressi järgi veebisaiti blokeerima, vaid lisasid bloki nimekirja just domeeninime. Sellele on lihtne veenduda, kui vaadata, millised veel domeenid peituvad selle sama IP-aadress, külastada ühte neist ja näha, et ligipääs ei ole blokeeritud:

Kuidas see siis nii juhtub? Kuidas pakkuja DPI teab, millisele domeenile minu brauser suundub, kui kõik suhtlused toimuvad https-protokolli kaudu, ja Beeline'i https-sertifikaatide asendamist me seni ei ole täheldanud? Kas ta on selgeltnägija või jälgib keegi mind?

Proovime sellele küsimusele vastata, vaadates liiklust läbi Wiresharki

Kuvamisel on näha, et kõigepealt saab brauser serveri IP-aadressi DNS-i kaudu, seejärel toimub standardne TCP-käepigistus sihtserveriga ja siis püüab brauser luua ssl-ühendust serveriga. Selleks edastab ta paketi SSL Client Hello, milles on originaaldomeeni nimi avatud kujul. See väli on vajalik Cloudflare'i frontend-serverile, et õigesti marsruutida ühendus. Just siin püüab meid kinni pakkuja DPI, katkestades meie ühenduse. Me ei saa pakkuja poolt mingeid blokeeringuteavet ja näeme tavalist brauseri viga, nagu oleks sait välja lülitatud või ei töötaks lihtsalt:

Nüüd aktiveerime brauseris eSNI mehhanismi, nagu on kirjas juhendis Firefox :
Selleks avame Firefoxi konfigureerimise lehe about:config ja aktiveerime järgmised seaded:

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

Pärast seda kontrollime seadete õigsust Cloudflare'i saidil lingil ja proovime veel kord meie torrent-trackeriga sama trikki.

Voila. Meie lemmik-tracker avanes, ilma igasuguste VPN-ide ja proksiserveriteta. Vaadakem nüüd Wiresharki liiklusdampi, mis juhtus.

Seekord ei sisalda ssl client hello pakett sihtdomeeni selgelt, vaid paketi sees on uus väli — encrypted_server_name — just seal on väärtus rutracker.nl ja seda välja saab dekrüpteerida ainult Cloudflare'i frontend-server. Kui nii on, siis ei jää pakkuja DPI-le muud üle, kui käsi pesta ja sellist liiklust lubada. Ja teisi šifreerimisvõimalusi ei olegi.

Nii et, kuidas tehnoloogia brauseris töötab — me vaatasime. Nüüd proovime seda rakendada konkreetsematesse ja huvitavatesse asjadesse. Alguseks õpetame, kuidas kasutada seda sama curl eSNI abil TLS 1.3-tal, ja vaatame, kuidas toimib domeenifronting eSNI põhjal.

Domeenifronting eSNI-ga

Kuna curl kasutab https-protokolliga ühendamiseks standardset openssl teeki, peame kõigepealt tagama eSNI toe just seal. OpenSSL-i master-harudes pole eSNI toe jaoks veel olemas, seega peame alla laadima spetsiaalse avatud haru openssl-ist, selle kompileerima ja installima.

Kloonime repot gitHubist ja kompileerime nagu tavaliselt:

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

$ make
$ cd esnistuff
$ make

Seejärel kloonime curl'i repot ja konfigureerime selle kompileerimise, kasutades meie koostatud openssl teeki:

$ 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

Siin on oluline õigesti määrata kõik kataloogid, kus openssl asub (meie puhul — see on /opt/openssl/) ja veenduda, et konfiguratsiooniprotsess ei sisaldaks vigu.

Juhul kui konfiguratsioon õnnestub — näeme rida:

WARNING: esni ESNI enabled but marked EXPERIMENTAL. Use with caution!

$ make

Pärast paketi edukat koostamist kasutame openssl-ist saadud spetsiaalset bash-faili curl'i seadistamiseks ja käivitamiseks. Kopeerime selle curl'i katalooge mugavuse huvides:

cp /opt/openssl/esnistuff/curl-esni 

ja sooritame testimise https-päringu cloudflare serverisse, salvestades samal ajal DNS ja TLS paketid Wireshark'i.

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

Serveri vastuses koos hulga silumisinfoga openssl'ist ja curl'ist saame HTTP vastuse koodiga 301 cloudflare'ilt.

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/

mis tõendab, et meie päring on edukalt toimetatud sihtserverisse, kuulatud ja töödeldud.

Nüüd vaatame liikluse dumpi wireshark'is, st mida nägi antud juhul teenuseliini DPI.

On näha, et esmalt pöördus curl DNS-serveri poole, et saada Cloudflare'i serveri avalikke eSNI võtmeid – TXT DNS päring _esni.cloudflare.com (pakett nr 13). Seejärel saatis curl openssl-raamatukogu abil TLS 1.3 päringu Cloudflare'i serverisse, kus SNI väli oli krüpteeritud eelnevalt saadud avaliku võtmega (pakett nr 22). Kuid peale eSNI välja sisaldas SSL-hello pakett ka tavalist avatud SNI välja, mille võime määrata suvalises järjekorras (antud juhul – www.hello-rkn.ru).

Seda avatud SNI välja ei arvestatud Cloudflare'i serverite poolt ja see oli vaid varjamine teenusepakkuja DPI jaoks. Cloudflare'i server aktsepteeris meie ssl-hello paketti, dekrüpteeris eSNI, eraldas sealt originaalse SNI ja käsitles seda nagu mitte midagi (tehtud oli täpselt nii, nagu eSNI loomisel plaanitud).

Ainus, mille külge siin DPI vaatenurgast kinni hakata, on esmase DNS päringu tegemine _esni.cloudflare.com. Kuid me tegime DNS päringu avatud ainult selleks, et näidata, kuidas see mehhanism seestpoolt töötab.

Kuna DPI alt lõplikult põrandat jalge alt välja tõmmata, kasutame juba mainitud DNS-over-HTTPS mehhanismi. Väike selgitus - DOH - protokoll, mis võimaldab kaitsta 'mees keset' rünnaku eest, edastades DNS-päringu HTTPS protokolli kaudu.

Teeme päringu uuesti, kuid seekord saame avalikud eSNI võtmed HTTPS protokolli kaudu, mitte DNS-i kaudu:

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

Päringu liikluse dump on esitatud alloleval ekraanipildil:

On näha, et esmalt pöördub curl mozilla.cloudflare-dns.com serveri poole DoH protokolli kaudu (HTTPS ühendus serveriga 104.16.249.249), et saada SNI krüpteerimiseks vajalikke avalikke võtmeid, ja seejärel päring suunatakse sihtserverisse, varjates end samal ajal domeeniga. www.hello-rkn.ru.

Peale eespool nimetatud DoH resolveri mozilla.cloudflare-dns.com saame kasutada ka teisi populaarseid DoH teenuseid, näiteks kurikuulsa kurjuse korporatsiooni teenuseid.
Teeme sellise päringu:

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

Ja saame vastuse:

< 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

Antud juhul pöördusime blokeeritud serveri rutracker.nl poole, kasutades DoH-resolvert dns.google (siin pole trükiviga, nüüd on kuulsa korporatsiooni oma tippdomeen) ja varjasime end teise domeeni taha, mille blokeerimine on rangelt keelatud kõigile DPI-dele surmaohuga. Vastusest võib aru saada, et meie päring töötati edukalt üles.

Lisakontrollina, et veenduda, et teenusepakkuja DPI reageerib avatud SNI-le, mida me varjatuna edastame — saame saata päringu rutracker.nl, varjades end mingi muu keelatud ressursi, näiteks teise "head" torrent-kerija taha:

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

Me ei saa serverilt vastust, kuna meie päring blokeeritakse DPI-süsteemi poolt.

Väike järeldus esimesele osale

Nii et oleme suutnud demonstreerida eSNI toimivust openssl'i ja curl'i abil ning kontrollida eSNI-põhiste domeenifrontide tööd. Sarnasel viisil saame kohandada oma lemmikinstrumente, mis kasutavad openssl'i teeki, et töötada "varjatuna" teiste domeenide taga. Rohkem sellest — meie järgnevates artiklites.

Allikas: habr.com