Şifrelenmiş DNS: DoH ve DoT

Önceki ders, düz bir DNS aramasını bir kartpostal olarak anlattı: yol boyunca onu elleyen herkes tarafından okunabilir. O kartpostalı bir zarfa koymak için iki IETF standardı vardır: TLS üzerinden DNS (DoT, RFC 7858) ve HTTPS üzerinden DNS (DoH, RFC 8484). İkisi de aynı aramayı şifreler; esas olarak onu nasıl taşıdıkları konusunda farklılaşırlar.

TLS üzerinden DNS

RFC 7858, hedefini doğrudan belirtir: “TLS tarafından sağlanan şifreleme, DNS sorgularını gizlice dinleme ve yol üzerinde kurcalama fırsatlarını ortadan kaldırır”, bu da “neredeyse tüm DNS sorgularının şifrelenmemiş gönderildiği, bunun da onları bir saldırganın gizlice dinlemesine karşı savunmasız bıraktığı” gerçeğini ele alır. DoT, olağan 53 numaralı bağlantı noktası yerine kendi özel bağlantı noktasını, 853’ü kullanır. RFC bunun nedenini açıklar: “TLS üzerinden DNS için 53 numaralı bağlantı noktasının kullanılmamasına dair bu öneri, TLS’in kullanılıp kullanılmayacağını seçmedeki karmaşıklığı önlemek ve düşürme (downgrade) saldırılarının riskini azaltmak içindir.”

HTTPS üzerinden DNS

RFC 8484 farklı bir yol izler: “her DNS sorgu-yanıt çifti bir HTTP değişimine eşlenir”, sıradan HTTPS trafiğinin kullandığı aynı 443 numaralı bağlantı noktası üzerinden taşınır. RFC, bunun bir yan yararı olduğunu belirtir: “HTTPS’in varsayılan 443 numaralı bağlantı noktası ve DoH trafiğini aynı bağlantıda diğer HTTPS trafiğiyle karıştırma yeteneği, yetkisiz yol üzerindeki cihazların DNS işlemlerine müdahale etmesini caydırabilir”, çünkü bir arama, başka herhangi bir web isteği gibi göründüğünde tek tek ayırt edip engellemek daha zordur.

Şifrelemenin neyi gizlediği ve hâlâ neyi gizlemediği

Her iki standart da bir ağ işletmecisinin veya Wi-Fi’de gizlice dinleyen birinin aramalarınızı aktarım sırasında okumasını engeller. Hiçbiri onları gönderdiğiniz çözümleyiciden gizlemez. RFC 8484, DoH’nin sunucunun kendisinin görebildiği şeyi değiştirmediğini açıkça belirtir: “DNS sorgularının ve yanıtlarının çeşitli taşıma biçimlerinin, istekleri ilişkilendirmek için kullanılabilecek veri sağladığını” ve istemci IP adresleri, çerezler ve TLS oturum bilgisi gibi sıradan web mekaniklerinin, sunucu ucunda “DoH’nin HTTPS ile ilişkili olanların ötesinde yeni endişeler getirdiğinin bilinmediği” anlamına geldiğini belirtir. RFC 7858 de benzer şekilde DoT’un “DNS’teki diğer güvenlik sorunlarını ele almadığını” ve “şifrelenmiş mesajlarla bile, iyi konumlanmış bir tarafın mesaj zamanlaması ve boyutlarının bir analizinden belirli ayrıntılar toplayabileceğini” belirtir. Kısacası: şifrelenmiş DNS, aramalarınızı kimin gördüğünü seçtiğiniz çözümleyici işletmecisine geri taşır, görünürlüğü tamamen kaldırmaz.

Bilinmeye değer ikinci bir boşluk vardır. DNS aramasını şifrelemek, tek başına ardından hangi siteye bağlandığınızı gizlemez: bunu izleyen TLS el sıkışması normalde ana bilgisayar adını düz görünümde içerir. Cloudflare’ın Sunucu Adı Belirtimi (SNI) açıklamasının ifadesiyle, “SNI, ana bilgisayar adını Client Hello mesajına, yani bir TLS el sıkışmasının tam ilk adımına dahil eder” — şifreleme kurulmadan önce gönderilir. Şifrelenmiş SNI (ESNI) adı verilen bir uzantı, aynı kaynağın açıkladığı gibi, “Client Hello’nun SNI kısmını şifreleyerek SNI uzantısına eklenir”, bu da “istemci ile sunucu arasında gizlice dinleyen herhangi birinin istemcinin hangi sertifikayı talep ettiğini görmesini engeller.” SNI’yi gizleme desteği hâlâ hem tarayıcının hem de sitenin buna razı olmasına bağlıdır ve henüz her bağlantının çalışma şekli değildir.

macOS bunu nasıl destekler

Apple, Mac, iPhone ve iPad için tam olarak bunu yapan bir DNS Ayarları yapılandırmasını belgeler: bir cihazın “DNS over HTTPS veya DNS over TLS kullanarak bir cihazın DNS sorgularını şifrelenmiş bir DNS sunucusu üzerinden yönlendirmesine” izin verir. Bu, bir yapılandırma profili olarak sunulur; şifrelenmiş çözümleyiciyi “ek eşleşme alan adları” aracılığıyla belirli alan adlarıyla sınırlayabilir veya ağın SSID’si gibi şeyleri eşleştirebilen “istek üzerine kurallar” kullanarak yalnızca belirli ağlarda uygulayabilir.