Jaką nazwę hosta powinien zawierać certyfikat SSL dla serwera SMTP?

Mam serwer foo.example.com pod adresem 192.0.2.1

Uruchamia exim, aby otrzymywać e-maile z kilku moich domen.

Każda moja domena ma rekord MX wskazujący na mx.example.com, który jest rozwiązywany do 192.0.2.1

Jeśli chcę zaoferować eximowi szyfrowanie TLS dla przychodzących połączeń e-mail, jaką nazwę hosta powinienem umieścić w certyfikacie SSL?

• foo.example.com, ponieważ tak powie serwer w HELO?
• mx.example.com, ponieważ jest to nazwa hosta, z którą klienci będą się łączyć?

http://www.checktls.com sugeruje, że to drugie jest poprawne, ale nie mogę znaleźć ostatecznej odpowiedzi.

W rzeczywistości nigdzie nie jest to wyraźnie określone, a to, czy serwer powinien być „zaufany”, zależy od klienta (który może oczywiście być innym serwerem poczty) łączącego się z nim; cytowanie z odpowiedniego RFC ( RFC 2487 ):

Jeśli klient SMTP zdecyduje, że poziom uwierzytelnienia lub
prywatności nie jest wystarczająco wysoki, aby mógł być kontynuowany, POWINIEN wydać
polecenie SMTP QUIT natychmiast po zakończeniu negocjacji TLS.
Jeśli serwer SMTP zdecyduje, że poziom uwierzytelnienia lub
prywatności nie jest wystarczająco wysoki, aby mógł kontynuować, POWINIEN odpowiadać na
każdą komendę SMTP od klienta (inną niż komenda QUIT) za
pomocą kodu odpowiedzi 554 (z możliwym ciągiem tekstowym takim jak jako „Polecenie
odmówiono z powodu braku bezpieczeństwa”).

Decyzja, czy wierzyć autentyczności
drugiej strony w negocjacje TLS, jest sprawą lokalną. Jednak niektóre
ogólne zasady dotyczące decyzji to:

- 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.

Zasadniczo oznacza to, że gdy serwer oferuje szyfrowanie TLS przy użyciu danego certyfikatu, decyzja o jego przyjęciu lub odrzuceniu zależy całkowicie od drugiej strony, która prawdopodobnie będzie chciała, aby nazwa na certyfikacie była taka sama, z którą się połączył, ale mogłaby bardzo dobrze to zaakceptuj, nawet jeśli nie pasuje.

Ale czekaj, jest więcej. Cytując ponownie z tego samego dokumentu RFC:

Po zakończeniu uzgadniania TLS protokół SMTP jest resetowany do
stanu początkowego (stan w SMTP po tym, jak serwer wydaje
powitanie gotowe do usługi 220 ). Serwer MUSI odrzucić wszelką wiedzę
uzyskaną od klienta, taką jak argument polecenia EHLO,
który nie został uzyskany z samej negocjacji TLS. Klient
MUSI odrzucić wszelką wiedzę uzyskaną z serwera, taką jak lista
rozszerzeń usługi SMTP, która nie została uzyskana z
samej negocjacji TLS . Klient POWINIEN wysłać polecenie EHLO jako
pierwsze polecenie po udanej negocjacji TLS.

Tak więc to, co serwer mówi w odpowiedzi na HELO / EHLO przed uzgadnianiem TLS, nie wydaje się w ogóle mieć znaczenia.

Z mojego doświadczenia wynika, że ​​samopodpisane certyfikaty działają całkiem dobrze na internetowych serwerach pocztowych, co oznacza, że inne serwery pocztowe nawet nie zadają sobie trudu, aby je zweryfikować, po prostu z przyjemnością przyjmą wszystko, co może zapewnić szyfrowanie TLS, niezależnie od wystawiającego nazwa organu lub podmiotu.

MTA dostarczający pocztę do twojej domeny będzie szukał rekordu MX (który da nazwę hosta), a następnie wyszuka rekord A dla tej nazwy hosta. Dlatego nazwa hosta, z którym się łączy, to nazwa hosta MX, a więc to, co zostanie zweryfikowane na podstawie zwykłej nazwy certyfikatu SSL. Weryfikacja nazwy hosta HELO nie ma sensu, ponieważ serwer może podać dowolną nazwę hosta HELO - nie zapewnia dodatkowych zabezpieczeń.

To powiedziawszy, ścisłe weryfikowanie certyfikatów SSL podczas dostarczania poczty nie jest obecnie szczególnie przydatne, ponieważ MTA (prawie zawsze) powrócą do dostarczania bez SSL, ponieważ tak właśnie działa SMTP. Rozsądną konfiguracją jest zatem użycie protokołu SSL, jeśli serwer MX go oferuje, niezależnie od tego, czy certyfikat SSL weryfikuje, czy nie (ponieważ szyfrowanie bez uwierzytelnienia jest lepsze niż brak szyfrowania i brak uwierzytelnienia). Dlatego w tym celu równie dobrze możesz użyć certyfikatu z podpisem własnym.

Weryfikacja certyfikatu serwera i sprawdzenie, czy jest on zgodny z nazwą hosta serwera, jest wyłącznie rolą klienta w przypadku dowolnego protokołu używającego protokołu SSL / TLS.

W związku z tym nazwa hosta w certyfikacie powinna odpowiadać nazwie, do której klient próbuje uzyskać dostęp.

Gdy połączenie SSL / TLS jest inicjowane z góry (SMTPS), serwer nie ma możliwości zobaczenia komunikatu HELO przed nawiązaniem połączenia, więc musi użyć tego, z którym wysłał żądanie.

Korzystając z protokołu SSL / TLS po STARTTLS, klient nadal zamierza rozmawiać z serwerem, na którym został skonfigurowany, więc nadal powinien to sprawdzić. W przeciwnym razie ataki MITM byłyby możliwe:

• C-> S: Cześć, jestem Alice, chcę porozmawiać z Bobem.
• S-> C: Cześć, jestem Chuck, oto mój certyfikat dla Chucka.
• C-> S: O tak, twój certyfikat jest rzeczywiście ważny dla Chucka. Kontynuujmy.
• ... Oczywiście jest w tym wada, ponieważ Alice chciała bezpiecznej komunikacji z Bobem.

W obu przypadkach należy użyć adresu MX.

Reguły dopasowywania nazw hostów zostały ostatnio zebrane w różnych protokołach w RFC 6125 , ale niewielu klientów w pełni je implementuje (jest to raczej najlepsza praktyka RFC niż kompletna zmiana i wciąż jest całkiem nowa).

W swoim dodatku podsumowuje to, co istniało wcześniej o SMTP (wzięte z RFC 3207 i RFC 4954 ). W szczególności „ Klient NIE MOŻE używać żadnej formy nazwy hosta serwera pochodzącej z niezabezpieczonego zdalnego źródła (np. Niepewne wyszukiwanie DNS). ” (Co oczywiście dotyczy banera serwera). Niezależnie od tego, zasady legacy SMTP były nieco bardziej zrelaksowany niż HTTPS dotyczące Subject Alternative Names ( powinien zamiast musi być używany).

Współczesnym sposobem jest zdecydowanie umieszczenie nazwy hosta we wpisie DNS Alternatywna nazwa podmiotu. Odradza się również używanie symboli wieloznacznych .

Myślę, że najlepiej byłoby skopiować to, co zostało zrobione w praktyce. Sprawdziłem adres e-mail yahoo.com za pomocą http://checktls.com Mam nadzieję, że w yahoo użyli innej domeny dla swojej nazwy hosta i dla swojej domeny mx. Ich nazwa hosta to yahoo.com, a ich domena mx kończy się na yahoodns.net

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

Wynik sprawdzianów: certyfikat SSL CN = domena MX (* .yahoodns.net)

Zrobiłem to samo z Cisco i miałem taki sam wynik.

W przypadku szyfrowania SSL / TLS klient zawsze sprawdza zgodność między „rzeczywistą” / „zadeklarowaną” nazwą hosta na zdalnym komputerze a informacjami zawartymi w certyfikacie.

Prawdopodobnie powinieneś ustawić foo.example.com lub wygenerować certyfikat z symbolami wieloznacznymi ;-)