DANE (DNS-Based Authentication of Named Entities), bağlantıyı şifreleyen TLS protokolünde hangi sertifika veya açık anahtarın kabul edileceğini DNS üzerinden doğrulanabilir biçimde belirtmeye yarayan bir güvenlik modelidir. Alan adlarına ait kayıtları sağlayan DNS içinde bu bilgi TLSA kaydıyla yayımlanır. Kaydın kaynağını ve bütünlüğünü doğrulayan DNSSEC, bu bilginin güvenilirliğini sağlar. E-posta aktarımı için kullanılan SMTP protokolünde DANE, alıcı posta sunucusunun TLS kimliğini denetlemeye yarar.

DANE, DNSSEC ile doğrulanmış kullanılabilir bir TLSA kaydı bulunduğunda TLS'yi isteğe bağlı olmaktan çıkarır. DANE destekli gönderen posta sunucusu, böyle bir kayıt bulduğunda hedef SMTP sunucusuyla şifreli bağlantı kurmak ve sunulan sertifika ya da açık anahtarı kayıtla doğrulamak zorundadır. DANE e-posta dışındaki TLS hizmetlerinde de kullanılabilir.

TLSA Kaydı Ne Anlatır?

TLSA kaydı, belirli bir ağ hizmeti için TLS kimliğiyle ilgili doğrulanabilir eşleştirme bilgisi taşır. Kaydın dört bölümü vardır: sertifika kullanımı güvenin nereye bağlandığını, seçici alanı tam sertifikanın mı yoksa açık anahtar bilgisinin mi karşılaştırılacağını, eşleştirme türü ise doğrudan verinin mi yoksa SHA-256 ya da SHA-512 algoritmasıyla hesaplanan özetinin mi kullanılacağını belirtir. Son bölüm, karşılaştırılacak sertifika ilişkilendirme verisini taşır.

SMTP DANE kullanımında TLSA kaydı, alan adına gelen postayı hangi sunucunun kabul ettiğini belirten MX kaydındaki hedefle ilişkilidir. Örneğin MX hedefi mx.example.com ise standart 25 numaralı port için TLSA sorgusu _25._tcp.mx.example.com adına yapılır. MX kaydı bulunmadığı için alan adının kendisine doğrudan teslimat yapılıyorsa TLSA adı da bu sunucu adına göre oluşturulur. MX hedefleri değiştiğinde TLSA yapılandırması yeni teslimat hedefleriyle uyumlu olmalıdır.

TLSA kaydı tek başına güvenilir değildir. DNS yanıtına müdahale eden bir saldırgan TLSA verisini değiştirebilseydi sahte bir sunucuyu geçerli gibi gösterebilirdi. DANE'nin güven modeli bu nedenle TLSA kaydının DNSSEC ile doğrulanmasına dayanır.

SMTP Tesliminde DANE Nasıl Çalışır?

DANE'nin e-posta teslimindeki işleyişi, alıcı alan adına hizmet veren posta sunucusunun bulunmasıyla başlar ve TLS kimliğinin doğrulanmasıyla tamamlanır. Süreçte DNSSEC ve TLSA birbirini tamamlayan iki ayrı görevi üstlenir.

  1. Gönderen posta sunucusu, alıcı alan adının MX kayıtlarını sorgular ve teslimat yapılacak SMTP sunucusunu belirler.
  2. Gönderen, MX yanıtının DNSSEC ile doğrulanmış olduğunu denetler. TLSA kaydının da ayrıca DNSSEC doğrulamasından geçmesi gerekir.
  3. Gönderen, hedef SMTP sunucusunun TLS hizmeti için yayımlanmış TLSA kaydını alır.
  4. SMTP bağlantısı kurulduğunda, mevcut bağlantıda TLS görüşmesini başlatan STARTTLS komutu kullanılır. DNSSEC ile doğrulanmış kullanılabilir TLSA kaydı bulunduğunda gönderen, teslimatı TLS olmadan sürdürmez.
  5. Hedef sunucunun sunduğu sertifika veya açık anahtar, TLSA kaydında tanımlanan eşleştirme kuralına göre doğrulanır.
  6. Kimlik doğrulaması başarısızsa gönderen, bu hedefe şifrelenmemiş teslimata dönmez. Diğer MX hedeflerini kendi TLS politikalarına göre deneyebilir; hiçbir hedefin teslimat koşulları karşılanamazsa iletiyi erteler.

Bu davranış, saldırganın TLS kullanımını engelleyip gönderen posta sunucusunu şifrelenmemiş teslimata yönlendirmesi riskini azaltır. DNSSEC ile doğrulanmış kullanılabilir bir TLSA kaydı varsa gönderen posta sunucusu, hedefin TLS kullanması gerektiğini DNSSEC ile güvence altına alınmış veriden öğrenir.

DNSSEC Neden DANE İçin Zorunludur?

DNSSEC, DNS verisinin şifrelenmesini değil, alınan kaydın yetkili kaynaktan geldiğinin ve aktarım sırasında değiştirilmediğinin doğrulanmasını amaçlar. DANE açısından kritik nokta budur: TLSA kaydının saldırgan tarafından değiştirilmediğine güvenilmeden kaydın belirttiği sertifika veya açık anahtar da güvenilir kabul edilemez.

Yalnız TLSA kaydının doğrulanması yeterli değildir; posta sunucusunu belirleyen MX yanıtı da DNSSEC ile korunmalıdır. Aksi durumda saldırgan MX yanıtını değiştirerek postayı başka bir sunucuya yönlendirebilir. İmzasız MX yanıtıyla bulunan bir sunucunun TLSA kaydı doğrulansa bile bu, postanın amaçlanan alan adına güvenle teslim edildiğini kanıtlamaz.

TLSA sorgusunun sonuçları aynı anlama gelmez:

  • Doğrulanmış ve kullanılabilir kayıt: TLS bağlantısı ve TLSA ile sunucu kimliği doğrulaması zorunludur.
  • Doğrulanmış, ancak tamamı kullanılamayan kayıtlar: Örneğin gönderenin desteklemediği eşleştirme türleri varsa TLS zorunluluğu sürer, fakat DANE kimlik doğrulaması yapılamaz. Bu durum, kullanılabilir bir kaydın sertifikayla eşleşmemesinden farklıdır.
  • İmzasız yanıt veya doğrulanmış kayıt yokluğu: DANE uygulanmaz. Başka bir zorunlu TLS politikası yoksa fırsatçı TLS, yani mümkün olduğunda şifreli bağlantı kullanıp gerektiğinde şifrelenmemiş teslimata dönebilme davranışı geçerli olabilir.
  • Sorgu veya DNSSEC doğrulama hatası: İlgili hedefe teslimat yapılmaz; başka uygun MX hedefi denenir veya ileti bekletilir. Hata, kayıt yokluğu sayılmaz.

DANE ile Sağlanan SMTP Koruması

DANE'nin temel katkısı, SMTP sunucusunun TLS kimliği ile DNS'te yayımlanan doğrulanmış beklenti arasındaki bağı güçlendirmektir. Bu bağ özellikle aktif ağ saldırılarında önem kazanır.

  • TLS düşürme saldırıları: DNSSEC ile doğrulanmış kullanılabilir TLSA kaydı varsa gönderen posta sunucusu, TLS kurulmadan ileti teslim etmez. SMTP bağlantısında TLS'yi başlatan STARTTLS desteğinin aradaki saldırgan tarafından gizlenmesi şifrelenmemiş teslimata geçiş sağlamaz.
  • Sahte TLS kimliği: Sunulan sertifika veya açık anahtar TLSA eşleştirmesini karşılamazsa DANE doğrulaması başarısız olur.
  • Genel sertifika otoritesi listelerine bağımlılık: Sertifika otoritesi, kimlik denetimi yaparak sertifika imzalayan taraftır. TLSA sertifika kullanımlarından DANE-EE(3), güveni doğrudan hedef sunucunun sertifikasına veya açık anahtarına bağlayabilir; DANE-TA(2) ise alan adı sahibinin belirlediği sertifika ya da açık anahtarı sertifika zincirinin güven dayanağı olarak kullanabilir.

Buna karşılık DANE, e-posta içeriğini göndericiden alıcıya kadar uçtan uca şifrelemez ve posta kutusuna erişim güvenliğini tek başına çözmez. Ayrıca alıcı tarafın TLSA yayımlaması, DANE desteği olmayan tüm gönderen posta sunucularını aynı davranışa zorlamaz; korumanın uygulanması için gönderen posta sunucusunun da DANE doğrulaması yapması gerekir.

DANE Yapılandırmasında DNSSEC, MX ve Sertifika Uyumu

Bütün teslimat hedeflerinde DANE koruması için her MX sunucusunun TLS desteği ve kullanılabilir TLSA kaydı bulunmalıdır. Gönderen, MX öncelik sırasını yalnız başka bir sunucuda TLSA kaydı var diye değiştirmez. TLSA kaydı eksik bir hedefe teslimat yapılabiliyorsa, diğer hedeflerin DANE kullanması o bağlantıyı da korumaz.

Yeni sertifika veya açık anahtar mevcut TLSA eşleştirmesini karşılamayacaksa geçişten önce eski ve yeni kimlikle eşleşen kayıtlar birlikte yayımlanır. DNS kayıtlarının önbellekte tutulma süresini belirleyen TTL değerleri dikkate alınarak eski TLSA yanıtının ve ilgili imza kayıtlarının önbelleklerden çıkması beklenir; ardından SMTP sunucusu yeni kimliği kullanmaya başlar. Tüm ilgili sunucular yeni kimliğe geçtikten sonra artık kullanılmayan eski TLSA kaydı kaldırılır. Bu sıra izlenmezse DANE kullanan gönderen posta sunucuları yeni kimliği doğrulayamaz ve teslimatı erteleyebilir.

DANE ile Diğer SMTP TLS Mekanizmaları Arasındaki Farklar

DANE güven bilgisini DNSSEC ile doğrulanan TLSA kayıtlarından alır. SMTP tesliminde TLS kullanım politikasını belirleyen MTA-STS ise politikanın varlığını DNS ile bildirir, içeriğini şifreli web bağlantısı sağlayan HTTPS üzerinden yayımlar. MTA-STS, MX adlarını ve güvenilen sertifika otoritelerine uzanan sertifika zincirini denetler; zorlayıcı enforce modunda başarısız denetim teslimatı engeller. SMTP TLS raporlama mekanizması TLS-RPT, DANE veya MTA-STS doğrulama sorunlarını toplu raporlarla bildirir, ancak kendi başına şifrelemeyi zorunlu tutmaz. Bu mekanizmalar aynı alan adında birlikte kullanılabilir.