Giriş
Cisco, BlueCoat, FireEye kimi məşhur istehsalçıların müasir korporativ məzmun filtrləmə sistemləri milli səviyyədə fəal şəkildə tətbiq olunan daha güclü həmkarları - DPI sistemləri ilə kifayət qədər ümumi cəhətlərə malikdir. Hər ikisinin işinin mahiyyəti daxil olan və gedən internet trafikini yoxlamaq və qara/ağ siyahılar əsasında internetə qoşulmanı qadağan etmək barədə qərar qəbul etməkdir. Və onların hər ikisi işlərinin əsaslarında oxşar prinsiplərə güvəndikləri üçün onlardan yan keçmək üsulları da çoxlu ümumi cəhətlərə malik olacaqdır.
Həm DPI, həm də korporativ sistemləri kifayət qədər effektiv şəkildə yan keçməyə imkan verən texnologiyalardan biri domen ön texnologiyasıdır. Onun mahiyyəti ondan ibarətdir ki, biz yaxşı reputasiyaya malik başqa bir ictimai domenin arxasında gizlənərək, heç bir sistem, məsələn, google.com tərəfindən bloklanmayacaq bir resursa gedirik.
Bu texnologiya haqqında artıq kifayət qədər məqalələr yazılmış və çoxlu nümunələr verilmişdir. Bununla belə, populyar və bu yaxınlarda müzakirə edilən DNS-over-HTTPS və şifrələnmiş SNI texnologiyaları, həmçinin TLS 1.3 protokolunun yeni versiyası domen cəbhəsi üçün başqa variantı nəzərdən keçirməyə imkan verir.
Texnologiyanı başa düşmək
Əvvəlcə bir az əsas anlayışları müəyyən edək ki, hər kəs kimin kim olduğunu və bütün bunların nə üçün lazım olduğunu başa düşsün. Əməliyyatı daha sonra müzakirə ediləcək eSNI mexanizmini qeyd etdik. eSNI (şifrələnmiş Server Adı Göstərişi) mexanizmi SNI-nin təhlükəsiz versiyasıdır və yalnız TLS 1.3 protokolu üçün mövcuddur. Əsas ideya, digər şeylərlə yanaşı, sorğunun hansı domenə göndərildiyi barədə məlumatları şifrələməkdir.
İndi eSNI mexanizminin praktikada necə işlədiyinə baxaq.
Tutaq ki, müasir DPI həlli ilə bloklanmış İnternet resursumuz var (məsələn, məşhur torrent izləyicisi rutracker.nl-i götürək). Torrent izləyicisinin veb saytına daxil olmağa çalışarkən, resursun bloklandığını göstərən provayderin standart stubunu görürük:
RKN saytında bu domen əslində dayanma siyahılarında verilmişdir:
Whois sorğusunda domenin özünün Cloudflare bulud provayderinin arxasında “gizləndiyini” görə bilərsiniz.
Ancaq RKN-nin "mütəxəssislərindən" fərqli olaraq, Beeline-ın texniki cəhətdən daha fərasətli işçiləri (və ya məşhur tənzimləyicimizin acı təcrübəsi ilə öyrədilmiş) saytı ağılsızcasına IP ünvanı ilə qadağan etmədilər, lakin domen adını stop siyahısına əlavə etdilər. Eyni IP ünvanının arxasında hansı digər domenlərin gizləndiyinə baxsanız, onlardan birinə baş çəkin və girişin bloklanmadığını görsəniz, bunu asanlıqla yoxlaya bilərsiniz:
Bu necə baş verir? Provayderin DPI brauzerimin hansı domendə olduğunu necə bilir, çünki bütün kommunikasiyalar https protokolu vasitəsilə baş verir və biz Beeline-dan https sertifikatlarının dəyişdirilməsini hələ görməmişik? O, görücüdür, yoxsa məni izləyirlər?
Wireshark vasitəsilə trafikə baxaraq bu suala cavab verməyə çalışaq
Ekran görüntüsü göstərir ki, əvvəlcə brauzer DNS vasitəsilə serverin IP ünvanını alır, sonra təyinat serveri ilə standart TCP əl sıxması baş verir və sonra brauzer serverlə SSL əlaqəsi yaratmağa çalışır. Bunun üçün o, aydın mətndə mənbə domeninin adını ehtiva edən SSL Client Hello paketini göndərir. Bağlantını düzgün istiqamətləndirmək üçün bu sahə cloudflare frontend serveri tərəfindən tələb olunur. Bu, provayder DPI-nin əlaqəmizi pozaraq bizi tutduğu yerdir. Eyni zamanda, biz provayderdən heç bir stub almırıq və biz standart brauzer xətasını görürük ki, sayt deaktiv edilib və ya sadəcə işləmir:
İndi təlimatlarda yazıldığı kimi brauzerdə eSNI mexanizmini işə salaq :
Bunu etmək üçün Firefox konfiqurasiya səhifəsini açırıq Haqqında: config və aşağıdakı parametrləri aktivləşdirin:
network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true
Bundan sonra biz cloudflare saytında parametrlərin düzgün işlədiyini yoxlayacağıq. və gəlin torrent izləyicimizlə hiyləni yenidən sınayaq.
Voila. Sevimli izləyicimiz heç bir VPN və ya proxy server olmadan açıldı. İndi nə baş verdiyini görmək üçün Wireshark-dakı trafik zibilliyinə baxaq.
Bu dəfə, ssl müştəri salam paketi açıq şəkildə təyinat domenini ehtiva etmir, əksinə paketdə yeni bir sahə meydana çıxdı - encrypted_server_name - bu, rutracker.nl dəyərinin olduğu yerdir və yalnız cloudflare frontend serveri bunu deşifrə edə bilər. sahə. Əgər belədirsə, onda DPI provayderinin əllərini yumaqdan və bu cür trafikə icazə verməkdən başqa çarəsi yoxdur. Şifrələmə ilə başqa seçimlər yoxdur.
Beləliklə, texnologiyanın brauzerdə necə işlədiyinə baxdıq. İndi gəlin bunu daha konkret və maraqlı şeylərə tətbiq etməyə çalışaq. Birincisi, biz eyni qıvrıla TLS 1.3 ilə işləmək üçün eSNI-dən istifadə etməyi öyrədəcəyik və eyni zamanda eSNI əsaslı domen cəbhəsinin özünün necə işlədiyini görəcəyik.
eSNI ilə domen cəbhəsi
Curl https protokolu ilə qoşulmaq üçün standart openssl kitabxanasından istifadə etdiyinə görə, ilk növbədə biz orada eSNI dəstəyini təmin etməliyik. Openssl master filiallarında hələ eSNI dəstəyi yoxdur, ona görə də biz xüsusi openssl filialını endirməli, onu tərtib edib quraşdırmalıyıq.
Biz anbarı GitHub-dan klonlayırıq və həmişəki kimi tərtib edirik:
$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config
$ make
$ cd esnistuff
$ make
Sonra, repozitoriyanı curl ilə klonlayırıq və tərtib edilmiş openssl kitabxanamızdan istifadə edərək onun tərtibini konfiqurasiya edirik:
$ 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
Burada openssl-in yerləşdiyi bütün qovluqları düzgün müəyyən etmək vacibdir (bizim vəziyyətimizdə bu, /opt/openssl/) və konfiqurasiya prosesinin səhvsiz keçdiyinə əmin olmaqdır.
Konfiqurasiya uğurlu olarsa, xətti görəcəyik:
XƏBƏRDARLIQ: ESNI aktivdir, lakin EKSPERİMENTAL olaraq qeyd olunur. Ehtiyatla istifadə edin!
$ makePaketi uğurla qurduqdan sonra curl-u konfiqurasiya etmək və işə salmaq üçün openssl-dən xüsusi bash faylından istifadə edəcəyik. Rahatlıq üçün onu curl ilə qovluğa kopyalayaq:
cp /opt/openssl/esnistuff/curl-esni və eyni zamanda Wireshark-da DNS və TLS paketlərini qeyd edərkən cloudflare serverinə test https sorğusu göndərin.
$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/Server cavabında, openssl və curl-dan çoxlu sazlama məlumatlarına əlavə olaraq, cloudflare-dən 301 kodu ilə HTTP cavabı alacağıq.
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, sorğumuzun təyinat serverinə uğurla çatdırıldığını, eşidildiyini və işləndiyini göstərir.
İndi Wireshark-da trafik zibilliyinə baxaq, yəni. provayder DPI bu vəziyyətdə nə gördü.
Görünür ki, curl əvvəlcə cloudflare serveri üçün ictimai eSNI açarı üçün DNS serverinə çevrildi - _esni.cloudflare.com ünvanına TXT DNS sorğusu (paket No. 13). Sonra openssl kitabxanasından istifadə edərək, curl SNI sahəsinin əvvəlki addımda əldə edilmiş açıq açarla şifrələndiyi cloudflare serverinə TLS 1.3 sorğusu göndərdi (paket #22). Lakin, eSNI sahəsinə əlavə olaraq, SSL-salam paketinə istənilən qaydada təyin edə biləcəyimiz adi - açıq SNI olan bir sahə də daxildir (bu halda - ).
Bu açıq SNI sahəsi cloudflare serverləri tərəfindən işlənərkən heç bir şəkildə nəzərə alınmadı və yalnız DPI provayderi üçün maska kimi xidmət etdi. Cloudflare serveri ssl-salam paketimizi qəbul etdi, eSNI-nin şifrəsini açdı, orijinal SNI-ni oradan çıxardı və heç nə olmamış kimi emal etdi (eSNI-ni inkişaf etdirərkən hər şeyi planlaşdırıldığı kimi etdi).
Bu vəziyyətdə DPI nöqteyi-nəzərindən tutula bilən yeganə şey _esni.cloudflare.com ünvanına edilən əsas DNS sorğusudur. Lakin biz DNS sorğusunu yalnız bu mexanizmin içəridən necə işlədiyini göstərmək üçün açıq etdik.
Nəhayət, xalçanı DPI altından çıxarmaq üçün biz artıq qeyd olunan DNS-over-HTTPS mexanizmindən istifadə edirik. Kiçik bir izahat - DOH HTTPS üzərindən DNS sorğusu göndərməklə ortada olan adam hücumundan qorunmağa imkan verən protokoldur.
Sorğunu yenidən icra edək, lakin bu dəfə biz DNS deyil, https protokolu vasitəsilə ictimai eSNI açarlarını alacağıq:
ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/Sorğu trafik zibilliyi aşağıdakı ekran görüntüsündə göstərilir:
Görünür ki, curl əvvəlcə Mozilla.cloudflare-dns.com serverinə SNI şifrələməsi üçün açıq açarların dəyərlərini əldə etmək üçün DoH protokolu (https serverə 104.16.249.249) vasitəsilə daxil olur, sonra isə təyinat yerinə server, domenin arxasında gizlənir .
Yuxarıda göstərilən DoH həlledicisinə əlavə olaraq mozilla.cloudflare-dns.com, biz digər məşhur DoH xidmətlərindən, məsələn, məşhur şər korporasiyasından istifadə edə bilərik.
Gəlin aşağıdakı sorğunu icra edək:
ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Və cavabı alırıq:
< 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
Bu halda, biz DoH həlledicisi dns.google-dan istifadə edərək bloklanmış rutracker.nl serverinə müraciət etdik (burada heç bir yazı səhvi yoxdur, indi məşhur korporasiyanın öz birinci səviyyəli domeni var) və özümüzü başqa bir domenlə əhatə etdik, bu da ciddi şəkildə bütün DPI-lərin ölüm ağrısı altında bloklanması qadağandır. Alınan cavaba əsasən başa düşə bilərsiniz ki, sorğumuz uğurla icra olunub.
Provayderin DPI-nin örtük kimi ötürdüyümüz açıq SNI-yə cavab verdiyini yoxlamaq üçün başqa bir qadağan olunmuş resurs, məsələn, başqa bir "yaxşı" torrent izləyicisi adı altında rutracker.nl-ə sorğu göndərə bilərik:
$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/Serverdən cavab almayacağıq, çünki... sorğumuz DPI sistemi tərəfindən bloklanacaq.
Birinci hissəyə qısa yekun
Beləliklə, biz openssl və curl istifadə edərək eSNI-nin funksionallığını nümayiş etdirə və eSNI əsasında domen cəbhəsinin işini sınaqdan keçirə bildik. Eyni şəkildə, biz openssl kitabxanasından istifadə edən sevimli alətlərimizi digər domenlərin “kimi altında” işləmək üçün uyğunlaşdıra bilərik. Bu barədə ətraflı məlumatı növbəti yazılarımızda tapa bilərsiniz.
Mənbə: www.habr.com