kirish
Cisco, BlueCoat, FireEye kabi taniqli ishlab chiqaruvchilarning zamonaviy korporativ kontentni filtrlash tizimlari o'zlarining kuchli hamkasblari - milliy darajada faol joriy etilayotgan DPI tizimlari bilan juda ko'p umumiyliklarga ega. Ikkalasining ishining mohiyati kiruvchi va chiquvchi Internet-trafikni tekshirish va qora / oq ro'yxatlar asosida Internetga ulanishni taqiqlash to'g'risida qaror qabul qilishdir. Va ikkalasi ham o'z ishlarining asoslarida o'xshash printsiplarga tayanganligi sababli, ularni chetlab o'tish usullari ham umumiy jihatlarga ega bo'ladi.
DPI va korporativ tizimlarni samarali ravishda chetlab o'tishga imkon beradigan texnologiyalardan biri bu domenga kirish texnologiyasidir. Uning mohiyati shundaki, biz yaxshi obro'ga ega bo'lgan boshqa jamoat mulki orqasida yashirinib, bloklangan resursga o'tamiz, bu hech qanday tizim tomonidan bloklanmasligi aniq, masalan, google.com.
Ushbu texnologiya haqida allaqachon juda ko'p maqolalar yozilgan va ko'plab misollar keltirilgan. Biroq, ommabop va yaqinda muhokama qilingan DNS-over-HTTPS va shifrlangan-SNI texnologiyalari, shuningdek, TLS 1.3 protokolining yangi versiyasi domenni o'zgartirishning boshqa variantini ko'rib chiqishga imkon beradi.
Texnologiyani tushunish
Birinchidan, bir oz asosiy tushunchalarni aniqlaylik, shunda hamma kim kimligini va bularning barchasi nima uchun kerakligini tushunadi. Biz eSNI mexanizmini eslatib o'tdik, uning ishlashi keyinroq muhokama qilinadi. eSNI (shifrlangan server nomini ko'rsatish) mexanizmi SNI ning xavfsiz versiyasi bo'lib, faqat TLS 1.3 protokoli uchun mavjud. Asosiy g'oya, boshqa narsalar qatori, so'rov qaysi domenga yuborilganligi haqidagi ma'lumotlarni shifrlashdir.
Endi eSNI mexanizmi amalda qanday ishlashini ko'rib chiqamiz.
Aytaylik, bizda zamonaviy DPI yechimi tomonidan bloklangan Internet-resurs mavjud (masalan, mashhur rutracker.nl torrent trekerini olaylik). Torrent trekerining veb-saytiga kirishga harakat qilganimizda, biz provayderning resurs bloklanganligini ko'rsatadigan standart stubini ko'ramiz:
RKN veb-saytida ushbu domen aslida to'xtash ro'yxatlarida keltirilgan:
Whois-ni so'raganingizda, domenning o'zi Cloudflare bulut provayderining orqasida "yashirin" ekanligini ko'rishingiz mumkin.
Ammo RKN “mutaxassislari” dan farqli o‘laroq, “Bilayn”ning texnik jihatdan ancha bilimdon xodimlari (yoki mashhur regulyatorimizning achchiq tajribasidan o‘rgatilgan) saytni IP-manzil bo‘yicha ahmoqona ravishda taqiqlashmadi, balki domen nomini to‘xtash ro‘yxatiga qo‘shib qo‘yishdi. Agar bir xil IP manzil orqasida qanday boshqa domenlar yashiringaniga qarasangiz, ulardan biriga tashrif buyurib, kirish bloklanmaganligini ko'rsangiz, buni osongina tekshirishingiz mumkin:
Bu qanday sodir bo'ladi? Provayderning DPI brauzerim qaysi domenda ekanligini qanday biladi, chunki barcha aloqalar https protokoli orqali amalga oshiriladi va biz hali “Bilayn”dan https sertifikatlari almashtirilganini payqamadik? U bashoratlimi yoki meni kuzatib borishyaptimi?
Keling, bu savolga wireshark orqali trafikka qarab javob berishga harakat qilaylik
Skrinshotda ko'rinib turibdiki, avval brauzer DNS orqali serverning IP-manzilini oladi, so'ngra belgilangan server bilan standart TCP qo'l siqishi sodir bo'ladi va keyin brauzer server bilan SSL ulanishini o'rnatishga harakat qiladi. Buning uchun u aniq matnda manba domen nomini o'z ichiga olgan SSL Client Hello paketini yuboradi. Ushbu maydon ulanishni to'g'ri yo'naltirish uchun cloudflare frontend serveri tomonidan talab qilinadi. Bu erda DPI provayderi bizni ushlaydi va ulanishimizni buzadi. Shu bilan birga, biz provayderdan hech qanday stub olmaymiz va biz sayt o'chirilgan yoki oddiygina ishlamayotgandek standart brauzer xatosini ko'ramiz:
Endi ko'rsatmalarda yozilganidek, brauzerda eSNI mexanizmini yoqaylik :
Buning uchun Firefox konfiguratsiya sahifasini ochamiz haqida: config va quyidagi sozlamalarni faollashtiring:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Shundan so'ng, biz Cloudflare veb-saytida sozlamalar to'g'ri ishlayotganligini tekshiramiz. va keling, torrent trekerimiz bilan yana bir hiylani sinab ko'raylik.
Voila. Bizning sevimli kuzatuvchimiz VPN yoki proksi-serverlarsiz ochildi. Keling, nima bo'lganini ko'rish uchun Wiresharkdagi traffikni ko'rib chiqaylik.
Bu safar, ssl mijozi salom paketi aniq maqsad domenini o'z ichiga olmaydi, lekin uning o'rniga paketda yangi maydon paydo bo'ldi - encrypted_server_name - bu erda rutracker.nl qiymati mavjud va faqat cloudflare frontend serveri buni shifrlashi mumkin. maydon. Va agar shunday bo'lsa, DPI provayderi qo'llarini yuvishdan va bunday trafikka ruxsat berishdan boshqa tanlovi yo'q. Shifrlash bilan boshqa variantlar yo'q.
Shunday qilib, biz texnologiya brauzerda qanday ishlashini ko'rib chiqdik. Keling, buni aniqroq va qiziqarli narsalarga qo'llashga harakat qilaylik. Va birinchi navbatda, biz xuddi shu jingalakni TLS 1.3 bilan ishlash uchun eSNI-dan foydalanishni o'rgatamiz va shu bilan birga eSNI-ga asoslangan domen frontining o'zi qanday ishlashini ko'rib chiqamiz.
eSNI bilan domenni ochish
Curl https protokoli orqali ulanish uchun standart openssl kutubxonasidan foydalanganligi sababli, birinchi navbatda biz u erda eSNI yordamini taqdim etishimiz kerak. Openssl master filiallarida hali eSNI yordami mavjud emas, shuning uchun biz maxsus openssl filialini yuklab olishimiz, kompilyatsiya qilishimiz va o'rnatishimiz kerak.
Biz GitHub-dan omborni klonlaymiz va odatdagidek kompilyatsiya qilamiz:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Keyinchalik, biz omborni curl bilan klonlaymiz va kompilyatsiya qilingan openssl kutubxonamiz yordamida uning kompilyatsiyasini sozlaymiz:
$ 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
Bu erda openssl joylashgan barcha kataloglarni to'g'ri ko'rsatish muhim (bizning holatda, bu /opt/openssl/) va konfiguratsiya jarayoni xatosiz o'tishiga ishonch hosil qiling.
Agar konfiguratsiya muvaffaqiyatli bo'lsa, biz qatorni ko'ramiz:
OGOHLANTIRISH: ESNI yoqilgan, lekin EXPERIMENTAL deb belgilangan. Ehtiyotkorlik bilan foydalaning!
$ makePaketni muvaffaqiyatli qurgandan so'ng, curl-ni sozlash va ishga tushirish uchun openssl-dan maxsus bash faylidan foydalanamiz. Qulaylik uchun uni curl bilan katalogga ko'chiramiz:
cp /opt/openssl/esnistuff/curl-esni va bir vaqtning o'zida Wireshark-da DNS va TLS paketlarini yozib olish bilan birga cloudflare serveriga test https so'rovini yuboring.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Server javobida, openssl va curl-dan ko'plab disk raskadrovka ma'lumotlariga qo'shimcha ravishda, biz cloudflare-dan 301 kodi bilan HTTP javobini olamiz.
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/
bu bizning so'rovimiz maqsadli serverga muvaffaqiyatli yetkazilganligini, eshitilganligini va qayta ishlanganligini ko'rsatadi.
Keling, wireshark-dagi transport axlatini ko'rib chiqaylik, ya'ni. DPI provayderi bu holatda nimani ko'rgan.
Ko'rinib turibdiki, curl birinchi navbatda cloudflare serveri uchun umumiy eSNI kaliti - _esni.cloudflare.com ga TXT DNS so'rovi (to'plam № 13) uchun DNS serveriga aylandi. Keyin, openssl kutubxonasidan foydalanib, curl bulutflare serveriga TLS 1.3 so'rovini yubordi, unda SNI maydoni oldingi bosqichda olingan ochiq kalit bilan shifrlangan (paket № 22). Ammo, eSNI maydoniga qo'shimcha ravishda, SSL-salom paketi odatdagi - ochiq SNIga ega bo'lgan maydonni ham o'z ichiga oladi, biz uni istalgan tartibda belgilashimiz mumkin (bu holda - ).
Ushbu ochiq SNI maydoni Cloudflare serverlari tomonidan ishlov berilganda hech qanday tarzda hisobga olinmagan va faqat DPI provayderi uchun niqob sifatida xizmat qilgan. Cloudflare serveri bizning ssl-salom paketimizni oldi, eSNI shifrini ochdi, u yerdan asl SNI-ni chiqarib oldi va uni hech narsa bo'lmagandek qayta ishladi (eSNI-ni ishlab chiqishda hamma narsani rejalashtirilganidek bajardi).
Bu holatda DPI nuqtai nazaridan ushlanishi mumkin bo'lgan yagona narsa bu _esni.cloudflare.com saytiga asosiy DNS so'rovidir. Ammo biz DNS so'rovini faqat ushbu mexanizm ichkaridan qanday ishlashini ko'rsatish uchun ochiq qildik.
Nihoyat DPI ostidagi gilamni tortib olish uchun biz yuqorida aytib o'tilgan DNS-over-HTTPS mexanizmidan foydalanamiz. Kichkina tushuntirish - DOH - bu HTTPS orqali DNS so'rovini yuborish orqali o'rtadagi odam hujumidan himoya qilish imkonini beruvchi protokol.
So‘rovni yana bajaramiz, lekin bu safar biz ochiq eSNI kalitlarini DNS emas, https protokoli orqali olamiz:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/So'rov trafigini yig'ish quyidagi skrinshotda ko'rsatilgan:
Ko'rinib turibdiki, curl avval mozilla.cloudflare-dns.com serveriga DoH protokoli (https serverga 104.16.249.249 ulanishi) orqali kirib, ulardan SNI shifrlash uchun ochiq kalitlarning qiymatlarini, so'ngra belgilangan joyga kiradi. server, domen orqasida yashiringan .
Yuqoridagi mozilla.cloudflare-dns.com DoH-resolveriga qo'shimcha ravishda biz boshqa mashhur DoH xizmatlaridan, masalan, mashhur yovuz korporatsiyadan foydalanishimiz mumkin.
Keling, quyidagi so'rovni bajaramiz:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Va biz javob olamiz:
< 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
Bunday holda, biz DNS.google DoH Resolveridan foydalanib, bloklangan rutracker.nl serveriga murojaat qildik (bu erda hech qanday xatolik yo'q, endi mashhur korporatsiya o'zining birinchi darajali domeniga ega) va o'zimizni boshqa domen bilan qopladik, bu qat'iy. barcha DPIlar uchun o'lim og'rig'i ostida blokirovka qilish taqiqlangan. Qabul qilingan javobga asoslanib, so'rovimiz muvaffaqiyatli bajarilganligini tushunishingiz mumkin.
Provayderning DPI-ning biz qopqoq sifatida uzatadigan ochiq SNI-ga javob berishini qo'shimcha tekshirish sifatida biz rutracker.nl-ga boshqa taqiqlangan manba, masalan, boshqa "yaxshi" torrent trekeri niqobi ostida so'rov yuborishimiz mumkin:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Biz serverdan javob olmaymiz, chunki... bizning so'rovimiz DPI tizimi tomonidan bloklanadi.
Birinchi qismga qisqacha xulosa
Shunday qilib, biz openssl va curl-dan foydalangan holda eSNI funksionalligini namoyish etishga muvaffaq bo'ldik va eSNI-ga asoslangan domen frontining ishlashini sinab ko'rdik. Xuddi shu tarzda, biz openssl kutubxonasidan foydalanadigan sevimli vositalarimizni boshqa domenlarning "niqobi ostida" ishlashi uchun moslashtira olamiz. Bu haqda keyingi maqolalarimizda batafsil ma'lumot.
Manba: www.habr.com