Frage Welchen Hostnamen sollte das SSL-Zertifikat für einen SMTP-Server enthalten?


Ich habe einen Server foo.example.com bei 192.0.2.1

Es läuft exim, um E-Mails für mehrere meiner Domains zu erhalten.

Meine Domains haben jeweils einen MX-Eintrag, der auf "mx.example.com" verweist, was zu 192.0.2.1 führt

Wenn ich exim TLS-Verschlüsselung für eingehende E-Mail-Verbindungen anbieten möchte, welchen Hostnamen sollte ich in das SSL-Zertifikat eingeben?

  • foo.example.com, denn das wird der Server im HELO sagen?
  • mx.example.com, weil das der Hostname ist, mit dem die Clients verbunden sind?

http://www.checktls.com schlägt vor, dass Letzteres korrekt ist, aber ich kann keine definitive Antwort finden.


18
2018-05-15 21:23


Ursprung


In HTTP + SSL benötigen Sie ein Platzhalterzertifikat (* .example.com), um mehrere namensbasierte virtuelle Server zu bedienen. Ich bin mir nicht sicher über SMTP + SSL, aber ich vermute, dass Sie eine ähnliche Einschränkung finden werden. Der Umweg über HTTP besteht darin, jeden virtuellen Server an eine andere IP zu binden und für jedes ein eindeutiges Zertifikat zu verwenden. - Chris Nava
Für einen MX-Server spielt es praktisch keine Rolle, wofür Sie Ihren allgemeinen Namen festlegen. - cnst


Antworten:


Dies ist eigentlich nirgendwo explizit definiert, und ob der Server "vertrauenswürdig" sein soll oder nicht, hängt davon ab, dass der Client (der natürlich ein anderer Mail-Server sein könnte) mit ihm verbunden ist; zitieren aus dem relevanten RFC (RFC 2487):

Wenn der SMTP-Client entscheidet, dass die Stufe der Authentifizierung oder
  Privatsphäre ist nicht hoch genug, um es fortzusetzen, es sollte ein
  SMTP QUIT-Befehl unmittelbar nach Abschluss der TLS-Verhandlung.
  Wenn der SMTP-Server entscheidet, dass die Stufe der Authentifizierung oder
  Privatsphäre ist nicht hoch genug, um es fortzusetzen, es sollte antworten
  Jeder SMTP-Befehl vom Client (außer einem QUIT-Befehl) mit
  der 554-Antwortcode (mit einer möglichen Textzeichenfolge wie "Command
  wegen mangelnder Sicherheit abgelehnt ").

Die Entscheidung, ob man der Authentizität der
  Eine andere Partei in einer TLS-Verhandlung ist eine lokale Angelegenheit. Jedoch einige
  allgemeine Regeln für die Entscheidungen sind:

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

Das bedeutet im Wesentlichen, wenn der Server die TLS-Verschlüsselung unter Verwendung eines bestimmten Zertifikats anbietet, hängt die Entscheidung über das Akzeptieren oder Verweigern des Zertifikats vollständig von dem anderen Teil ab wahrscheinlich Ich möchte, dass der Name auf dem Zertifikat derselbe ist, mit dem er verbunden ist, aber ich könnte ihn auch akzeptieren, wenn er nicht übereinstimmt.

Aber warte, da ist mehr. Wieder aus dem gleichen RFC zitieren:

Nach Beendigung des TLS-Handshakes wird das SMTP-Protokoll auf zurückgesetzt
  Der Anfangszustand (der Status in SMTP, nachdem ein Server eine 220 ausgibt
  Service bereit Gruß). Der Server muss jegliches Wissen verwerfen
  vom Kunden erhalten, wie das Argument des EHLO-Befehls,
  was nicht aus den TLS-Verhandlungen selbst stammt. Der Kunde
  MUSS jegliches vom Server erhaltene Wissen wie die Liste verwerfen
  von SMTP-Serviceerweiterungen, die nicht vom TLS erhalten wurden
  Verhandlung selbst. Der Client SOLLTE einen EHLO Befehl als senden
  erster Befehl nach einer erfolgreichen TLS-Verhandlung.

Also, was der Server als Antwort auf HELO / EHLO sagt Vor Der TLS-Handshake scheint überhaupt keine Rolle zu spielen.

Meiner Erfahrung nach funktionieren selbstsignierte Zertifikate ziemlich gut auf Internet-Mail-Servern, was bedeutet, dass andere Mail-Server kümmern sich nicht mal darum, sie zu validieren, sie akzeptieren einfach alles, was TLS-Verschlüsselung bereitstellen kann, unabhängig von der ausstellenden Behörde oder dem Namen des Subjekts.


15
2018-05-15 22:00





Ein MTA, der E-Mails an Ihre Domain sendet, sucht den MX-Eintrag (der einen Hostnamen ergibt) und sucht dann einen A-Eintrag für diesen Hostnamen. Der Hostname, zu dem die Verbindung hergestellt wird, ist daher der MX-Hostname. Dies wird anhand des allgemeinen Namens des SSL-Zertifikats überprüft. Die Überprüfung des HELO-Hostnamens ist nicht sinnvoll, da der Server einen beliebigen HELO-Hostnamen bereitstellen kann - er bietet keine zusätzliche Sicherheit.

Nichtsdestoweniger ist die strikte Überprüfung von SSL-Zertifikaten bei der Zustellung von E-Mails derzeit nicht besonders nützlich, da MTAs (fast immer) auf Nicht-SSL-Zustellung zurückgreifen, da SMTP im Moment funktioniert. Die sinnvolle Konfiguration besteht daher darin, SSL zu verwenden, wenn der MX-Server es anbietet, unabhängig davon, ob das SSL-Zertifikat dies bestätigt oder nicht (da Verschlüsselung ohne Authentifizierung besser ist als keine Verschlüsselung und keine Authentifizierung). Sie können daher auch ein selbstsigniertes Zertifikat für diesen Zweck verwenden.


8
2018-05-15 21:59



Ja, und aus diesem Grund spielt es überhaupt keine Rolle, auf welchen allgemeinen Namen es sich bezieht, oder ob es überhaupt gesetzt ist. - cnst


Die Aufgabe, das Serverzertifikat zu überprüfen und dem Hostnamen des Servers zu entsprechen, ist die Rolle des Clients für jedes Protokoll, das SSL / TLS verwendet.

Daher sollte der Hostname im Zertifikat mit dem Namen übereinstimmen, auf den der Client zugreifen möchte.

Wenn die SSL / TLS-Verbindung von vorneherein (SMTPS) initiiert wird, hat der Server keine Möglichkeit zu sehen, was die HELO-Nachricht sagt, bevor die Verbindung hergestellt wird, also muss sie die verwenden, mit der sie die Anfrage gestellt hat.

Bei Verwendung von SSL / TLS nach STARTTLSDer Client möchte weiterhin mit dem Server kommunizieren, mit dem er konfiguriert wurde. Das sollte also noch überprüft werden. Andernfalls könnten MITM-Angriffe möglich werden:

  • C-> S: Hallo, ich bin Alice, ich möchte mit Bob reden.
  • S-> C: Hi, ich bin Chuck, hier ist mein Zertifikat für Chuck.
  • C-> S: Oh ja, dein Zertifikat ist in der Tat gültig für Chuck. Lass uns fortfahren.
  • ... Da ist natürlich ein Fehler, denn Alice wollte ein sicheres Kommunikation mit Bob.

In beiden Fällen ist es die MX-Adresse, die verwendet werden sollte.

Die Übereinstimmungsregeln für den Hostnamen wurden kürzlich über die Protokolle in RFC 6125, aber nur wenige Clients implementieren es vollständig (es ist mehr eine Best Practice RFC als eine vollständige Änderung, und es ist immer noch ziemlich neu).

Im sein Anhang, fasst es zusammen, was vorher über SMTP existierte (aus RFC 3207 und RFC 4954). Im Speziellen "Der Client darf KEINE Form des Server-Hostnamens verwenden, der von einer unsicheren Remote-Quelle stammt (z. B. unsichere DNS-Suche)."(was natürlich für das Banner des Servers gilt). Abgesehen davon waren die SMTP-Legacy-Regeln etwas entspannter als HTTPS in Bezug auf alternative Subjektnamen (sollte anstatt Muss verwendet werden).

Der moderne Weg ist definitiv, den Host-Namen in einen Subject Alternative Name DNS-Eintrag zu setzen. Wildcard-Nutzung wird ebenfalls abgeraten.


5
2018-05-16 01:27



Es wäre nett, wenn das Zertifikat für die Mail-Domäne wäre - dann wäre DNSSEC im Wesentlichen nicht erforderlich, um MITMs zu vermeiden. - Andreas Krey


Ich denke, das Beste wäre, zu kopieren, was in der Praxis getan wird. Ich habe eine yahoo.com E-Mail-Adresse mit verwendet http://checktls.com Hoffentlich haben sie bei Yahoo eine andere Domain für ihren Hostnamen und für ihre MX-Domain verwendet. Ihr Hostname ist also yahoo.com und ihre mx-Domain endet mit yahoodns.net

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

Ergebnis der Checklisten: das SSL-Zertifikat CN = MX-Domäne (* .yahoodns.net)

Ich machte das gleiche mit Cisco und ich hatte das gleiche Ergebnis.


0
2017-07-29 16:00





Bei der SSL / TLS-Verschlüsselung prüft der Client immer die Übereinstimmung zwischen "echtem" / "deklariertem" Hostnamen auf dem entfernten Rechner und den enthaltenen Informationen in das Zertifikat.

Also solltest du foo.example.com setzen oder ein Wildcard-Zertifikat erstellen ;-)


-1
2018-05-15 21:41



Ich denke nicht, dass das stimmt. - mgorven
Ich werde meine Antwort verbessern. Wenn ich auf meinem Mail-Server eine Verbindung zwischen meinem Host-Server mit dem Namen mx1.dn.tld und einem anderen Server mit dem Namen foo.dn.tld haben möchte, muss ich ein SSL-Cert mit dem Hostnamen mx1 generieren .dn.tld. Wenn Sie nun einen Mail-Server haben, auf den Sie von anderen Diensten mit externem Standardzugriff wie zum Beispiel IMAP zugreifen können, legen Sie folgenden DNS-Aliasnamen fest: imap.dn.tld, der eine Verbindung zu einer IP oder einem anderen Hostnamen herstellt (mx1. dn.tld zum Beispiel). und generieren Sie dann ein SSL-Zertifikat mit diesem Hostnamen imap.dn.tld. - Dr I
Ja, aber die Frage betraf nicht den IMAP / POP3-Zugriff, sondern die E-Mail-Zustellung mit SMTP. - mgorven