TLS 1.3'e dayalı alan adı ön gösterimi

Giriş

TLS 1.3'e dayalı alan adı ön gösterimi
Cisco, BlueCoat, FireEye gibi tanınmış üreticilerin modern kurumsal içerik filtreleme sistemlerinin, ulusal düzeyde aktif olarak uygulanan DPI sistemleri olan daha güçlü muadilleriyle pek çok ortak noktası vardır. Her ikisinin de işinin özü, gelen ve giden İnternet trafiğini incelemek ve kara/beyaz listelere dayanarak İnternet bağlantısını yasaklama kararı vermektir. Ve her ikisi de işlerinin temellerinde benzer ilkelere dayandıkları için, onları atlatmaya yönelik yöntemlerin de pek çok ortak noktası olacaktır.

Hem DPI hem de kurumsal sistemleri oldukça etkili bir şekilde atlamanıza olanak tanıyan teknolojilerden biri de alan adı ön teknolojisidir. Bunun özü, engellenen bir kaynağa gitmemiz, iyi bir itibara sahip başka bir kamu alanının arkasına saklanmamızdır ve bu, herhangi bir sistem tarafından açıkça engellenmeyecektir, örneğin google.com.

Bu teknoloji hakkında zaten pek çok makale yazıldı ve birçok örnek verildi. Bununla birlikte, popüler ve yakın zamanda tartışılan HTTPS üzerinden DNS ve şifreli SNI teknolojileri ve ayrıca TLS 1.3 protokolünün yeni sürümü, alan adı yönlendirme için başka bir seçeneğin dikkate alınmasını mümkün kılmaktadır.

Teknolojiyi anlamak

Öncelikle kimin kim olduğunu ve tüm bunlara neden ihtiyaç duyulduğunu herkesin anlayabilmesi için biraz temel kavramları tanımlayalım. İşleyişi daha sonra tartışılacak olan eSNI mekanizmasından bahsetmiştik. eSNI (şifreli Sunucu Adı Göstergesi) mekanizması, SNI'nin güvenli bir sürümüdür ve yalnızca TLS 1.3 protokolü için kullanılabilir. Ana fikir, diğer şeylerin yanı sıra, isteğin hangi alana gönderildiğine ilişkin bilgileri şifrelemektir.

Şimdi eSNI mekanizmasının pratikte nasıl çalıştığına bakalım.

Diyelim ki modern bir DPI çözümü tarafından engellenen bir İnternet kaynağımız var (örneğin ünlü torrent izleyici rutracker.nl'yi ele alalım). Bir torrent izleyicinin web sitesine erişmeye çalıştığımızda, sağlayıcının kaynağın engellendiğini belirten standart saplamasını görüyoruz:

TLS 1.3'e dayalı alan adı ön gösterimi

RKN web sitesinde bu alan adı aslında durak listelerinde listeleniyor:

TLS 1.3'e dayalı alan adı ön gösterimi

Whois sorgusu yaptığınızda alan adının kendisinin bulut sağlayıcı Cloudflare'in arkasında "gizli" olduğunu görebilirsiniz.

TLS 1.3'e dayalı alan adı ön gösterimi

Ancak RKN'nin "uzmanlarından" farklı olarak, Beeline'ın teknik açıdan daha bilgili çalışanları (veya ünlü düzenleyicimizin acı deneyiminden ders almış), siteyi IP adresine göre aptalca yasaklamadılar, ancak alan adını durma listesine eklediler. Aynı IP adresinin arkasında başka hangi alanların gizlendiğine bakıp bunlardan birini ziyaret edip erişimin engellenmediğini görürseniz bunu kolayca doğrulayabilirsiniz:

TLS 1.3'e dayalı alan adı ön gösterimi

Bu nasıl oluyor? Tüm iletişimler https protokolü üzerinden gerçekleştiğinden ve Beeline'dan https sertifikalarının değiştirildiğini henüz fark etmediğimizden, sağlayıcının DPI'sı tarayıcımın hangi etki alanında olduğunu nasıl biliyor? O mu kahin yoksa ben mi takip ediliyorum?

Bu soruyu Wireshark üzerinden trafiğe bakarak cevaplamaya çalışalım.

TLS 1.3'e dayalı alan adı ön gösterimi

Ekran görüntüsü, tarayıcının önce sunucunun IP adresini DNS aracılığıyla aldığını, ardından hedef sunucuyla standart bir TCP anlaşmasının gerçekleştiğini ve ardından tarayıcının sunucuyla bir SSL bağlantısı kurmaya çalıştığını gösteriyor. Bunu yapmak için, kaynak etki alanının adını açık metin olarak içeren bir SSL İstemci Merhaba paketi gönderir. Bu alan, bağlantıyı doğru şekilde yönlendirmek için cloudflare ön uç sunucusu tarafından gereklidir. Sağlayıcı DPI'nın bizi yakalayıp bağlantımızı kestiği yer burasıdır. Aynı zamanda, sağlayıcıdan herhangi bir taslak almıyoruz ve sanki site devre dışı bırakılmış veya çalışmıyormuş gibi standart tarayıcı hatasını görüyoruz:

TLS 1.3'e dayalı alan adı ön gösterimi

Şimdi tarayıcıda eSNI mekanizmasını talimatlarda yazıldığı gibi etkinleştirelim. Firefox :
Bunu yapmak için Firefox yapılandırma sayfasını açıyoruz about: config ve aşağıdaki ayarları etkinleştirin:

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

Bundan sonra cloudflare web sitesinde ayarların doğru çalışıp çalışmadığını kontrol edeceğiz. bağlantı ve torrent izleyicimizle bu numarayı tekrar deneyelim.

TLS 1.3'e dayalı alan adı ön gösterimi

Voila. Favori izleyicimiz herhangi bir VPN veya proxy sunucusu olmadan açıldı. Şimdi ne olduğunu görmek için Wireshark'taki trafik dökümüne bakalım.

TLS 1.3'e dayalı alan adı ön gösterimi

Bu sefer, SSL istemcisi merhaba paketi hedef etki alanını açıkça içermiyor, bunun yerine pakette yeni bir alan belirdi - şifrelenmiş_sunucu_adı - burası rutracker.nl değerinin bulunduğu yerdir ve yalnızca cloudflare ön uç sunucusu bunun şifresini çözebilir alan. Ve eğer öyleyse, o zaman sağlayıcı DPI'nın ellerini yıkamaktan ve bu tür trafiğe izin vermekten başka seçeneği yoktur. Şifrelemeyle başka seçenek yoktur.

Böylece teknolojinin tarayıcıda nasıl çalıştığına baktık. Şimdi bunu daha spesifik ve ilginç şeylere uygulamaya çalışalım. İlk olarak, eSNI'yi TLS 1.3 ile çalışmak için kullanmak için aynı curl'u öğreteceğiz ve aynı zamanda eSNI tabanlı alan ön yüzünün nasıl çalıştığını göreceğiz.

eSNI ile alan adı ön yüzü

curl https protokolü üzerinden bağlanmak için standart openssl kütüphanesini kullandığından dolayı öncelikle orada eSNI desteğini sağlamamız gerekiyor. Openssl ana dallarında henüz eSNI desteği yok bu nedenle özel bir openssl dalını indirip derleyip kurmamız gerekiyor.

Depoyu GitHub'dan kopyalıyoruz ve her zamanki gibi derliyoruz:

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

$ make
$ cd esnistuff
$ make

Daha sonra, depoyu curl ile klonlarız ve derlenmiş openssl kütüphanemizi kullanarak derlemesini yapılandırırız:

$ 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'nin bulunduğu tüm dizinleri doğru bir şekilde belirtmek (bizim durumumuzda bu /opt/openssl/) ve konfigürasyon işleminin hatasız geçtiğinden emin olmak önemlidir.

Yapılandırma başarılı olursa şu satırı göreceğiz:

UYARI: esni ESNI etkinleştirildi ancak DENEYSEL olarak işaretlendi. Dikkatle kullanın!

$ make

Paketi başarıyla oluşturduktan sonra, curl'u yapılandırmak ve çalıştırmak için openssl'den özel bir bash dosyası kullanacağız. Kolaylık sağlamak için onu curl içeren dizine kopyalayalım:

cp /opt/openssl/esnistuff/curl-esni 

ve aynı anda Wireshark'ta DNS ve TLS paketlerini kaydederken cloudflare sunucusuna bir test https isteği yapın.

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

Sunucu yanıtında openssl ve curl'den gelen birçok hata ayıklama bilgisine ek olarak cloudflare'den 301 kodlu bir HTTP yanıtı alacağız.

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, isteğimizin başarıyla hedef sunucuya iletildiğini, duyulduğunu ve işlendiğini gösterir.

Şimdi Wireshark'taki trafik dökümüne bakalım. sağlayıcı DPI'nın bu durumda gördüğü şey.

TLS 1.3'e dayalı alan adı ön gösterimi

Curl'ün, cloudflare sunucusu için genel bir eSNI anahtarı için ilk olarak DNS sunucusuna başvurduğu görülebilir - _esni.cloudflare.com'a bir TXT DNS isteği (paket No. 13). Daha sonra, openssl kütüphanesini kullanarak curl, SNI alanının önceki adımda elde edilen genel anahtarla (paket #1.3) şifrelendiği cloudflare sunucusuna bir TLS 22 isteği gönderdi. Ancak, eSNI alanına ek olarak, SSL-merhaba paketi aynı zamanda herhangi bir sırayla belirtebileceğimiz olağan - açık SNI'ya sahip bir alan da içeriyordu (bu durumda - www.hello-rkn.ru).

Bu açık SNI alanı, cloudflare sunucuları tarafından işlenirken hiçbir şekilde dikkate alınmadı ve yalnızca sağlayıcı DPI için maske görevi gördü. Cloudflare sunucusu ssl-merhaba paketimizi aldı, eSNI'nin şifresini çözdü, orijinal SNI'yı oradan çıkardı ve sanki hiçbir şey olmamış gibi işledi (eSNI'yi geliştirirken her şeyi tam olarak planlandığı gibi yaptı).

Bu durumda DPI açısından yakalanabilecek tek şey, _esni.cloudflare.com'a yapılan birincil DNS isteğidir. Ama biz DNS isteğini sadece bu mekanizmanın içeriden nasıl çalıştığını göstermek için açık yaptık.

Sonunda halıyı DPI'nın altından çıkarmak için, daha önce bahsedilen DNS-over-HTTPS mekanizmasını kullanıyoruz. Küçük bir açıklama - DOH, HTTPS üzerinden bir DNS isteği göndererek ortadaki adam saldırısına karşı korunmanıza olanak tanıyan bir protokoldür.

İsteği tekrar yürütelim, ancak bu sefer genel eSNI anahtarlarını DNS değil, https protokolü aracılığıyla alacağız:

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

İstek trafiği dökümü aşağıdaki ekran görüntüsünde gösterilmektedir:

TLS 1.3'e dayalı alan adı ön gösterimi

Curl'ün önce mozilla.cloudflare-dns.com sunucusuna DoH protokolü (104.16.249.249 sunucusuna https bağlantısı) aracılığıyla erişerek onlardan SNI şifrelemesi için genel anahtarların değerlerini ve ardından hedefe eriştiği görülebilir. sunucu, etki alanının arkasına saklanıyor www.hello-rkn.ru.

Yukarıdaki DoH çözümleyici mozilla.cloudflare-dns.com'a ek olarak, örneğin ünlü şeytani şirkete ait diğer popüler DoH hizmetlerini de kullanabiliriz.
Aşağıdaki sorguyu çalıştıralım:

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

Ve cevabı alıyoruz:

< 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'e dayalı alan adı ön gösterimi

Bu durumda, DoH çözümleyici dns.google'ı kullanarak engellenen rutracker.nl sunucusuna döndük (burada yazım hatası yok, artık ünlü şirketin kendi birinci düzey etki alanı var) ve kendimizi kesinlikle başka bir etki alanıyla kapladık. Tüm DPI'ların ölüm acısı altında bloke edilmesi yasaktır. Alınan cevaba göre talebimizin başarıyla işleme alındığını anlayabilirsiniz.

Sağlayıcının DPI'sinin kapak olarak ilettiğimiz açık SNI'ye yanıt verip vermediğinin ek bir kontrolü olarak, başka bir yasaklı kaynağın, örneğin başka bir "iyi" torrent izleyicinin kisvesi altında rutracker.nl'ye bir talepte bulunabiliriz:

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

Sunucudan yanıt alamayacağız çünkü... isteğimiz DPI sistemi tarafından engellenecektir.

İlk bölümün kısa özeti

Böylece, openssl ve curl kullanarak eSNI'nin işlevselliğini gösterebildik ve eSNI'ya dayalı alan adı ön izlemenin çalışmasını test edebildik. Aynı şekilde, openssl kütüphanesini kullanan favori araçlarımızı diğer alanların "kisvesi altında" çalışacak şekilde uyarlayabiliriz. Bu konuyla ilgili daha detaylı bilgiyi sonraki makalelerimizde bulabilirsiniz.

Kaynak: habr.com

Yorum ekle