STARTTLS yalan söylüyor: DANE/TLSA ile SMTP'de zorunlu ve doğrulanabilir TLS
SMTP'de STARTTLS fırsatçıdır: sertifika doğrulamaz, kendinden imzalıyı kabul eder ve araya giren biri bağlantıyı sessizce düz metne düşürebilir. TLS'i hem zorunlu hem doğrulanabilir yapan tek mekanizma DANE/TLSA'dır. Üretimde işleyen kayıtlar, Postfix konfigürasyonu ve ayağınıza sıkmadan rollover disiplini.
EvilMail Team19 Temmuz 202613 dk okuma
İki mail sunucusu STARTTLS ile "şifreli" konuşuyorsa çoğu yönetici işini bitmiş sayar. Bitmemiştir. SMTP'de TLS, HTTPS'in aksine protokole sonradan yamanmış bir eklentidir ve varsayılan davranışı hâlâ o mirasın izini taşır: fırsatçı, doğrulamasız, geri düşürülebilir. Şifreleme kutucuğu işaretlidir ama karşı uçta kimin oturduğunu kimse bilmez. Bu yazı o boşluğu kapatan tek mekanizmayı — DANE/TLSA'yı — üretim gerçekleriyle anlatıyor: neyi çözdüğünü, hangi tek kaydın herkese yettiğini ve kurulumu ayağına sıkanlarla düzgün çalıştıranları ayıran rollover disiplinini.
STARTTLS tek başına neden hiçbir şeyi doğrulamaz
Fırsatçı TLS'in üç ölümcül açığı var; üçü de "şifreli görünüyor" yanılsamasının altında saklı.
Downgrade (stripping). Gönderen MTA, alıcıya EHLO çeker ve yanıttaki yetenek listesinde 250-STARTTLS satırını arar. Araya giren aktif bir aktör bu tek satırı yanıttan siler. Gönderen "karşı taraf TLS bilmiyor" diye düşünür ve varsayılan politikayla mesajı düz metin olarak yollar. Ne uyarı vardır ne hata.
Sertifika doğrulama yokluğu. Postfix, varsayılan may
DANE/TLSA ile SMTP TLS: DNSSEC üzerinde zorunlu şifreleme | evilmail.pro — EvilMail Blog
ve hatta
encrypt
seviyelerinde sunucu sertifikasını doğrulamaz. Kendinden imzalı, süresi geçmiş,
CN
'i tamamen alakasız bir sertifika sorgusuz kabul edilir. Yani araya giren, kendi sertifikasını sunup oturumu sonlandırarak trafiği okuyabilir — TLS handshake pürüzsüz tamamlanır.
İmzasız MX araması. Teslimat, hedef alan adı için MX sorgusuyla başlar. DNSSEC yoksa bu yanıtın kimliği doğrulanamaz; saldırgan sahte bir MX enjekte ederek tüm trafiği kendi sunucusuna çeker. Ondan sonra hangi TLS'i konuştuğunuzun bir önemi kalmaz.
Sonuç net: fırsatçı TLS pasif dinlemeye karşı işe yarar, aktif saldırgana karşı tiyatrodur. Eksik olan iki şey kimlik doğrulama ve zorunluluk.
DANE ne çözüyor: DNS'in kendisini güven çıpası yapmak
DANE'in fikri tek cümlede özetlenir: bir hostname:port çiftini belirli bir sertifikaya ya da anahtara bağlayan bir DNS kaydı yayınlayın, sonra bu bağı DNSSEC ile kökten itibaren imzalayın. Güven artık bir CA rozetinden ya da ayrı bir HTTPS politika sunucusundan değil, zaten sizin kontrolünüzdeki bölgeden gelir. WebPKI'nın "yüzlerce CA'dan herhangi biri sizin adınıza sertifika kesebilir" problemi buharlaşır.
İlgili RFC'ler: RFC 6698 DANE/TLSA'yı tanımlar, RFC 7671 operasyonel rehberdir, RFC 7672 ise SMTP'ye özgü profildir. SMTP DANE'de kritik bir kısıt vardır: yalnızca usage 2 (DANE-TA) ve 3 (DANE-EE) geçerlidir. WebPKI'ya güvenen usage 0 ve 1 modları SMTP DANE'de yok sayılır — çünkü iki mail sunucusu arasında, kullanıcıya uyarı gösterip karar sorabilecek bir tarayıcı yoktur.
En önemli davranış farkı şu: bir alan için TLSA kaydı bulunduğunda TLS artık opsiyonel değildir. Gönderen MTA TLS'i zorunlu kılar; sertifika TLSA ile eşleşmezse oturumu düşürür ve mesajı defer eder. Düz metne dönmez. Downgrade saldırısı burada işe yaramaz, çünkü "TLS yok" sinyalinin kendisi artık imzalı DNS ile çelişir.
TLSA kaydının anatomisi
Bir TLSA kaydı şuna benzer:
dns
_25._tcp.mail.evilmail.pro. 3600 IN TLSA 3 1 1 <64-hane-hex-sha256>
Alan alan çözelim:
Port etiketi `_25._tcp` — SMTP inbound port 25'i işaret eder. Submission (587) ve smtps (465) DANE'lenmez; DANE, MTA-to-MTA teslimatı içindir, istemci-sunucu submission için değil. Yaygın bir hata _587 veya _465 yazmaktır.
Usage (ilk alan) — 3 = DANE-EE, sunucunun kendi uç (end-entity) sertifikası/anahtarı. 2 = DANE-TA, kendi zincirinizdeki bir güven çıpası. Neredeyse tüm kurulumlar için 3 doğrudur ve en basitidir.
Selector (ikinci alan) — 0 = tüm sertifika, 1 = SubjectPublicKeyInfo (SPKI), yani sadece açık anahtar. `1` seçin: sertifika yenilendiğinde anahtar aynı kalırsa TLSA hiç değişmez. Bu tek karar, birazdan anlatacağım rollover kâbusunun büyük kısmını en baştan siler.
ad bayrağı yoksa zincir kopuktur. DNSViz (dnsviz.net) veya Verisign DNSSEC Debugger ile kökten bölgenize kadar görsel doğrulama yapın. En sık ölümcül hata: DS kaydının registrar tarafında eksik ya da yanlış olması. Bu durumda ya zincir kopuk kalır (DANE hiç devreye girmez, korumasız olduğunuzu fark etmezsiniz) ya da doğrulayan resolver'lar SERVFAIL döner ve size gelen mail defer olur.
Bir kısıt daha: RFC 7672 strict moda göre MX ana adı CNAME'e işaret etmemelidir; doğrudan A/AAAA kayıtlarına çözülmelidir.
TLSA kaydını üretmek
Let's Encrypt sertifikasından SPKI SHA-256 hash'ini çıkaran tek zincir:
Üçüncü yöntem, canlı sunucudan posttls-finger ile üretimdir. Hangisini seçerseniz seçin, sonucu bölge dosyanıza yazın, imzalayıp yayınlayın:
dns
_25._tcp.mail.evilmail.pro. 3600 IN TLSA 3 1 1 abc123... ; 64 hane
Postfix'i DANE için ayarlamak
Alıcı tarafı işin kolay kısmı. Sertifikanız geçerli ve TLSA ile eşleşiyorsa, gelen mail için ekstra Postfix ayarı gerekmez — sadece kaydı yayınlarsınız, DANE uygulayan göndericiler gerisini halleder.
Gönderen tarafı asıl iş. DANE doğrulaması için Postfix'in, AD bayrağına güvenebileceği doğrulayan (validating) bir resolver'a ihtiyacı vardır. Pratikte bu Unbound'dur; 127.0.0.1 üzerinde çalışır ve /etc/resolv.conf yalnızca onu gösterir:
ini
# /etc/resolv.conf
nameserver 127.0.0.1
Ardından main.cf:
ini
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_host_lookup = dns
dane ile dane-only arasındaki fark üretimde çok önemlidir:
`dane` — hedefte TLSA varsa TLS zorunlu ve doğrulanır; yoksa fırsatçı TLS'e düşer. İnternete açık genel teslimat için doğru seçim.
`dane-only` — TLSA/DNSSEC yoksa mesajı defer eder. Belirli bir partnerle güvenli kanal garantisi istediğiniz transport eşlemelerinde anlamlıdır; global varsayılan olarak kullanmak, DNSSEC'siz milyonlarca alana giden mail'i kuyrukta bekletir.
Yenilemeden sağ çıkmak: rollover disiplini
Üretimde DANE kaynaklı kesintinin bir numaralı nedeni tektir: sertifika yenilenir, TLSA hash artık eşleşmez, DANE uygulayan her gönderici mesajı geri çevirmeye başlar. Let's Encrypt sertifikaları ~90 gün ömürlüdür ve certbot bunları ~60. günde yeniler. Selector 0 (full cert) kullanıyorsanız her yenilemede TLSA kırılır. İki doğru strateji var.
Strateji A — anahtarı sabitle (önerilen). SPKI selector (1) kullanın ve certbot'a anahtarı yeniden kullanmasını söyleyin:
bash
certbot renew --reuse-key
Anahtar sabit kaldığından 3 1 1 TLSA hash'i sertifika kaç kez yenilenirse yenilensin hiç değişmez. Tek kayıt, sıfır rollover bakımı. Dikkat: --reuse-key artık certbot'un varsayılanı değildir, bilinçli olarak açmanız gerekir.
Strateji B — anahtar değişecekse "önce yayınla" penceresi. Anahtarı döndürmek zorundaysanız (ör. sızma şüphesi), sıralama kutsaldır: yeni TLSA'yı ekleyin (eski + yeni birlikte yayında), en az max(TTL, negatif-cache) süre bekleyin, sonra sertifikayı yeni anahtara geçirin, en son eski TLSA'yı silin. TTL'i düşük tutun (300–3600 s) ki pencere kısalsın. Bu sırayı bozup önce sertifikayı geçirirseniz, DNS önbelleklerinde hâlâ eski hash duran her göndericiden anında geri dönüş alırsınız.
DANE mı, MTA-STS mi?
Rakip değiller, katman farkındalar. DANE DNSSEC ister, TOFU (ilk temasta güven) yoktur, gerçek kriptografik güven sunar — ama DNSSEC'siz bir bölgede kurulamaz. MTA-STS (RFC 8461) DNSSEC istemez; bunun yerine WebPKI + bir HTTPS politika sunucusu + TOFU'ya dayanır, dolayısıyla ilk temasta ve politika önbelleği boşken zayıftır. Google ve Microsoft ekosistemi tarihsel olarak MTA-STS'i öne çıkardı; Google Workspace 2024'ten beri giden mailde DANE'i de destekliyor.
Doğru üretim duruşu ikili değil, birleşik: bölgeniz DNSSEC ise DANE ile MTA-STS'i birlikte yayınlayın ve her ikisi için de TLSRPT (RFC 8460) ile başarısızlık raporu toplayın. Böylece DNSSEC doğrulayan göndericiler DANE'i, doğrulamayanlar MTA-STS'i kullanır — ve neyin kırıldığını raporlardan görürsünüz:
dns
_smtp._tls.evilmail.pro. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Doğrulama ve izleme
Yayına almadan önce ve düzenli olarak canlı doğrulama yapın:
bash
# Canlı DANE doğrulaması — "Verified TLS connection ... Matched" görmelisiniz
posttls-finger -c -l dane-only mail.evilmail.pro
# TLSA kaydı ve DNSSEC yanıtı
dig +dnssec +short TLSA _25._tcp.mail.evilmail.pro
dig +dnssec mail.evilmail.pro # flags'te 'ad' bayrağı
Dış doğrulayıcılar için dane.sys4.de/smtp, internet.nl ve hardenize.com sonucu net gösterir. Sürekli izlemede aradığınız iki sinyal var: DANE eşleşme oranı ve TLSRPT raporlarındaki certificate-not-matched ile validation-failure sayaçları. Bu sayaçlardaki ani bir sıçrama, neredeyse her zaman kaçırılmış bir rollover demektir.
Devreye alma kontrol listesi
Bölge DNSSEC ile imzalı ve DS kaydı registrar'da doğrulanmış (dig +dnssec → ad bayrağı).
MX ana adı A/AAAA'ya çözülüyor, CNAME değil.
_25._tcp.mail... altında 3 1 1 TLSA yayında ve canlı sertifikayla eşleşiyor (posttls-finger → Matched).
