TLS 1.3 əsasında domen önləyici

Giriş

TLS 1.3 əsasında domen önləyici
Müasir korporativ məzmun filtrasiya sistemləri, Cisco, BlueCoat, FireEye kimi tanınmış istehsalçıların məhsulları, daha güclü analoqları olan DPI sistemləri ilə bir çox oxşarlıqlara malikdir. Hər iki sistemin əsası, daxil olan və çıxan internet trafikinin yoxlanılması və qara/ağ siyahılara əsaslanaraq internet bağlantısını qadağan etmək qərarını qəbul etməkdir. Həmçinin, hər iki tip sistem, iş prinsiplərində oxşar yanaşmalara əsaslandığı üçün, onların aşılması yollarında da oxşarlıqlar olacaq.

DPI və korporativ sistemləri effektiv şəkildə aşmağa imkan verən texnologiyalardan biri domən-fronting texnologiyasıdır. Bu texnologiyanın mahiyyəti, bloklanmış resursa, əvvəlcədən qadağan edilməyəcək, məsələn, google.com, reputasiyası yaxşı olan digər, açıq bir domənlə gizlənərək daxil olmaqdan ibarətdir.

Bu texnologiya haqqında artıq kifayət qədər məqalə yazılıb və bir çox nümunələr gətirilib. Lakin son zamanlarda populyar və müzakirə olunan DNS-over-HTTPS və encrypted-SNI texnologiyaları, eləcə də TLS 1.3 protokolunun yeni versiyası domən-fronting-in başqa bir variantını nəzərdən keçirməyə imkan verir.

Texnologiyaya baxırıq

İlk öncə əsas anlayışları müəyyənləşdirək ki, hamının kim kimdir və niyə bu lazımdır anlayışı olsun. Biz eSNI mexanizmi haqqında danışdıq, iş prinsipi aşağıda izah ediləcək. eSNI mexanizmi (encrypted Server Name Indication) - yalnız TLS 1.3 protokoluna aid olan, SNI-nin təhlükəsiz bir versiyasıdır. Əsas mahiyyəti - istənilən domənə göndərilən sorğunu da şifrələməkdir.

İndi gəlin eSNI mexanizminin praktikada necə işlədiyini nəzərdən keçirək.

Tutaq ki, müasir DPI sistemi tərəfindən bloklanan bir internet resursumuz var (məsələn, məşhur torrent tracker - rutracker.nl). Torrent tracker saytına daxil olmağa çalışdığımızda - provayderin resursun bloklandığı haqqında standart siqnalını görürük:

TLS 1.3 əsasında domen önləyici

RKN saytında bu domen həqiqətən də qara siyahılarda yer alır:

TLS 1.3 əsasında domen önləyici

Whois sorğusu edərkən - domenin Cloudflare adlı bulud provayderinin arxasında "gizlədildiyini" görürük.

TLS 1.3 əsasında domen önləyici

Lakin RKN "mütəxəssisləri"-dən fərqli olaraq, daha texniki biliklərə malik olan beeline işçiləri (ya da bizim məşhur tənzimləyicimizin acı təcrübəsindən dərs götürmüş olanlar) sadəcə IP ünvanına görə saytı qadağan etməyi seçmədilər, əksinə, qara siyahıya daxil etdilər domen adını.Bunun asanlıqla başa düşülməsi mümkündür, əgər eyni adlı başqa domenlərin arxasında gizləndiyinə baxsaq, IP ünvanı., onlardan birini ziyarət edərək, girişin bloklanmadığını görmək olar:

TLS 1.3 əsasında domen önləyici

Bəs bu necə olur? Provayder DPI, brauzerimin hansı domenə daxil olduğunu necə bilir? Axı bütün kommunikasiya https protokolu üzərindən baş verir, elə deyilmi? Yəqin ki, Beeline-dan https sertifikatlarının dəyişdirilməsini hələ görməmişik. Yoxsa o, görən deyil, yoxsa mənim arxamca izləmə aparılır?

Bu suala cavab verməyə çalışaq, trafiki Wireshark vasitəsilə araşdıraraq.

TLS 1.3 əsasında domen önləyici

Ekran görüntüsündə göründüyü kimi, əvvəlcə brauzer DNS vasitəsilə serverin IP ünvanını alır, sonra hədəf serverlə standart TCP əlverişi baş verir, daha sonra brauzer ssl əlaqəsini qurmağa çalışır. Bunun üçün o, paket SSL Client Hello göndərişini ötürür ki, burada açıq şəkildə əsas domenin adı mövcuddur. Bu sahə Cloudflare-nin ön uç serverinə əlaqəni düzgün yönləndirmək üçün lazımdır. Burada provayder DPI bizi tutur, bizim əlaqəmizi kəsir. Bununla yanaşı, provayder tərəfindən heç bir sayğac almırıq və brauzerdən standart xəta mesajını görürük, elə bil ki, sayt bağlıdır ya da sadəcə işləməyir:

TLS 1.3 əsasında domen önləyici

İndi gəlin brauzerdə eSNI mexanizmini aktivləşdirək, necə yazılmışdır. TIFF :
Bunun üçün Firefox-un konfiqurasiya səhifəsini açırıq. about:config və aşağıdakı parametrləri aktivləşdiririk:

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

Bundan sonra Cloudflare saytında parametrlərin düzgün işləməsini yoxlayacağıq. linkdə Və yenidən torrent izleyicimizlə bu hiyləni yoxlayacağıq.

TLS 1.3 əsasında domen önləyici

Vəssalam. Sevdiyimiz izleyici, heç bir VPN və ya proksi server olmadan açıldı. İndi gəlin Wireshark-da trafik damlasına nəzər salaq, nələr baş verdi.

TLS 1.3 əsasında domen önləyici

Bu dəfə ssl client hello paketi açıq şəkildə hədəf domenini içermir, bunun əvəzinə paketdə yeni bir sahə – encrypted_server_name mövcuddur – bu sahədə rutracker.nl dəyəri saxlanılır və onu yalnız Cloudflare-in ön uç serveri deşifrə edə bilər. Belə olduğu halda, provayderin DPI üçün başqa variant qalmır, onun əllərini yuyub belə trafiki buraxmalıdır. Və şifrələmə mövzusunda digər variantlar da yoxdur.

Beləliklə, brauzerdə texnologiyanın necə işlədiyini gördük. İndi gəlin bunu daha spesifik və maraqlı şeylər üçün tətbiq etməyə çalışaq. İlk növbədə, eSNI-dən istifadə edərək TLS 1.3 ilə işləyən curl-i öyrədək, eləcə də eSNI əsasında domen-frontalın necə işlədiyini araşdıraq.

eSNI ilə domen-frontal

Curl https protokolu vasitəsilə bağlanma üçün standart OpenSSL kitabxanasını istifadə etdiyi üçün, əvvəlcə orada eSNI dəstəyini təmin etməliyik. OpenSSL-in master şaxələrində eSNI dəstəyi hələ yoxdur, buna görə xüsusi OpenSSL şaxəsini yükləmək, tərtib etmək və quraşdırmaq məcburiyyətindəyik.

GitHub-dan repositoriyanı klonlayırıq və adət üzrə tərtib edirik:

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

$ make
$ cd esnistuff
$ make

Daha sonra curl repositoriyasını klonlayırıq və onu, bizim tərtib etdiyimiz OpenSSL kitabxanasından istifadə edərək tərtib etməyə 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 göstərmək vacibdir (bizim halımızda bu /opt/openssl-dir) və konfiqurasiya prosesinin səhvsiz keçdiyinə əmin olmaq lazımdır.

Uğurlu konfiqurasiya halında — biz aşağıdakı xətti görəcəyik:

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

$ make

Paket müvəffəqiyyətlə qurulduqdan sonra, openssl-in tərkibindəki xüsusi bash skriptindən istifadə edəcəyik ki, curl-u tənzimləyək və işə salaq. Rahatlıq üçün onu curl qovluğuna köçürəcəyik:

cp /opt/openssl/esnistuff/curl-esni 

Və eyni zamanda DNS və TLS paketlərini Wireshark-da qeyd edərək cloudflare serverinə test https sorğusu göndərəcəyik.

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

Serverdən gələn cavabda openssl və curl-dan çoxsaylı debug məlumatları ilə yanaşı cloudflare-dan 301 kodlu 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, bizim sorğunun müvəffəqiyyətlə təyinat serverinə çatdırıldığını, eşidildiyini və emal edildiyini göstərir.

İndi isə Wireshark-da trafik yığıncağına baxaq, yəni bu halda internet provayderinin DPI-sinin gördüklərini yoxlayaq.

TLS 1.3 əsasında domen önləyici

Görünür ki, əvvəlcə curl cloudflare serveri üçün açıq eSNI açarını DNS serverindən soruşub — _esni.cloudflare.com üçün TXT DNS sorğusu (paket №13). Sonra, openssl kitabxanasını istifadə edərək, curl cloudflare serverinə TLS 1.3 sorğusu göndərib və burada SNI sahəsi əvvəlki mərhələdə alınmış açıq açar ilə şifrlənib (paket №22). Lakin eSNI sahəsindən əlavə, SSL-hello paketində başqa bir sahə də var — açıq SNI, hansı ki, biz istədiyimiz qaydada göstərə bilərik (bu halda — www.hello-rkn.ru).

Bu açıq SNI sahəsi cloudflare serverləri tərəfindən emal edərkən heç bir hesaba alınmır və sadəcə provayderin DPI-sinə qarşı maska rolunu oynayır. Cloudflare serveri bizim ssl-hello paketimizi qəbul etdi, eSNI-ni şifrəni açdı, oradan orijinal SNI-ni çıxartdı və onu olduğu kimi emal etdi (bunu eSNI-nin hazırlanmasında nəzərdə tutulduğu şəkildə etdi).

Buna görə DPI-nin əlindən tutula biləcək yeganə məqam — _esni.cloudflare.com üçün ilkin DNS sorğusudur. Lakin biz DNS sorğunu açıq etdik yalnız bu mexanizmin daxili işini göstərmək üçün.

Nəhayət, DPI-nin ayağının altından yerini çəkərək, artıq deyildiyi kimi DNS-dən HTTPS vasitəsilə işləmə mexanizmini istifadə edəcəyik. Kiçik bir izah – DOH – "orta adam" hücumuna qarşı qorunmağa imkan verən protokoldur, çünki DNS sorğusunu HTTPS protokolu vasitəsilə göndərir.

Sorğunu yenidən icra edəcəyik, lakin bu dəfə açıq eSNI açarlarını https protokolu ilə alacağıq, yoxsa DNS ilə:

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

Sorğu trafikinin dump-u aşağıdakı ekranda görünür:

TLS 1.3 əsasında domen önləyici

Görünür ki, curl əvvəlcə 104.16.249.249 serverinə DoH protokolu vasitəsilə (https bağlantısı) mozilla.cloudflare-dns.com serverinə müraciət edir, SNI şifrələməsi üçün açarların dəyərlərini almaq üçün, daha sonra isə artıq hedef serverə müraciət edir, bu arada isə özünü domenlə gizlədir. www.hello-rkn.ru.

Yuxarıda qeyd olunan mozilla.cloudflare-dns.com DoH çözücüsündən əlavə, biz məşhur DoH xidmətlərini də istifadə edə bilərik, məsələn, tanınmış 'pis korporasiya' tərəfindən təqdim edilən xidmətləri.
Belə bir sorğu 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

TLS 1.3 əsasında domen önləyici

Bu halda biz bloklanmış rutracker.nl serverinə müraciət etdik, eyni zamanda DoH çözücüsü dns.google istifadə etməklə (burada heç bir yazı səhvi yoxdur, indi tanınmış korporiyanın öz birinci səviyyəli domeni var) və artıq başqa bir domenlə gizləndik, bunu isə DPI tərəfindən qadağan edilir.

SNI-nin açıq şəkildə göndərdiyimizə təminat üçün əlavə yoxlama olaraq — biz başqa bir qadağan olunmuş resursa, məsələn, başqa 'yaxşı' torrent izləyicisi ilə rutracker.nl-ə müraciət edə 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 sistemində bloklanacaq.

Birinci hissəyə qısa yekun

Beləliklə, openssl və curl vasitəsilə eSNI-nin işlədiyini göstərməyə və eSNI-yə əsaslanan domen-frontalı test etməyə müvəffəq olduq. Eyni qaydada sevdiyimiz openssl kitabxanasını istifadə edən alətlərimizi digər domenlərin ‘qarşısında’ işləməyi uyğunlaşdıra bilərik. Bununla bağlı daha ətraflı – növbəti məqalələrimizdə.

Mənbə: habr.com

DDoS qoruması olan saytlara etibarlı hosting satın alın, VPS VDS serverlər 🔥 DDoS qoruması olan saytlara etibarlı hosting satın alın, VPS VDS serverlər | ProHoster