DANE kaydı nedir?

E-posta sunucuları bugün birbirleriyle konuşurken çoğu zaman bağlantıyı şifreler. Bu iyi haber. Kötü haber şu: bu şifrelemenin çoğu, karşıdaki sunucunun gerçekten olması gereken sunucu olup olmadığını hiç sormaz. E-posta şifrelenir, ama kime şifrelendiği kontrol edilmez.

Dizinin ilk yazısında DNS cevaplarının DNSSEC ile nasıl imzalandığını anlatmıştık. DNSSEC'in e-posta için asıl işe yaradığı yer burası: sunucular arasındaki şifreli bağlantının doğrulanması. Bunu yapan standardın adı DANE.

DANE aslında e-postaya özel değil; şifreli bağlantı kuran herhangi bir hizmet için kullanılabilir. Ama bugün yaygın olarak kullanıldığı ve en çok fark yarattığı yer e-posta. Bu yazı da e-posta tarafını anlatıyor.

01Fırsatçı şifreleme ne demek

Bir e-posta sunucusu başka bir sunucuya bağlandığında önce karşı tarafa şifreli konuşup konuşamayacaklarını sorar. Karşı taraf "evet" derse bağlantı şifrelenir. Buna STARTTLS denir.

Sorun, bu sürecin "fırsatçı" olması. Şifreleme mümkünse yapılır, mümkün değilse e-posta yine de şifresiz gönderilir. Karşı tarafın sunduğu sertifika da çoğu zaman doğrulanmaz; süresi geçmiş, kendi kendine imzalanmış ya da tamamen başka bir sunucuya ait olsa bile bağlantı kurulur.

Bu iki açık kapı bırakır:

- Şifrelemeyi düşürmek. Trafiğin arasına girebilen bir saldırgan, karşı sunucunun "şifreli konuşabilirim" cevabını silebilir. Gönderen sunucu şifrelemenin mümkün olmadığını düşünür ve e-postayı düz metin olarak gönderir. - Araya kendi sunucusunu koymak. Saldırgan trafiği kendi sunucusuna yönlendirip herhangi bir sertifikayla bağlantıyı karşılayabilir. Gönderen sunucu sertifikayı doğrulamadığı için e-postayı şifreli ama yanlış sunucuya teslim eder.

İki durumda da gönderen tarafta bir hata görünmez.

02Neden web'deki gibi doğrulanmıyor

Tarayıcınız bir web sitesine bağlanırken sertifikayı sıkı biçimde doğrular; adres uyuşmazsa sizi uyarır. E-postada bunun yapılmamasının sebebi pratik: e-postanın teslim edildiği sunucunun adı çoğu zaman alan adıyla örtüşmez, birçok e-posta sunucusu da herkesçe tanınan bir sertifika kullanmaz. Sertifika doğrulaması herkes için zorunlu olsaydı, dünyadaki e-postanın önemli bir kısmı teslim edilemezdi. Bu yüzden uzun süre "şifrele ama sorgulama" yaklaşımı tercih edildi.

Eksik olan, gönderen sunucunun "bu alan adının e-posta sunucusu şifrelemeyi destekliyor ve şu anahtarı kullanıyor" bilgisini güvenilir bir kaynaktan öğrenebilmesiydi.

03DANE ne yapar

DANE bu bilgiyi DNS'e koyar. Alan adının sahibi, e-posta sunucusu için bir TLSA kaydı yayımlar; "DANE kaydı" denince kastedilen bu kayıttır. Bu kayıt kısaca şunu söyler: "Bu sunucuya bağlandığında karşına şu anahtar çıkacak."

Kayıt DNSSEC ile imzalı olduğu için sahtesi üretilemez. DANE'i destekleyen bir gönderen sunucu TLSA kaydını bulduğunda iki şey yapar:

- Şifrelemeyi zorunlu tutar. Karşı taraf şifreli bağlantı sunmuyorsa e-postayı göndermez. - Karşı tarafın sunduğu anahtarı TLSA kaydıyla karşılaştırır. Uyuşmazsa e-postayı teslim etmez, bekletir.

Böylece yukarıdaki iki saldırı da işe yaramaz hâle gelir: şifreleme düşürülemez, araya giren sunucunun anahtarı kayıtla tutmaz.

04Kimler kullanıyor

- Microsoft 365: Exchange Online, giden e-postalarda DANE doğrulamasını 2022 başında kademeli olarak devreye aldı ve bugün tüm müşteriler için varsayılan olarak açık. Microsoft 365'te barındırılan alan adları için gelen tarafta DANE ise 28 Ekim 2024'te genel kullanıma açıldı. - Açık kaynak e-posta sunucuları: Postfix gibi yaygın sunucular DANE doğrulamasını destekliyor; bunun için sunucunun DNSSEC doğrulaması yapan bir çözümleyici kullanması gerekiyor. - Kamu düzenlemeleri: Hollanda'da kamu kurumları için STARTTLS ve DANE "uygula ya da gerekçesini açıkla" listesinde zorunlu standartlar arasında. Almanya'da BSI'nin e-posta hizmet sağlayıcılarına yönelik TR-03108 teknik yönergesi, gelen ve giden e-postada DANE'i uyumluluk için zorunlu tutuyor.

Gmail tarafı farklı. Google kendi belgelerinde DANE'den değil, dizinin üçüncü yazısının konusu olan MTA-STS'ten söz ediyor. gmail.com alan adı DNSSEC ile imzalı olmadığı için Gmail adreslerine giden e-postada DANE zaten uygulanamıyor.

05Türkiye'de durum

Dizinin ilk yazısında .tr, gov.tr ve edu.tr gibi üst alan adlarının DNSSEC ile imzalı olduğunu, yani zincirin kurumların kapısına kadar hazır olduğunu göstermiştik. DANE için bir sonraki adım kurumların kendi alan adlarını ve e-posta sunucularını bu zincire bağlaması. Bunun ne kadar yapıldığını ölçtük.

Üst alan adları imzalıyken kurumların hiçbirinin bağlantıyı kurmamış olması, eksiğin tamamen kurumların kendi tarafında olduğunu gösteriyor. Yani başlamak için kimseyi beklemek gerekmiyor.

06En büyük risk: unutulan kayıt

DANE'in DNSSEC'ten devraldığı bir bedel var. TLSA kaydı sunucunun anahtarını tarif eder. Sunucunun sertifikası yenilenirken anahtar değişir ve TLSA kaydı güncellenmezse, DANE kullanan gönderen sunucular sizin sunucunuzu sahte sayar ve e-postayı teslim etmez. Sonuç, kurumunuza gelen e-postaların bir kısmının sessizce beklemeye alınmasıdır.

Bunu önlemenin bilinen yolları var:

- TLSA kaydını sertifikanın tamamına değil, yalnızca açık anahtara bağlamak ve sertifika yenilenirken aynı anahtarı korumak. Böylece sertifika yenilense de kayıt geçerli kalır. - Anahtar değişecekse, yeni anahtarın kaydını değişiklikten önce yayımlamak ve bir süre eski ve yeni kaydı birlikte tutmak. - TLSA kaydı ile sunucunun gerçekte sunduğu anahtarın uyumunu düzenli kontrol eden bir izleme kurmak.

07Nereden başlamalı

Önce DNSSEC. DANE, DNSSEC olmadan çalışmaz. Hem alan adınızın hem de e-posta sunucunuzun adının bulunduğu alan adının imzalı ve zincire bağlı olması gerekir. Bunun nasıl yapılacağını ilk yazıda anlatmıştık.

Sonra TLSA kaydı. E-posta sunucunuzun anahtarı için TLSA kaydını oluşturun ve yayımlayın. E-postanız bir bulut sağlayıcıda barındırılıyorsa bu adım sağlayıcının altyapısına bağlıdır; Microsoft 365'te gelen tarafta DANE için Microsoft'un yeni MX adreslerine geçmek gerekiyor.

Test edin. internet.nl ve Microsoft'un DANE doğrulama testi gibi ücretsiz araçlar, kaydın doğru yayımlanıp yayımlanmadığını ve sunucunun sunduğu anahtarla uyuşup uyuşmadığını gösterir.

Giden tarafı da sorun. DANE iki yönlüdür: sizin kaydınız, size e-posta gönderenleri korur. Sizin gönderdiğiniz e-postaların korunması ise kendi sunucunuzun, karşı tarafın TLSA kaydını doğrulamasına bağlıdır. Kullandığınız e-posta altyapısının giden e-postada DANE doğrulaması yapıp yapmadığını bilin.

Dizinin son yazısında, DNSSEC gerektirmeyen ve Gmail gibi büyük sağlayıcıların tercih ettiği alternatif yolu, MTA-STS'i anlatacağız.

Dizinin sonraki bölümü: MTA-STS (yakında)