Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Ievads

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3
MÅ«sdienu korporatÄ«vā satura filtrÄ“Å”anas sistēmām no tādiem slaveniem ražotājiem kā Cisco, BlueCoat, FireEye ir diezgan daudz kopÄ«ga ar jaudÄ«gākajiem lÄ«dziniekiem - DPI sistēmām, kuras tiek aktÄ«vi ieviestas valsts lÄ«menÄ«. Abu darba bÅ«tÄ«ba ir pārbaudÄ«t ienākoÅ”o un izejoÅ”o interneta trafiku un, balstoties uz melnajiem/baltajiem sarakstiem, pieņemt lēmumu par interneta pieslēguma aizliegÅ”anu. Un tā kā viņi abi savā darba pamatos paļaujas uz lÄ«dzÄ«giem principiem, arÄ« to apieÅ”anas metodēm bÅ«s daudz kopÄ«ga.

Viena no tehnoloģijām, kas ļauj diezgan efektīvi apiet gan DPI, gan korporatīvās sistēmas, ir domēna frontes tehnoloģija. Tās būtība ir tāda, ka mēs ejam uz bloķētu resursu, slēpjoties aiz cita, publiska domēna ar labu reputāciju, kuru acīmredzot nebloķēs neviena sistēma, piemēram, google.com.

Par Å”o tehnoloÄ£iju jau ir rakstÄ«ts diezgan daudz rakstu un sniegti daudzi piemēri. Tomēr populārās un nesen apspriestās DNS-over-HTTPS un Å”ifrētā SNI tehnoloÄ£ijas, kā arÄ« jaunā TLS 1.3 protokola versija ļauj apsvērt citu domēna frontes iespēju.

Izpratne par tehnoloģiju

Pirmkārt, definēsim nedaudz pamatjēdzienus, lai ikvienam bÅ«tu izpratne par to, kas ir kas un kāpēc tas viss ir vajadzÄ«gs. Pieminējām eSNI mehānismu, par kura darbÄ«bu tiks runāts tālāk. eSNI (Å”ifrēta servera nosaukuma indikācijas) mehānisms ir droÅ”a SNI versija, kas pieejama tikai TLS 1.3 protokolam. Galvenā ideja ir cita starpā Å”ifrēt informāciju par to, uz kuru domēnu tiek nosÅ«tÄ«ts pieprasÄ«jums.

Tagad apskatīsim, kā eSNI mehānisms darbojas praksē.

Pieņemsim, ka mums ir interneta resurss, kuru bloķē moderns DPI risinājums (ņemsim, piemēram, slaveno torrentu izsekotāju rutracker.nl). Mēģinot piekļūt torrentu izsekotāja vietnei, mēs redzam pakalpojumu sniedzēja standarta apakÅ”nodaļu, kas norāda, ka resurss ir bloķēts:

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

RKN vietnē Å”is domēns faktiski ir norādÄ«ts pieturas sarakstos:

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Kad vaicājat whois, jÅ«s varat redzēt, ka pats domēns ir ā€œpaslēptsā€ aiz mākoņa nodroÅ”inātāja Cloudflare.

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Bet atŔķirÄ«bā no RKN ā€œspeciālistiemā€ tehniski gudrāki darbinieki no Beeline (vai mācÄ«ja mÅ«su slavenā regulatora rÅ«gtā pieredze) vietni muļķīgi neaizliedza pēc IP adreses, bet pievienoja domēna nosaukumu pieturas sarakstam. Varat to viegli pārbaudÄ«t, ja aplÅ«kojat, kādi citi domēni ir paslēpti aiz tās paÅ”as IP adreses, apmeklējiet kādu no tiem un redzat, vai piekļuve nav bloķēta:

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Kā tas notiek? Kā pakalpojumu sniedzēja DPI zina, kurā domēnā darbojas mana pārlÅ«kprogramma, jo visi sakari notiek, izmantojot https protokolu, un mēs vēl neesam pamanÄ«juÅ”i https sertifikātu aizstāŔanu no Beeline? Vai viņŔ ir gaiÅ”reÄ£is vai arÄ« man seko?

Mēģināsim atbildēt uz Å”o jautājumu, aplÅ«kojot trafiku caur wireshark

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Ekrānuzņēmums parāda, ka vispirms pārlÅ«kprogramma iegÅ«st servera IP adresi, izmantojot DNS, pēc tam notiek standarta TCP rokasspiediens ar mērÄ·a serveri un pēc tam pārlÅ«kprogramma mēģina izveidot SSL savienojumu ar serveri. Lai to izdarÄ«tu, tas nosÅ«ta SSL Client Hello paketi, kas satur avota domēna nosaukumu skaidrā tekstā. Å is lauks ir nepiecieÅ”ams Cloudflare priekÅ”gala serverim, lai pareizi marÅ”rutētu savienojumu. Å eit pakalpojumu sniedzējs DPI mÅ«s pieÄ·er, pārtraucot mÅ«su savienojumu. Tajā paŔā laikā mēs nesaņemam no pakalpojumu sniedzēja nevienu ziņojumu, un mēs redzam standarta pārlÅ«kprogrammas kļūdu, it kā vietne bÅ«tu atspējota vai vienkārÅ”i nedarbojas:

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Tagad pārlūkprogrammā iespējosim eSNI mehānismu, kā rakstīts instrukcijās Firefox :
Lai to izdarÄ«tu, atveram Firefox konfigurācijas lapu about: config un aktivizējiet Ŕādus iestatÄ«jumus:

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

Pēc tam mēs pārbaudīsim, vai Cloudflare vietnē iestatījumi darbojas pareizi. saite un vēlreiz izmēģināsim triku ar mūsu torrentu izsekotāju.

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Voila. Mūsu iecienītākais izsekotājs tika atvērts bez VPN vai starpniekserveriem. Tagad apskatīsim satiksmes izgāztuvi Wireshark, lai redzētu, kas noticis.

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Å oreiz ssl klienta hello pakotnē nav skaidri norādÄ«ts mērÄ·a domēns, bet tā vietā pakotnē parādÄ«jās jauns lauks - encrypted_server_name - Å”eit ir ietverta rutracker.nl vērtÄ«ba, un tikai cloudflare frontend serveris var to atÅ”ifrēt. lauks. Un ja tā, tad pakalpojumu sniedzējam DPI neatliek nekas cits kā mazgāt rokas un atļaut Ŕādu trafiku. Citu Å”ifrÄ“Å”anas iespēju nav.

Tātad, mēs apskatÄ«jām, kā tehnoloÄ£ija darbojas pārlÅ«kprogrammā. Tagad mēģināsim to attiecināt uz konkrētākām un interesantākām lietām. Un vispirms mēs iemācÄ«sim to paÅ”u loku izmantot eSNI darbam ar TLS 1.3, un tajā paŔā laikā mēs redzēsim, kā darbojas pati eSNI balstÄ«tā domēna fronte.

Domēna frontÄ“Å”ana ar eSNI

Sakarā ar to, ka curl izmanto standarta openssl bibliotēku, lai izveidotu savienojumu, izmantojot https protokolu, vispirms mums ir jānodroÅ”ina eSNI atbalsts. Pagaidām openssl master filiālēs eSNI atbalsta nav, tāpēc mums ir jālejupielādē speciāla openssl filiāle, jāapkopo un jāinstalē.

Mēs klonējam repozitoriju no GitHub un kompilējam kā parasti:

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

$ make
$ cd esnistuff
$ make

Pēc tam mēs klonējam repozitoriju ar curl un konfigurējam tā kompilāciju, izmantojot mūsu apkopoto openssl bibliotēku:

$ 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

Šeit ir svarīgi pareizi norādīt visus direktorijus, kuros atrodas openssl (mūsu gadījumā tas ir /opt/openssl/), un pārliecināties, ka konfigurācijas process norit bez kļūdām.

Ja konfigurācija ir veiksmīga, mēs redzēsim rindu:

BRÄŖDINĀJUMS: esni ESNI ir iespējots, bet atzÄ«mēts EKSPERIMENTĀLS. Lietojiet piesardzÄ«gi!

$ make

Pēc veiksmÄ«gas pakotnes izveidoÅ”anas mēs izmantosim Ä«paÅ”u bash failu no openssl, lai konfigurētu un palaistu curl. ĒrtÄ«bas labad kopēsim to uz direktoriju ar curl:

cp /opt/openssl/esnistuff/curl-esni 

un veiciet pārbaudes https pieprasījumu cloudflare serverim, vienlaikus ierakstot DNS un TLS paketes programmā Wireshark.

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

Servera atbildē papildus lielai atkļūdoÅ”anas informācijai no openssl un curl mēs saņemsim HTTP atbildi ar kodu 301 no cloudflare.

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/

kas norāda, ka mūsu pieprasījums tika veiksmīgi piegādāts galamērķa serverim, uzklausīts un apstrādāts.

Tagad apskatÄ«sim satiksmes dump in wireshark, t.i. ko Å”ajā gadÄ«jumā redzēja pakalpojumu sniedzējs DPI.

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Var redzēt, ka curl vispirms vērsās pie DNS servera, lai iegÅ«tu publisku eSNI atslēgu cloudflare serverim - TXT DNS pieprasÄ«jums uz _esni.cloudflare.com (pakete Nr. 13). Pēc tam, izmantojot openssl bibliotēku, curl nosÅ«tÄ«ja TLS 1.3 pieprasÄ«jumu cloudflare serverim, kurā SNI lauks tika Å”ifrēts ar publisko atslēgu, kas iegÅ«ta iepriekŔējā darbÄ«bā (pakete #22). Bet, papildus laukam eSNI, SSL-hello paketē bija arÄ« lauks ar parasto - atvērto SNI, kuru mēs varam norādÄ«t jebkurā secÄ«bā (Å”ajā gadÄ«jumā - www.hello-rkn.ru).

Å is atvērtais SNI lauks nekādā veidā netika ņemts vērā, kad to apstrādāja cloudflare serveri, un tas kalpoja tikai kā maska ā€‹ā€‹nodroÅ”inātāja DPI. Cloudflare serveris saņēma mÅ«su ssl-hello paketi, atÅ”ifrēja eSNI, izvilka no turienes sākotnējo SNI un apstrādāja to tā, it kā nekas nebÅ«tu noticis (izstrādājot eSNI, tas visu darÄ«ja tieÅ”i tā, kā bija plānots).

VienÄ«gais, ko Å”ajā gadÄ«jumā var uztvert no DPI viedokļa, ir primārais DNS pieprasÄ«jums vietnei _esni.cloudflare.com. Bet mēs padarÄ«jām DNS pieprasÄ«jumu atvērtu tikai tāpēc, lai parādÄ«tu, kā Å”is mehānisms darbojas no iekÅ”puses.

Lai beidzot izvilktu paklāju no zem DPI, mēs izmantojam jau minēto DNS-over-HTTPS mehānismu. Neliels paskaidrojums ā€“ DOH ir protokols, kas ļauj aizsargāties pret uzbrukuma starpnieku, nosÅ«tot DNS pieprasÄ«jumu, izmantojot HTTPS.

IzpildÄ«sim pieprasÄ«jumu vēlreiz, bet Å”oreiz publiskās eSNI atslēgas saņemsim caur https protokolu, nevis DNS:

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

PieprasÄ«juma trafika dump ir parādÄ«ts zemāk esoÅ”ajā ekrānuzņēmumā:

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Var redzēt, ka curl vispirms piekļūst mozilla.cloudflare-dns.com serverim, izmantojot DoH protokolu (https savienojums ar serveri 104.16.249.249), lai iegÅ«tu no tiem publisko atslēgu vērtÄ«bas SNI Å”ifrÄ“Å”anai un pēc tam galamērÄ·im. serveris, kas slēpjas aiz domēna www.hello-rkn.ru.

Papildus iepriekÅ” minētajam DoH atrisinātājam mozilla.cloudflare-dns.com mēs varam izmantot citus populārus DoH pakalpojumus, piemēram, no slavenās ļaunās korporācijas.
Izpildīsim Ŕādu vaicājumu:

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

Un mēs saņemam atbildi:

< 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

Domēna frontÄ“Å”ana, pamatojoties uz TLS 1.3

Å ajā gadÄ«jumā mēs vērsāmies pie bloķētā rutracker.nl servera, izmantojot DoH solver dns.google (Å”eit nav drukas kļūdas, tagad slavenajai korporācijai ir savs pirmā lÄ«meņa domēns) un piesedzāmies ar citu domēnu, kas ir stingri aizliegts visiem DPI bloķēt nāves sāpju gadÄ«jumā. Pamatojoties uz saņemto atbildi, varat saprast, ka mÅ«su pieprasÄ«jums tika veiksmÄ«gi apstrādāts.

Kā papildu pārbaudi, vai pakalpojumu sniedzēja DPI reaģē uz atvērto SNI, ko mēs pārsÅ«tām kā segumu, mēs varam veikt pieprasÄ«jumu rutracker.nl cita aizliegta resursa aizsegā, piemēram, cita ā€œlabaā€ torrentu izsekotāja aizsegā:

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

No servera atbildi nesaņemsim, jo... mūsu pieprasījumu bloķēs DPI sistēma.

ÄŖss secinājums pirmajai daļai

Tātad, mēs varējām demonstrēt eSNI funkcionalitāti, izmantojot openssl un curl, un pārbaudÄ«t domēna frontes darbÄ«bu, pamatojoties uz eSNI. Tādā paŔā veidā mēs varam pielāgot savus iecienÄ«tākos rÄ«kus, kas izmanto openssl bibliotēku, lai tie darbotos citu domēnu ā€œaizsegāā€. PlaŔāka informācija par to ir mÅ«su nākamajos rakstos.

Avots: www.habr.com

Pievieno komentāru