Şifreli Tutun, Güvende Tutun: ESNI, DoH ve DoT ile Çalışmak

İnternette gizliliği koruma konusundaki en son gelişmeler, her ikisi de veri toplayıcılar tarafından oldukça tartışmalı olarak kabul edilen, şifreli TLS sunucu adı göstergesi (ESNI) ve HTTPS üzerinden DNS (DoH) biçiminde şifrelenmiş DNS'yi içerir.

İşte onların var olma nedenlerine, ne olduklarına dair ayrıntılara ve nasıl çalıştıklarının arkasındaki teknolojiye hızlı bir bakış.

DNS'nin Doğru Çalışması Gerekiyor

Bölünmüş tünel sanal özel ağ (VPN) bağlantıları, web proxy otomatik bulma (WPAD) protokolü, sıfır yapılandırmalı çok noktaya yayın DNS (mDNS), gerçek zamanlı kara listeler (RBL) ve DNS çalışmadığında yaygın olarak kullanılan diğer birçok teknoloji bozulur. t doğru şekilde çalıştırın.

Kar ve Şöhret için İnterneti Kırmak

2003 yılına kadar, internet kullanıcıları, daha sonra .com üst düzey etki alanını (TLD) işleten şirket NXDOMAIN yanıtları vermeyi durdurmayı seçtiğinde, DNS'nin küresel ölçekte önemini öğrendi. Bunun yerine, daha fazla reklam sunmak, daha fazla alan satmak ve nihayetinde daha fazla gelir elde etmek amacıyla var olmayan herhangi bir alanın kimliğine büründüler. Beklenmeyen zincirleme etki, kamuoyunda bir tartışmaya ve ICANN'in Güvenlik ve İstikrar Danışma Komitesi'nden (SSAC) ürkütücü bir rapora neden oldu. Bu proje gerçekten kapatıldı, ancak teknik açıdan güvenlik açığı devam etti.

Daha sonra 2008'de, en büyük ISP'lerden bazıları, kelimenin tam anlamıyla herhangi bir web sitesine karşı siteler arası komut dosyası çalıştırma saldırıları için çeşitli yollar sunduğunda, DNS'yi kâr amacıyla manipüle etmeye yönelik başka bir girişim halka açık olarak çağrıldı. Güvenlik açıklarının doğası gereği, özel bir ağda barındırılan ve internetten erişilemeyen web siteleri bile istismar edilebilir.

Bulunan sorun, çekirdek internet protokollerinde değil, bunun yerine belirli DNS özelliklerinden uygun olmayan şekilde para kazanılmasıyla daha da kötüleşen bir sorundur.

Paul Vixie, İnternet Sistemleri Konsorsiyumu (ISC)

Sorunun asıl nedeninin protokoller olmadığı doğru olsa da, bu protokollerin kötü aktörlerin sistemi kötüye kullanmasını engellemediği de doğrudur. Dolayısıyla teknik açıdan, güvenlik açığı devam etti.

Gözetim ve Sansür için İnterneti Kırmak

2016 yılında İran'daki İSS'lerin DNS'yi manipüle ettiği gözlemlendi. Bu sefer, reklam enjekte etmek yerine, internetteki en iyi 10.000 alan adından 139'unun e-posta sunucularına erişimi engelliyorlardı. Bunun, Çin'deki dünyaca ünlü sansüre benzer şekilde, bu belirli alanlara karşı kasıtlı bir hizmet reddi politikası mı yoksa DNS sorgularını engelleyen herhangi bir sistemin kötü teknik uygulamasının bir örneği mi olduğu açık değil.

DNS'nin neden ele geçirildiğini bilmemek önemlidir: Kapsamlı gözetim ve sansürle ilgili ahlaki ve yasal soruları bir kenara bıraksak bile, bunu yapmak için kullanılan teknoloji - doğası gereği - standartlara uygun değildir ve çok iyi müdahale ediyor olabilir. normal, günlük, makul ve yasal internet kullanımınız.

Yine de teknik açıdan, güvenlik açığı devam etti.

İnterneti Kötü Amaçlarla Kırmak

Tabii ki, internet trafiğini kendi imkanlarıyla engellemeye çalışanlar sadece ticari kuruluşlar ve hükümetler değil. Genellikle kullanıcı verilerini çalmak veya kullanıcıları önemli erişim bilgilerini ifşa etmeleri için kandırmak amacıyla bağlantıları ele geçirmeye çalışan birçok suçlu örneği vardır. En belirgin şekilde, DNS önbellek zehirlenmesi, kullanıcıları kimlik avı sitelerine yönlendirmek, fidye yazılımı dağıtmak, botnet'leri dağıtmak, belirli web sitelerine hizmeti reddetmek ve çok daha fazlası için kullanılmıştır.

TLS Kimin Kime Bağlandığını Sızdırıyor

Aktarım Katmanı Güvenliği (TLS), her gün güvendiğimiz HTTP'nin güvenli sürümü olan HTTPS'nin arkasındaki teknolojidir. Bir TLS bağlantısı kurmak, bir dizi adım gerektirir; bu sırada sunucu, bir sertifika sunarak kimliğini kanıtlar ve yeni şifreleme anahtarları değiştirilir.

Sunucunun kimliğini kanıtlamak için bir sertifika kullanması çok önemli bir adımdır, çünkü sertifikanın bir parçası asimetrik bir genel şifreleme anahtarıdır.

İstemci bu anahtarı kullanarak bir mesaj gönderdiğinde, yalnızca ilişkili özel anahtara sahip olan sunucu mesajı okuyabilir. Sonuç olarak, bağlantıyı kesen veya dinleyen herkes kilitlenir ve içeriği okuyamaz.

Bununla birlikte, bu ilk değişim hala şifreleme olmadan açık bir şekilde yapılır, bu da bir gözlemcinin her zaman sunucunun kimliğini bileceği anlamına gelir.

Etki Alanı Önleme

Birkaç anti-sansür türü araç, etki alanı cephesi olarak bilinen bir teknik kullanarak bir süre TLS'deki bu sızıntıyı çözdü. Bu, bir HTTPS bağlantısı kurulduğunda, çoğu büyük barındırma sağlayıcısının, her HTTP isteğinde sunulan ana bilgisayar adının TLS anlaşmasında kullanılanla eşleşip eşleşmediğini kontrol etmemesi gerçeğinden yararlanır. Gizlilik araçları açısından bu, gizli bir site ile gizli iletişime izin veren kullanışlı bir özellik olarak görüldü. Barındırma sağlayıcıları ve veri toplayıcıları için bu, belirtimin uygulanma biçiminin kötüye kullanılması olarak görülüyordu.

Bu başlı başına bir güvenlik açığıdır ve bu nedenle AWS dahil olmak üzere birçok büyük barındırma sağlayıcısı tarafından düzeltilmiştir.

Standardı Değiştirerek Sorunu Çözme: Şifreli SNI (ESNI)

ESNI'nin arkasındaki fikir, ilk Client Hello mesajı da dahil olmak üzere tüm mesajları şifreleyerek TLS'nin herhangi bir veri sızdırmasını önlemektir. Bu, herhangi bir gözlemciyi sunucunun hangi sunucu sertifikasını sunduğu konusunda tamamen karanlıkta bırakır.

Bunu yapmak için istemci, bağlantıyı yapmadan önce bir şifreleme anahtarına ihtiyaç duyar. Bu nedenle ESNI, DNS'deki bir SRV kaydına belirli bir ESNI şifreleme anahtarı setinin yerleştirilmesini gerektirir.

Bununla birlikte, spesifikasyon henüz kesinleşmediği için bunun kesin detayları hala değişmektedir. Buna rağmen, ESNI'nin bir uygulaması Mozilla Firefox ve Cloudflare tarafından zaten üretime alındı.

DNS Güvenliğini Sağlama ve Şifreleme

ESNI anahtarlarının ele geçirilmeden teslim edilebilmesi için DNS kurcalamasına karşı koruma sağlamak önemlidir.

1993'ten beri internet topluluğu DNS'yi güvence altına almaya çalışıyor. IETF, erken problem çözme toplantılarının aşağıdakileri tartıştığını not eder:

1. DNS verilerinin yetkisiz taraflara ifşa edilmesine karşı koruma
2. Veri bütünlüğünün sağlanması
3. Veri kaynağı kimlik doğrulaması

Bu toplantılar, 1997'de Etki Alanı Adı Sistemi Güvenlik Uzantıları (DNSSEC) standardı ile sonuçlandı. Tasarım ekibi, tüm veri ifşası tehditlerini açıkça kapsam dışı bırakmak için açık bir karar verdiğinden, standart bu endişelerin üçünden ikisini ele almayı seçti.

Bu nedenle, DNSSEC, kullanıcıların DNS sorgularına verilen yanıtların, etki alanı sahiplerinin olmasını istedikleri gibi olduğuna güvenebilecekleri anlamına gelir. ESNI bağlamında bu, aldığımız anahtarın kurcalanmadığını bildiğimiz anlamına gelir ve neyse ki, DNSSEC kullanımdayken yukarıda bahsedilen birçok güvenlik açığı ortadan kalkar. Ancak, gizliliği sağlamaz ve bu nedenle gözetim ve sansür sistemlerinin getirdiği sorunlara karşı hala savunmasızdır.

Ne yazık ki, “güvensiz DNS” ile tamamen geriye dönük uyumlu olduğundan ve doğru şekilde uygulanması oldukça zor olduğundan, DNSSEC'nin benimsenmesi çok düşüktür. Vahşi doğada görülen çok sayıda geçersiz ve yarı-kurulu konfigürasyonun kanıtladığı gibi, pek çok alan sahibi, onu yapılandırmaya çalışırken kısmen vazgeçiyor.

HTTPS üzerinden DNS (DoH)

ESNI anahtarlarının, kullanıcıların hangi siteyi ziyaret etmeye çalıştığını bilmeden teslim edilebilmesi için, DNS dinlemelerine karşı koruma sağlamak önemlidir. Hal böyle olunca da şifreli DNS'in (DoH gibi) iyi bir şey olduğunu söylemek oldukça mantıklı ve anlaşılır. Ancak bugün olduğu gibi DNS şifreli değildir.

Bunu değiştirmek için Mozilla, Google, APNIC, Cloudflare, Microsoft ve diğerlerinin hamleleri var.

İdeal Şifreli Kullanıcı Deneyimi

Yukarıdaki teknolojilerden yararlanmak isteyen bir kullanıcı, şifreleme ile çalışmanın pratik UX ayrıntıları söz konusu olduğunda oldukça uzun bir gereksinim listesine sahip olabilir. Muhtemelen, aşağıdakilerden kaçınmak isteyeceklerdir:

• Belirli bir DNS servis sağlayıcısını kullanmaya zorlanmak (ne kadar iyi olursa olsun) veya seçimin görünmez olması veya bulunması zor olması
• Bir cihazdaki her uygulama DNS'yi farklı şekilde işler (ör. Firefox, Safari'nin bulamadığı şeyleri bulabilir)
• Bir cihazdaki tüm uygulamalar kendi içinde kendi güvenli DNS uygulamasını oluşturmak zorunda
• DNS'yi birden çok kez manuel olarak yapılandırmak zorunda kalma
• Gizlilik ve güvenliği seçme zorunluluğu
• Kullanıcı izni olmadan güvenli olmayan çalışmaya geri dönen uygulamalar

Gizlilik bilincine sahip kullanıcılar bunun yerine şunları ister:

• Herhangi biri tarafından izinsiz gözetimden gizlilik
• İzin vermedikleri hedefli reklamlara karşı koruma
• Kendi yayınlanmış içeriklerinin (örneğin, kişisel bir web sitesinde) diğer izleyicilere giderken değiştirilmesine veya manipüle edilmesine karşı koruma
• Kendi yayınlanmış içeriklerini görüntüleyenlerin yalnızca içeriğe eriştikleri için başının belaya girmeyeceğine dair güvence
• DNS'yi kendi ağlarında kontrol etme seçeneğine sahip olmaya devam etmek için (çünkü bazen bölünmüş ufuk DNS, dahili kaynakları dahili kullanıcılara yönelik tutmak için iyidir)
• DNS düzeyinde filtrelemeyi etkinleştirme veya en azından devre dışı bırakma yeteneği (ör. Quad9, CleanBrowsing ve OpenDNS Family Shield)
• Kolay, sorunsuz yapılandırma (ör. DHCP)
• DNS'yi şifreleme olmadan kullanmaya onay vermeniz istenecek
• Yalnızca tarayıcı trafiği için değil, örneğin e-posta, Slack, VoIP, SSH, VPN vb. gibi tüm trafik türleri için koruma.

Mevcut Şifreleme Çalışmaları

Yukarıdaki hedeflere sahip kullanıcılar için hangi seçenekler var?

Mozilla'nın çözümü bir başlangıçtır, ancak ideal olmaktan uzaktır. Yalnızca Firefox'un güvenliğini sağlıyorlar; varsayılan, işletim sistemi ayarlarınızı, bunu söylemeden sağlayıcı seçimi (Cloudflare) lehine geçersiz kılmaktır ve sessizce güvensizliğe geri döner (şifreli DNS'nin engellenmesi vb. durumlarda)

Google'ın çözümü daha iyi bir yaklaşımdır. Tüm uygulamalar için geçerli olan Android 9+'ı güvence altına alıyorlar. (Chrome OS için planlarından emin değilim, ancak iş başında olduğundan şüpheleniyorum.) Ayrıca Chrome'u tüm platformlarda güvence altına alıyorlar, ancak yalnızca ana bilgisayar platformu güvenliği destekleyen bir sağlayıcı kullanacak şekilde yapılandırıldığında güvenliği tetikliyor. Bu, kullanıcı seçimi açısından iyidir, ancak ideal değildir çünkü sessizce güvensizliğe geri döner.

Diğer tüm büyük tarayıcılar da destek uygulamaktadır.

Kullanıcılar için ideal durumda, daha geniş yazılım ve işletim sistemi geliştiricileri topluluğu:

1. Uygulama düzeyinde yeni DNS güvenlik özelliklerini uygulamayı durdurun
2. Bunları işletim sistemi düzeyinde uygulamaya başlayın
3. İşletim sistemi düzeyinde yapılandırmaya saygı gösterin veya kullanıcı izni alın

İşletim sistemi düzeyinde şifrelenmiş DNS uygulayarak, şu anda DNS çözümleyicileri için sahip olduğumuz dağıtılmış modeli izlemeye devam edebiliriz. Kişinin kendi ağlarında kendi DNS sunucusunu çalıştırması ve bu çözümleyiciyi güvenli hale getirebilmesi, merkezi bir sağlayıcı kullanması gerektiği gibi bir seçenek olmaya devam etmesi mantıklıdır.

Linux ve BSD, mevcut çeşitli seçeneklerle bu işlevselliğe zaten sahiptir. Ne yazık ki, bildiğim kadarıyla hiçbir dağıtım varsayılan olarak hiçbirini etkinleştirmiyor. Sadece glibc'ye bağlanacak bir şey istiyorsanız nss-tls'ye göz atın.

Google'ın Android 9+ sürümündeki TLS üzerinden DNS uygulaması da bunu zaten yapıyor. DNS sunucusunu şifreleme desteği için test ederek çalışır. Elinde varsa onu kullanır. Olmazsa, Chrome'da olduğu gibi, izin istenmeden güvenli olmayan bir şekilde devam eder.

Çoğu ağın, şifrelemeyi desteklemeyen DNS sunucularını kullanacak şekilde yapılandırıldığını belirtmekte fayda var, bu nedenle Android'de yerleşik olan çözüm, çoğu kullanıcı için henüz hiçbir şeyi değiştirmez. Merkezi olmayanın şifrelemeyi desteklemediği durumlarda, merkezi bir şifreli DNS'ye geri dönmeyi önermek daha iyi olabilir.

Apple ve Microsoft lezzet cihazları için, şifreli DNS desteği bu yazı itibariyle henüz resmi olarak gelmedi. Microsoft, Kasım 2019'da şifreli DNS'yi destekleme niyetlerini açıklarken, umarım Apple yakında takip eder.

Şifreli DNS Geçici Çözümleri

Yerel olarak çalıştırılabilen proxy biçiminde bazı geçici çözümler vardır. Bunlarla, bir kullanıcının bilgisayarı şifrelenmemiş DNS'yi kendisine konuşur ve daha sonra kullanmak üzere yapılandırılan herhangi bir sağlayıcıya şifreli DNS'yi konuşur. Bu ideal bir çözüm değil, ancak geçici çözümler olarak kabul edilebilir.

Bu makaleyi yazmanın ilham kaynağı, çok kararlı, birçok özelliği olan ve çapraz platform olan DNSCrypt proxy'sidir. Eski DNSCrypt protokolünün yanı sıra daha yeni DNS over TLS (DoT) ve DNS over HTTPS (DoH) protokollerini destekler.

Windows kullanıcıları için Simple DNSCrypt adında, tüm özelliklere sahip ve kullanımı çok kolay bir yükleyici ve GUI vardır.

Bunu tavsiye ederim, ancak dünyanın muhtemelen henüz sizin için hazır olmadığını ve zaman zaman onu devre dışı bırakmanız gerekebileceğini (örneğin, en sevdiğiniz kafede veya bir LAN'da bir esir portalı kullanmanız gerektiğinde) unutmayın. Parti).

Diğer seçenekler

Ek olarak, şifreli DNS'yi destekleyen, çapraz platformlu (Windows, MacOS, Linux on ARM/Raspberry Pi) ve kaygan bir web arayüzüne sahip Technitium DNS Sunucusu vardır. "Diğer" kategorisi altındadır, çünkü bu soruna özgü bir çözümden çok çok yönlü bir araçtır. (Raspberry Pi DNS sunucunuzu evde çalıştırmak istiyorsanız bu muhtemelen iyi bir seçim olacaktır. Deneyen kişilerin yorumlarını aşağıdaki yorumlarda duymak isterim.)

Android veya iOS (iPhone, iPad vb.) cihazlarınız için tüm DNS sorgularınızı Cloudflare Şifreli DNS hizmeti üzerinden zorlayacak 1.1.1.1 uygulaması da bulunmaktadır. Intra gibi daha esnek uygulamaların da olduğunu duydum, ancak henüz onları test etmek için zaman harcamadım.

Tabii ki, hem Firefox hem de Chrome'da şifreli DNS'yi etkinleştirebilirsiniz - sadece yukarıda tartışılan tüm uyarıları aklınızda bulundurun.

DNS Güvenilirliği: Bir Numaralı İş

İnternet gizlilik teknolojisi ile ilgili çok fazla tartışma var. Ancak, güvenlik ve gizlilik önlemlerinin uygulanması söz konusu olduğunda, söz konusu teknoloji öncelikle sır saklamakla ilgili değildir. Güvenilirliği sağlamak ve başkalarının davranışlarına rağmen teknolojinin doğru şekilde çalışmaya devam etmesini garanti etmekle ilgilidir. Yine de, gizlilik önlemleri olmayan teknolojinin kötü olduğu gibi, kötü uygulanan güvenlik önlemlerinin de durumu daha da kötüleştirebileceğini unutmamalıyız.