HTTPS, bir web sitesine gönderdiklerinizi gizler, ancak Mac'inizin bu bağlantıyı açabilmesi için bile önce düz metin olarak bir soru sorması gerekir: "Bu ad hangi sunucuya işaret ediyor?" Bu soru (bir DNS araması) çoğu ağda varsayılan olarak şifrelenmeden dolaşır; bu, sayfalar daha sonra tamamen şifrelenmiş olsa bile internet sağlayıcınızın, ofis ağ yöneticinizin veya güvenli olmayan bir Wi-Fi ağını paylaşan herkesin çözdüğünüz her etki alanını görebileceği anlamına gelir.
Neden düz DNS sızıntıları
HTTPS'nin web'in varsayılanı haline gelmesinden onlarca yıl önce standartlaştırılan geleneksel DNS, sorguları düz UDP veya TCP üzerinden 53 numaralı bağlantı noktasında şifreleme olmadan gönderir ve çoğu ev ve genel ağ kurulumunda çözümleyicinin kimlik doğrulaması da yapılmaz. Bir ağ operatörünün ziyaret ettiğiniz her alan adının bir listesini oluşturmak için HTTPS'yi kırmasına gerek yoktur; yalnızca hemen yanında duran DNS trafiğinizi izlemesi gerekir. Bu aynı zamanda DNS tabanlı içerik filtrelerinin ve bazı ağ düzeyinde gözetim biçimlerinin de işe yaradığı şeydir: şifrelenmiş trafiğinizi denetleyerek değil, yalnızca bu trafiğin oluşmasından önce gerçekleşmesi gereken aramayı günlüğe kaydederek veya engelleyerek.
DoH ve DoT: aynı aramayı şifrelemenin iki yolu
İki IETF standardı, DNS sorgusunun kendisini şifrelemeye sararak bu sorunu çözer. RFC 7858'de tanımlanan DNS-over-TLS, DNS sorgularını 853 numaralı bağlantı noktasındaki özel bir şifreli TLS bağlantısına sararak onu sıradan trafikten ayırır ve bir ağın tanımlamasını kolaylaştırır ve prensip olarak bir ağın, özellikle şifrelenmiş DNS'yi durdurmak istiyorsa onu tamamen engellemesini sağlar. RFC 8484'te tanımlanan HTTPS üzerinden DNS, bunun yerine bir DNS sorgusunu, neredeyse tüm sıradan web trafiği tarafından kullanılan aynı bağlantı noktası olan 443 numaralı bağlantı noktasındaki standart bir HTTPS isteğine eşler; bu, DoH sorgularının ayırt edilmesini çok daha zorlaştıran ve dolayısıyla genel web taramasından ayrı olarak bloke eden bir tasarım tercihidir.
Apple'ın macOS 11'den bu yana yerel desteği
Apple, şifrelenmiş DNS'yi üçüncü taraf uygulamalara bırakmak yerine doğrudan ağ yığınına yerleştirdi ve bu özelliği macOS Big Sur (macOS 11) ve eşdeğer iOS 14 sürümüyle birlikte WWDC 2020'de duyurdu. Oturumda bunu açmanın iki yolu ortaya konuldu: uygulamaların programlı olarak yapılandırması için bir NEDNSSettingsManager API ve - çoğu kişinin gerçekten kullanacağı seçenek - Apple'ın cihaz yönetimi referansında belgelenen com.apple.dnsSettings.managed yükünü taşıyan, bir DoH veya DoT çözümleyicisinin adresini belirtmenize ve sistemdeki her uygulamanın bunu varsayılan olarak kullanmasını sağlamanıza olanak tanıyan, üçüncü taraf yazılıma gerek duymayan bir yapılandırma profili.
Örnek bir konfigürasyon profili
Yapılandırma profili, macOS'un çift tıklattığınızda veya Profiller bölmesine sürüklediğinizde Sistem Ayarları aracılığıyla yükleyebileceği bir XML özellik listesidir (.mobileconfig dosyası). Aşağıdaki örnek, bir Mac'in Quad9'un genel HTTPS üzerinden DNS çözümleyicisine işaret etmektedir; bu, yaygın olarak kullanılan, hesap gerektirmeyen bir hizmettir ve varsayılan olarak kimlik avı ve diğer kötü amaçlı etkinlikler için bilinen etki alanlarına yapılan bağlantıları da engeller. Kullanmadan önce yer tutucu tanımlayıcısını ve UUID değerlerini değiştirin; her gerçek profilin kendi benzersiz PayloadUUID'ine ihtiyacı vardır.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadType</key>
<string>com.apple.dnsSettings.managed</string>
<key>PayloadIdentifier</key>
<string>com.example.dns.quad9-doh</string>
<key>PayloadUUID</key>
<string>REPLACE-WITH-A-UNIQUE-UUID-1</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadDisplayName</key>
<string>Quad9 Encrypted DNS (DoH)</string>
<key>DNSSettings</key>
<dict>
<key>DNSProtocol</key>
<string>HTTPS</string>
<key>ServerURL</key>
<string>https://dns.quad9.net/dns-query</string>
<key>ServerAddresses</key>
<array>
<string>9.9.9.9</string>
<string>149.112.112.112</string>
<string>2620:fe::fe</string>
<string>2620:fe::9</string>
</array>
</dict>
</dict>
</array>
<key>PayloadDisplayName</key>
<string>Encrypted DNS - Quad9</string>
<key>PayloadIdentifier</key>
<string>com.example.dns.quad9-doh.root</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>REPLACE-WITH-A-UNIQUE-UUID-2</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>Bunun yerine Cloudflare'i kullanmak için, ServerURL'yi https://cloudflare-dns.com/dns-query olarak ve ServerAddresses'yi 1.1.1.1 ve 1.0.0.1 olarak ayarlayın (IPv6 için 2606:4700:4700::1111 ve 2606:4700:4700::1001 ile) — veya DoH yerine TLS üzerinden DNS için DNSProtocol'yi TLS ve ServerName olarak ayarlayın. one.one.one.one, Cloudflare'in yayınlanan DoT belgelerine göre.
Kurulum
- Dosyayı
.mobileconfiguzantısıyla kaydedin ve çift tıklayın veya Sistem Ayarları'nı açın, Gizlilik ve Güvenlik'e, ardından Profiller'e gidin ve dosyayı içeri sürükleyin. - macOS, siz onaylamadan önce yapılandırdığınız çözümleyici de dahil olmak üzere yük içeriğini gösterecektir; Bunu her zaman gözden geçirin, çünkü profil, güvenilmeyen bir kaynaktan bir profil yüklerseniz, kötü niyetli bir aktörün DNS'nizi tam olarak nasıl yönlendirebileceğidir.
- Yükle ve kimlik doğrulamasını tıklayın. Bu örnekteki gibi imzasız bir profil, "İmzasız" doğrulama durumu olarak gösterilir; Bu, elle oluşturulmuş bir profil için beklenen bir durumdur ve kendi başına bir kurcalama işareti değildir, ancak kişisel testin ötesindeki herhangi bir şey için, bütünlüğünün doğrulanabilmesi için profili imzalamanız gerekir.
Çalıştığını doğrulamak
Yalnızca ayarlar bölmesine güvenmeyin; terminalden kontrol edin.
# Show the resolvers macOS is actually configured to use
scutil --dns
# Look for your interface's resolver entry — it should now show
# the DoH/DoT server address you configured, not your router or ISP's resolver
# Confirm a lookup succeeds and see which resolver answered
dig example.com
# Cloudflare's own diagnostic page also reports whether your
# connection is using encrypted DNS when you open it in a browser
open https://1.1.1.1/helpscutil --dns hala yönlendiricinizin adresini veya İSS'nizin çözümleyicisini aktif DNS sunucusu olarak listeliyorsa, profil etkili olmamıştır; profili yalnızca indirmek yerine Profiller altında yüklediğinizden ve başka hiçbir ağ yapılandırmasının (aşağıya bakın) bunu geçersiz kılmadığını kontrol edin.
Bunun sessizce çalışmasını engelleyen tuzaklar
- Bir VPN uygulaması genellikle bağlıyken sistem DNS ayarlarını geçersiz kılar ve bunun yerine aramaları kendi çözümleyicisi aracılığıyla yönlendirir; DNS yapılandırmanızı bir VPN'ye bağlandıktan hemen önce değil, tekrar kontrol edin.
- Otel, havaalanı ve kafe Wi-Fi'sindeki sabit portallar, sizi bir oturum açma sayfasına yönlendirmek için düz bir DNS isteğini ele geçirmeye güvendikleri için genellikle şifreli DNS üzerinden oturum açma akışlarını tamamlayamazlar; çevrimiçi olmak için profili geçici olarak kaldırmanız veya devre dışı bırakmanız, ardından bağlandıktan sonra yeniden yüklemeniz gerekebilir.
- Aralarında Firefox ve Chrome'un da bulunduğu bazı tarayıcılar, sistem düzeyindeki yapılandırmayı geçersiz kılabilen veya kopyalayabilen kendi ayrı DoH ayarlarını sunar; davranışı
scutil --dnsraporlarıyla eşleşmiyorsa tarayıcının kendi ağ ayarlarını kontrol edin. - iCloud Özel Aktarma ve şifrelenmiş DNS, farklı, örtüşen sorunları çözer — Özel Aktarma, IP'nizi Safari'de ziyaret ettiğiniz sitelerden gizlerken, şifrelenmiş DNS, ağınızdan hangi etki alanlarını çözümlediğinizi gizler; birinin kullanılması diğerini gereksiz kılmaz.
FireAI ve HisnLabs burada nereye oturuyor
FireAI does not provide encrypted DNS today — it is on the roadmap, not in the current release — so a configuration profile like the one above is what actually closes the DNS-leak gap; FireAI’s job is different, watching and controlling which apps get to make a connection at all once that lookup resolves.
FireAI, HisnLabs’in kendi ürünüdür: doğrudan Mac’inizde çalışan, yapay zekâ destekli bir güvenlik duvarı. Uygulamalarınızın kurduğu her bağlantıyı sade bir dille gösterir ve Mac’inizden neyin çıkacağına sizin karar vermenizi sağlar — yapay zekâsı yerel olarak çalışır, yani trafiğiniz asla bize ya da başka birine gönderilmez. HisnLabs güvenlik araştırma ekibi bu kararların isabetli kalmasını sağlayan ekiptir: hangi alan adlarının sıradan telemetri, hangilerinin gerçek bir hizmet olduğunu kataloglar, bir bağlantının ardındaki ülkeyi ve ağı izler ve cihaz üzerindeki modeli (Autopilot özelliği) gerçek trafik örüntüleriyle eğitir — üstelik bunların hiçbiri Mac’inizden dışarı çıkmadan.
Arkasındaki teknik kararları okuyabilir ya da FireAI’yi 17 gün boyunca deneyebilirsiniz: HisnLabs’ten FireAI.
