DANE Ve MTA-STS her ikisi de destekleyici gönderme sistemlerinin kimlik doğrulamalı SMTP aktarımını zorunlu kılmasına izin verir. Güven bağımlılıkları farklıdır ve bu farklılıklar ilk mesajdan önce, DNS sorunu sırasında ve sertifikalar değiştiğinde önemlidir. Aralarında seçim yapmak, yalnızca başarılı bir TLS anlaşması değil, alıcı operatörün ve sağlayıcılarının neler sağlayabileceğinin bir envanterini gerektirir.
Bir alıcı rotayı takip edin
Referanslar: RFC 7672 §2, RFC 8461 §3, RFC 8461 §4.
TCP bağlantı noktası 25'te MX mx1.example.net ile example.com kullanın. SMTP DANE altında, gönderenin DNSSEC tarafından doğrulanmış uygun yönlendirmeye ve TLSA keşif süreci. Bu basit, takma adı olmayan ana bilgisayar için TLSA'nın sahibi _25._tcp.mx1.example.net . Kullanılabilir bir güvenli TLSA ilişkisi, destekleyici gönderene TLS hizmetinin kimliğinin nasıl doğrulanacağını söyler. A TXT kaydı alıcı etki alanında bunun yerine geçmez. RFC 7672 bölüm 2 ve 3.
MTA-STS altında, alıcı etki alanı keşfi _mta-sts.example.com adresinde yayınlar ve politikasını mta-sts.example.com adresinde kimliği doğrulanmış HTTPS üzerinden sunar. Politika, amaçlanan MX adlarına ve sarf malzemeleri moduna ve kullanım ömrüne yetki verir. STS kimlik doğrulaması için SMTP sunucusunun, RFC 8461 §4.2 kapsamında eşleşen bir SAN DNS-ID'si de dahil olmak üzere geçerli ortak anahtar altyapısı sertifika kontrollerini karşılaması gerekir. Genel TLS ana bilgisayar adı araştırmaları tek başına tam profili oluşturmaz. İlke ana bilgisayar sertifikası ve posta sunucusu sertifikası farklı hizmetleri korur. RFC 8461 bölüm 3 ve 4.
İlk temas ve arıza durumlarını karşılaştırın
Referanslar: RFC 7672 §2.1, RFC 8461 §2, RFC 8461 §3.3, RFC 8461 §10.2.
DANE politika keşfini aracılığıyla doğrulayabilir DNSSEC doğrulama zinciri güvenli olduğunda ve kullanılabilir kayıtlar mevcut olduğunda ilk temasta. Bu, özyinelemeli bir çözümleyici tarafından döndürülen herhangi bir cevaba güvenmekle aynı şey değildir. Sahte bir doğrulama sonucu, geçerli, güvenli olmayan bir yetkilendirmeye eşdeğer değildir. Çözümleyici güven ilişkisini ve ilgili her yanıtın doğrulama durumunu kaydedin.
MTA-STS bir önyükleme sınırlaması vardır: Kullanılabilir bir önbelleğe alınmış politikaya sahip olmayan bir göndericinin bu politikayı alması engellenebilir. Süresi dolmamış bir icra poliçesi bulunan gönderici, yeni bir poliçe elde edilemediğinde bu poliçeyi uygulamaya devam etmelidir. Bu nedenle boş önbellek ve sıcak önbellek durumlarını ayrı ayrı karşılaştırın. Bir izleme ana bilgisayarında başarılı HTTPS, her gönderenin politikayı öğrendiğini kanıtlamaz.
Açıkça varsayımsal olan dört durumu düşünün. İlk temasta güvenli, kullanılabilir DANE keşfi sayesinde, destekleyen gönderen, MTA-STS edinimi bastırılmış olsa bile hizmetin kimliğini doğrulayabilir. Süresi dolmamış, zorunlu bir MTA-STS ilkesinin önbelleğe alınmasıyla, başarısız alma işlemi bu ilkeyi silmez. A'dan B'ye yapılacak bir anahtar değişikliği, yeni sertifika PKIX gerekliliklerini karşılasa bile, yalnızca eski TLSA ilişkisini başarısızlığa uğratabilir; örtüşme her iki anahtarı da kapsayabilir. Geçerli bir önbelleğe alınmış STS politikası tarafından hariç tutulan bir MX geçmek, uyumlu bir politika öğrenilene kadar MX kontrolünde başarısız olabilir. Bunlar standartlara dayalı örneklerdir; gözlemlenmeyen DNSSEC , önbellek veya dağıtım testleridir.
Kural olarak mekanizmalar evrensel olarak birleştirilmemiştir ve her ikisinin de geçmesi gerekmektedir. RFC 8461 §2, belirli bir müdahale etmeme gereksinimi belirler: Başarılı MTA-STS doğrulaması, başarısız DANE doğrulamasını geçersiz kılmamalıdır ZORUNLU. Her ikisinin de geçmesi gerektiği konusunda ısrar eden genel bir karşılaştırma modeli, normatif bir gönderen algoritması değildir.
Aynı devri iki kez planlayın
Referanslar: RFC 7672 §4, RFC 8461 §8.
DANE-EE kullanımı 3, güvenli ilişkilendirme yoluyla kimlik doğrulaması yapar: RFC 7672 §3.1.1, STS tarafından kullanılan PKIX kimliğini veya sertifika geçerlilik sonu kontrollerini gerektirmez. Bu istisnayı her TLSA kullanımına ayrım gözetmeksizin uygulamayın. DANE-EE için seçici SPKI ve SHA-256, ortak anahtarı değiştirmek ilişkilendirme özetini değiştirir. Yeni anahtarı dağıtmadan önce eski ve yeni ilişkileri yayınlayın, eski DNS önbelleklerinin ve ilgili imza kayıtlarının eskimesine izin verin ve her etkin uç nokta için kapsama alanı sağlayın. Sertifikanın aynı anahtarla yeniden verilmesi, anahtarın döndürülmesinden farklıdır. RFC 7672 bölüm 4.
MTA-STS için geçerli MX kimliğini ve güvenini koruyan sıradan bir sertifika yenilemesi, politika MX modellerinin değiştirilmesini gerektirmez. MX geçişi şunları sağlar: hem eski hem de yeni alıcı ana bilgisayarları kapsayan bir politika düzenler ve önceki politikaları koruyan gönderenleri hesaba katar. Her iki model de, başka bir denetleyicinin yeşil rapor vermesi nedeniyle bozuk bir rotanın göz ardı edilmesine izin vermez.
Operasyonel sahipliğe göre karar verin
Referanslar: RFC 8461 §2.
Alıcı DNS , MX-ana bilgisayar DNS , DNSSEC imzalamayı, SMTP sertifika dağıtımını ve HTTPS ilkesi barındırmayı kontrol eden ekipleri listeleyin. Barındırılan sağlayıcı, alan sahibinin doğrudan değiştiremeyeceği bir bağımlılığı kontrol edebilir. Müşterilere her iki kontrolü de vaat etmeden önce desteklenen bir süreç oluşturun. Her iki mekanizmanın da konuşlandırıldığı durumlarda, başarılı MTA-STS doğrulaması, başarısız DANE doğrulamasını geçersiz kılmamalıdır. Bu kılavuz için canlı DNSSEC zinciri veya SMTP dağıtımı uygulanmadı; karşılaştırma standartlara dayalıdır ve yerel örnekleri açıkça sentetiktir.