Bir SMTP sunucusunun SSL sertifikası hangi ana bilgisayar adını içermelidir?

192.0.2.1'de foo.example.com sunucum var

Bazı etki alanlarım için e-posta almak için exim çalışır.

Alanlarımın her birinde, 192.0.2.1’e çözümlenen mx.example.com’a işaret eden bir MX kaydı bulunur.

Gelen e-posta bağlantıları için exim teklif TLS şifrelemesi yapmak istersem, SSL sertifikasına hangi ana bilgisayar adını girmeliyim?

• foo.example.com, sunucunun HELO'da söyleyeceği şey bu mu?
• mx.example.com çünkü müşterilerin bağlanacağı ana bilgisayar adı bu mu?

http://www.checktls.com , ikincisinin doğru olduğunu öne sürüyor, ancak kesin bir cevap bulamıyorum.

Bu aslında hiçbir yerde açıkça tanımlanmamıştır ve sunucunun "güvenilir" olması gerekip gerekmediği, ona bağlı olan müşteriye (elbette başka bir posta sunucusu olabilir) bağlıdır; ilgili RFC’den ( RFC 2487 ) alıntı :

SMTP istemcisi kimlik doğrulama veya
mahremiyet seviyesinin devam etmesi için yeterince yüksek olmadığına karar verirse
, TLS görüşmesi tamamlandıktan hemen sonra bir SMTP ÇIKIŞ komutu vermelidir.
SMTP sunucusu kimlik doğrulama veya
gizlilik seviyesinin devam etmesi için yeterince yüksek olmadığına karar verirse
, istemciden gelen her SMTP komutuna (QUIT komutu dışında)
554 yanıt koduyla (olası bir metin dizesiyle ) cevap vermelidir. "Komut
, güvenlik yetersizliği nedeniyle reddedildi" olarak.

Bir TLS müzakeresinde karşı tarafın gerçekliğine inanıp inanmama kararı yerel bir meseledir. Ancak,
kararlar için bazı genel kurallar şunlardır:

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

Bunun temel olarak anlamı, sunucu verilen bir sertifikayı kullanarak TLS şifrelemesi sunduğunda , sertifikanın isminin muhtemelen onunla aynı olmasını isteyeceği , ancak muhtemelen sertifikanın adının aynı olmasını isteyeceği diğer kısma bağlıdır. Uyuşmasa bile kabul et.

Fakat bekleyin, dahası var. Aynı RFC'den tekrar alıntı yapmak:

TLS anlaşmasının tamamlanmasından sonra, SMTP protokolü
başlangıç ​​durumuna sıfırlanır (bir sunucunun 220
servisine hazır selamlama vermesinden sonra SMTP'deki durum ). Sunucu
, istemciden
elde edilen bilgileri, TLS anlaşmasından elde edilemeyen EHLO komutunun argümanı gibi, atmalıdır . Müşteri , TLS anlaşmasından elde edilemeyen SMTP servis uzantıları
listesi gibi sunucudan
elde edilen bilgileri atmamalıdır
. Müşteri
, başarılı bir TLS görüşmesinden sonra ilk komut olarak bir EHLO komutu göndermelidir .

Öyleyse, sunucunun TLS anlaşmasından önce HELO / EHLO’ya cevaben söylediği aslında hiç önemli değil.

Tecrübelerime göre, kendinden imzalı sertifikalar Internet'e bakan posta sunucularında oldukça iyi çalışıyor; bu, diğer posta sunucularının onları doğrulamak için bile zahmete girmediği anlamına geliyor , yayınlamadan bağımsız olarak TLS şifrelemesi sağlayabilecek her şeyi mutlu bir şekilde kabul edecekler. yetki veya konu adı.

Etki alanınıza posta gönderen bir MTA, MX kaydını (bir ana bilgisayar adı verir) arayacak ve daha sonra bu ana bilgisayar adı için bir A kaydı arayacaktır. Bağlandığı ana bilgisayar adı bu nedenle MX ana bilgisayar adıdır ve bu nedenle SSL sertifikası ortak adına karşı doğrulanacaktır. HELO ana bilgisayar adının doğrulanması, sunucu istediği herhangi bir HELO ana bilgisayar adını sağlayabildiği için bir anlam ifade etmemektedir - ek güvenlik sağlamaz.

Bununla birlikte, posta tesliminde kesin olarak SSL sertifikalarının doğrulanması şu anda özellikle yararlı değildir, çünkü MTA'lar (hemen hemen her zaman) SSL olmayan dağıtımlara geri döner, çünkü SMTP şu anda böyle çalışır. Bu nedenle, mantıklı yapılandırma, SSL sertifikasının doğrulanıp onaylanmadığına bakılmaksızın MX sunucusu sunarsa SSL kullanmaktır (kimlik doğrulaması olmadan şifreleme, şifrelemeden ve doğrulamadan daha iyidir). Bu nedenle, bu amaç için kendinden imzalı bir sertifika kullanabilirsiniz.

Sunucu sertifikasını doğrulama ve sunucunun ana bilgisayar adıyla eşleşme görevi, SSL / TLS kullanan herhangi bir protokol için tamamen müşterinin rolüdür.

Bu nedenle, sertifikadaki ana bilgisayar adı, istemcinin erişmeye çalıştığı adla eşleşmelidir.

SSL / TLS bağlantısı önden başlatıldığında (SMTPS), sunucu, bağlantı kurulmadan önce HELO mesajının ne dediğini görmenin bir yolunu bulamamaktadır, bu nedenle isteği yaptığı bağlantıyı kullanması gerekir.

SSL / TLS'yi kullandıktan sonra STARTTLS, müşteri hala yapılandırıldığı sunucuyla konuşmayı düşünüyor, bu yüzden kontrol etmesi gereken de bu. Bunun başarısız olması, MITM saldırılarını mümkün kılar:

• C-> S: Merhaba, ben Alice, Bob ile konuşmak istiyorum.
• S-> C: Merhaba, ben Chuck, işte Chuck için benim sertifika.
• C-> S: Oh evet, sertifikan gerçekten Chuck için geçerli. Hadi devam edelim.
• ... Tabii ki orada bir kusur var, çünkü Alice Bob ile güvenli bir iletişim kurmak istedi.

Her iki durumda da kullanılması gereken MX adresi.

Ana bilgisayar adı eşleştirme kuralları yakın zamanda RFC 6125'teki protokoller arasında toplanmıştır , ancak çok az sayıda müşteri bunu tam olarak uygular (bu, tam bir değişiklikten ziyade en iyi uygulama RFC'sidir ve hala oldukça yenidir).

Gelen , uzantısı , bu (alınan önce SMTP hakkında varolan özetliyor RFC 3207 ve RFC 4954 ). Özellikle " İstemci, güvensiz bir uzak kaynaktan (örneğin güvensiz DNS araması) türetilmiş sunucu ana bilgisayar adını KULLANMAMALIDIR. " (Elbette sunucunun afişine uygulanır). Bunun dışında, SMTP eski kuralları Konu Alternatif İsimler (ilgili biraz daha HTTPS daha rahat olduğunu gerektiği yerine gerekir kullanılabilir).

Modern yöntem kesinlikle ana bilgisayar adını bir Konu Alternatif Adı DNS girişine koymaktır. Joker karakter kullanımı da önerilmez .

En iyisinin pratikte yapılanları kopyalamak olacağını düşünüyorum. Http://checktls.com adresini kullanarak bir yahoo.com e-posta adresini kontrol ettim. Yahoo'da ana bilgisayar adları ve mx etki alanları için farklı bir etki alanı kullandılar. Yani, hostname yahoo.com ve mx domainleri yahoodns.net ile bitiyor

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

Kontrollerin sonucu: SSL sertifikası CN = MX domain (* .yahoodns.net)

Cisco ile aynısını yaptım ve aynı sonucu aldım.

SSL / TLS şifrelemesinde, müşteri daima uzak makinedeki "real" / "beyan edilmiş" ana bilgisayar adı ile sertifikaya dahil edilen bilgiler arasındaki uyumu kontrol eder.

Bu nedenle, muhtemelen foo.example.com adresini ayarlamanız veya bir joker sertifikası oluşturmalısınız ;-)