Domain fronting batay sa TLS 1.3

Pagpapakilala

Ang mga modernong corporate content filtering system mula sa mga kilalang tagagawa gaya ng Cisco, BlueCoat, FireEye ay may napakaraming pagkakatulad sa kanilang mas makapangyarihang mga katapat - DPI system, na aktibong ipinapatupad sa pambansang antas. Ang esensya ng gawain ng dalawa ay ang pag-inspeksyon sa papasok at papalabas na trapiko sa Internet at, batay sa mga black/white list, gumawa ng desisyon na ipagbawal ang koneksyon sa Internet. At dahil pareho silang umaasa sa magkatulad na mga prinsipyo sa mga pangunahing kaalaman ng kanilang trabaho, ang mga pamamaraan para sa pag-iwas sa kanila ay magkakaroon din ng maraming pagkakatulad.

Ang isa sa mga teknolohiyang nagbibigay-daan sa iyo na lubos na ma-bypass ang parehong DPI at mga corporate system ay ang domain-fronting technology. Ang kakanyahan nito ay pumunta tayo sa isang naka-block na mapagkukunan, nagtatago sa likod ng isa pa, pampublikong domain na may magandang reputasyon, na malinaw na hindi haharangin ng anumang sistema, halimbawa google.com.

Napakaraming mga artikulo na ang naisulat tungkol sa teknolohiyang ito at maraming mga halimbawa ang ibinigay. Gayunpaman, ang sikat at kamakailang tinalakay na DNS-over-HTTPS at naka-encrypt na-SNI na teknolohiya, pati na rin ang bagong bersyon ng TLS 1.3 protocol, ay ginagawang posible na isaalang-alang ang isa pang opsyon para sa domain fronting.

Pag-unawa sa teknolohiya

Una, tukuyin natin ang kaunting mga pangunahing konsepto upang ang lahat ay magkaroon ng pang-unawa kung sino ang sino at bakit kailangan ang lahat ng ito. Binanggit namin ang mekanismo ng eSNI, ang pagpapatakbo nito ay tatalakayin pa. Ang mekanismo ng eSNI (naka-encrypt na Server Name Indication) ay isang secure na bersyon ng SNI, na available lang para sa TLS 1.3 protocol. Ang pangunahing ideya ay i-encrypt, bukod sa iba pang mga bagay, ang impormasyon tungkol sa kung saang domain ipinapadala ang kahilingan.

Ngayon tingnan natin kung paano gumagana ang mekanismo ng eSNI sa pagsasanay.

Sabihin nating mayroon tayong mapagkukunan sa Internet na na-block ng modernong solusyon sa DPI (kunin natin, halimbawa, ang sikat na torrent tracker rutracker.nl). Kapag sinubukan naming i-access ang website ng isang torrent tracker, nakikita namin ang karaniwang stub ng provider na nagsasaad na ang mapagkukunan ay naka-block:

Sa website ng RKN, nakalista ang domain na ito sa mga stop list:

Kapag nag-query ka ng whois, makikita mo na ang domain mismo ay "nakatago" sa likod ng cloud provider na Cloudflare.

Ngunit hindi tulad ng mga "espesyalista" mula sa RKN, ang mga empleyado ng Beeline na mas maalam sa teknikal (o itinuro ng mapait na karanasan ng aming sikat na regulator) ay hindi tuwang-tuwang nagbawal sa site sa pamamagitan ng IP address, ngunit idinagdag ang domain name sa stop list. Madali mong ma-verify ito kung titingnan mo kung ano ang iba pang mga domain na nakatago sa likod ng parehong IP address, bisitahin ang isa sa mga ito at makitang hindi naka-block ang access:

Paano ito nangyayari? Paano malalaman ng DPI ng provider kung aling domain ang aking browser, dahil ang lahat ng komunikasyon ay nangyayari sa pamamagitan ng https protocol, at hindi pa namin napansin ang pagpapalit ng mga https certificate mula sa Beeline? Clairvoyant ba siya o ako ang sinusundan?

Subukan nating sagutin ang tanong na ito sa pamamagitan ng pagtingin sa trapiko sa pamamagitan ng wireshark

Ipinapakita ng screenshot na unang nakukuha ng browser ang IP address ng server sa pamamagitan ng DNS, pagkatapos ay nangyayari ang karaniwang TCP handshake sa patutunguhang server, at pagkatapos ay sinusubukan ng browser na magtatag ng koneksyon sa SSL sa server. Upang gawin ito, nagpapadala ito ng SSL Client Hello packet, na naglalaman ng pangalan ng source domain sa malinaw na text. Ang field na ito ay kinakailangan ng cloudflare frontend server upang mairuta nang tama ang koneksyon. Dito kami hinuhuli ng provider na DPI, na sinira ang aming koneksyon. Kasabay nito, hindi kami nakakatanggap ng anumang stub mula sa provider, at nakikita namin ang karaniwang error sa browser na parang hindi pinagana ang site o hindi gumagana:

Ngayon, paganahin natin ang mekanismo ng eSNI sa browser, tulad ng nakasulat sa mga tagubilin para sa Firefox :
Upang gawin ito, binuksan namin ang pahina ng pagsasaayos ng Firefox tungkol sa: config at i-activate ang mga sumusunod na setting:

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

Pagkatapos nito, susuriin namin kung gumagana nang tama ang mga setting sa website ng cloudflare. link at subukan nating muli ang trick gamit ang ating torrent tracker.

Voila. Nagbukas ang aming paboritong tracker nang walang anumang VPN o proxy server. Tingnan natin ngayon ang traffic dump sa wireshark para makita kung ano ang nangyari.

Sa pagkakataong ito, ang ssl client hello package ay hindi tahasang naglalaman ng patutunguhang domain, ngunit sa halip, isang bagong field ang lumitaw sa package - encrypted_server_name - dito nakapaloob ang halaga ng rutracker.nl, at ang cloudflare frontend server lamang ang makakapag-decrypt nito patlang. At kung gayon, walang pagpipilian ang provider na DPI kundi maghugas ng kamay at payagan ang ganoong trapiko. Walang iba pang mga opsyon na may pag-encrypt.

Kaya, tiningnan namin kung paano gumagana ang teknolohiya sa browser. Ngayon subukan nating ilapat ito sa mas tiyak at kawili-wiling mga bagay. At una, ituturo namin ang parehong curl na gumamit ng eSNI para gumana sa TLS 1.3, at sa parehong oras makikita natin kung paano gumagana ang mismong fronting ng domain na nakabase sa eSNI.

Domain fronting na may eSNI

Dahil sa ang katunayan na ang curl ay gumagamit ng karaniwang openssl library upang kumonekta sa pamamagitan ng https protocol, una sa lahat kailangan naming magbigay ng suporta sa eSNI doon. Wala pang suporta sa eSNI sa mga openssl master branch, kaya kailangan naming mag-download ng espesyal na openssl branch, i-compile at i-install ito.

Kino-clone namin ang repositoryo mula sa GitHub at nag-compile gaya ng dati:

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

$ make
$ cd esnistuff
$ make

Susunod, kino-clone namin ang repositoryo gamit ang curl at i-configure ang compilation nito gamit ang aming compiled openssl library:

$ 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

Narito mahalagang tukuyin nang tama ang lahat ng mga direktoryo kung saan matatagpuan ang openssl (sa aming kaso, ito ay /opt/openssl/) at tiyaking dumadaan ang proseso ng pagsasaayos nang walang mga error.

Kung matagumpay ang pagsasaayos, makikita natin ang linya:

BABALA: pinagana ang esni ESNI ngunit may markang EXPERIMENTAL. Gamitin nang may pag-iingat!

$ make

Pagkatapos ng matagumpay na pagbuo ng package, gagamit kami ng espesyal na bash file na kasama sa openssl para i-configure at patakbuhin ang curl. Kopyahin natin ito sa direktoryo na may curl para sa kaginhawahan:

cp /opt/openssl/esnistuff/curl-esni 

at gumawa ng pagsubok na https na kahilingan sa cloudflare server, habang sabay na nagre-record ng mga DNS at TLS packet sa Wireshark.

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

Sa tugon ng server, bilang karagdagan sa maraming impormasyon sa pag-debug mula sa openssl at curl, makakatanggap kami ng HTTP na tugon na may code 301 mula sa 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/

na nagpapahiwatig na ang aming kahilingan ay matagumpay na naihatid sa patutunguhang server, narinig at naproseso.

Ngayon tingnan natin ang traffic dump sa wireshark, i.e. kung ano ang nakita ng provider DPI sa kasong ito.

Makikita na unang bumaling si curl sa DNS server para sa pampublikong eSNI key para sa cloudflare server - isang TXT DNS request sa _esni.cloudflare.com (package No. 13). Pagkatapos, gamit ang openssl library, nagpadala si curl ng TLS 1.3 na kahilingan sa cloudflare server kung saan naka-encrypt ang field ng SNI gamit ang pampublikong key na nakuha sa nakaraang hakbang (packet #22). Ngunit, bilang karagdagan sa field ng eSNI, ang SSL-hello packet ay kasama rin ang isang field na may karaniwang - bukas na SNI, na maaari naming tukuyin sa anumang pagkakasunud-sunod (sa kasong ito - www.hello-rkn.ru).

Ang bukas na field ng SNI na ito ay hindi isinasaalang-alang sa anumang paraan kapag naproseso ng mga server ng cloudflare at nagsilbing mask lamang para sa provider na DPI. Natanggap ng cloudflare server ang aming ssl-hello packet, na-decrypt ang eSNI, kinuha ang orihinal na SNI mula doon at pinoproseso ito na parang walang nangyari (ginawa nito ang lahat nang eksakto tulad ng binalak noong pagbuo ng eSNI).

Ang tanging bagay na maaaring makuha sa kasong ito mula sa isang DPI point of view ay ang pangunahing kahilingan sa DNS sa _esni.cloudflare.com. Ngunit ginawa naming bukas ang kahilingan sa DNS upang ipakita kung paano gumagana ang mekanismong ito mula sa loob.

Upang tuluyang mailabas ang alpombra mula sa ilalim ng DPI, ginagamit namin ang nabanggit na mekanismong DNS-over-HTTPS. Isang maliit na paliwanag - Ang DOH ay isang protocol na nagbibigay-daan sa iyong protektahan laban sa isang man-in-the-middle na pag-atake sa pamamagitan ng pagpapadala ng kahilingan sa DNS sa pamamagitan ng HTTPS.

Muli nating isagawa ang kahilingan, ngunit sa pagkakataong ito makakatanggap tayo ng mga pampublikong eSNI key sa pamamagitan ng https protocol, hindi DNS:

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

Ang kahilingan sa traffic dump ay ipinapakita sa screenshot sa ibaba:

Makikita na unang ina-access ng curl ang mozilla.cloudflare-dns.com server sa pamamagitan ng DoH protocol (https na koneksyon sa server 104.16.249.249) upang makuha mula sa kanila ang mga halaga ng mga pampublikong key para sa SNI encryption, at pagkatapos ay sa patutunguhan. server, nagtatago sa likod ng domain www.hello-rkn.ru.

Bilang karagdagan sa nabanggit na DoH solver na mozilla.cloudflare-dns.com, maaari naming gamitin ang iba pang sikat na serbisyo ng DoH, halimbawa, mula sa sikat na masamang korporasyon.
Patakbuhin natin ang sumusunod na query:

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

At nakuha namin ang sagot:

< 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

Sa kasong ito, bumaling kami sa naka-block na rutracker.nl server, gamit ang DoH resolver dns.google (walang typo dito, ngayon ang sikat na korporasyon ay may sariling first-level na domain) at tinakpan ang aming sarili ng isa pang domain, na mahigpit na ipinagbabawal para sa lahat ng DPI na humarang sa ilalim ng sakit ng kamatayan. Batay sa natanggap na tugon, mauunawaan mo na matagumpay na naproseso ang aming kahilingan.

Bilang karagdagang pagsusuri na tumutugon ang DPI ng provider sa bukas na SNI, na ipinadala namin bilang isang pabalat, maaari kaming humiling sa rutracker.nl sa ilalim ng pagkukunwari ng ilang iba pang ipinagbabawal na mapagkukunan, halimbawa, isa pang "mahusay" na torrent tracker:

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

Hindi kami makakatanggap ng tugon mula sa server, dahil... ang aming kahilingan ay haharangin ng sistema ng DPI.

Isang maikling konklusyon sa unang bahagi

Kaya, naipakita namin ang functionality ng eSNI gamit ang openssl at curl at sinubukan ang pagpapatakbo ng domain fronting batay sa eSNI. Sa parehong paraan, maaari naming iakma ang aming mga paboritong tool na gumagamit ng openssl library upang gumana "sa ilalim ng pagkukunwari" ng iba pang mga domain. Higit pang mga detalye tungkol dito sa aming susunod na mga artikulo.

Pinagmulan: www.habr.com