Quel nom d'hôte doit-il contenir un certificat SSL pour un serveur SMTP?
J'ai un serveur foo.example.com au 192.0.2.1
Il gère EXIM pour recevoir un e-mail pour plusieurs de mes domaines.
Mes domaines ont chacun un enregistrement MX pointant vers mx.example.com, qui se résout à 192.0.2.1
Si je souhaite faire de l'offre EXIM Cryptage TLS pour les connexions de messagerie entrantes, quel nom d'hôte dois-je mettre dans le certificat SSL?
- foo.example.com parce que c'est ce que le serveur dira dans l'HELO?
- mx.example.com Parce que c'est le nom d'hôte que les clients auront connecté?
http://www.checktls.com suggère que ce dernier est correct, mais je ne trouve pas de réponse définitive.
Ceci n'est effectivement défini explicitement nulle part et si le serveur doit être "fiable" dépend du client (qui pourrait bien sûr être un autre serveur de messagerie) en se connectant; citant de la RFC pertinente (- RFC 2487 ):
Si le client SMTP décide que le niveau d'authentification ou
[.____] la vie privée n'est pas assez élevée pour qu'il continue, il devrait émettre un
Commande SMTP Quitter immédiatement après la fin de la négociation TLS.
[.____] si le serveur SMTP décide que le niveau d'authentification ou
La vie privée n'est pas assez élevée pour qu'il continue, il devrait répondre à
[.____] Toutes les commandes SMTP du client (autre qu'une commande Quitting) avec
[.____] Le code de réponse 554 (avec une éventuelle chaîne de texte telle que "commande
[.____] a refusé à cause du manque de sécurité ").La décision de croire ou non l'authenticité de la
[.____] L'autre partie dans une négociation TLS est une affaire locale. Cependant, certains
[.____] Les règles générales pour les décisions sont:- 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.
Ce que cela signifie fondamentalement, lorsque le serveur offre un cryptage TLS à l'aide d'un certificat donné, la décision de l'accepter ou de le refuser dépend entièrement de l'autre partie, qui veut probablement Voulez-vous le nom sur le certificat à Soyez le même qu'il est connecté, mais pourrait très bien l'accepter même si cela ne correspond pas.
Mais attendez, il y en a plus. Citant à nouveau du même RFC:
À la fin de la poignée de main TLS, le protocole SMTP est réinitialisé à
[.____] L'état initial (l'état dans SMTP après un serveur émet un 220
Service prêt à accueillir). Le serveur doit jeter toute connaissance
[.____] obtenu auprès du client, tel que l'argument de la commande EHLO,
Qui n'a pas été obtenu de la négociation TLS elle-même. Le client
[.____] doit supprimer toutes les connaissances obtenues du serveur, telles que la liste
[.____] des extensions de service SMTP, qui n'a pas été obtenue à partir du TLS
Négociation elle-même. Le client doit envoyer une commande EHLO en tant que
Première commande après une négociation TLS réussie.
Donc, ce que le serveur dit en réponse à HELO/EHLO Avant La poignée de main TLS ne semble pas réellement importante du tout.
Dans mon expérience, des certificats auto-signés fonctionnent plutôt bien sur des serveurs de messagerie sur Internet, ce qui signifie que le Autre Les serveurs de messagerie ne se soucient même pas de les valider, ils accepteront tout simplement n'importe quoi peut fournir un cryptage TLS, indépendamment de l'autorité émettrice ou du nom de sujet.
Un MTA délivrant le courrier à votre domaine va chercher l'enregistrement MX (qui donnera un nom d'hôte), puis consultez un enregistrement pour ce nom d'hôte. Le nom d'hôte qu'il se connecte est donc le nom d'hôte MX, et c'est donc ce qui sera vérifié contre le nom commun du certificat SSL. Vérification du nom d'hôte Helo n'a pas de sens car le serveur peut fournir n'importe quel nom d'hôte Helo qu'il veut - il ne fournit pas de sécurité supplémentaire.
Cela dit, vérifiant strictement les certificats SSL lors de la livraison de courrier ne sont pas particulièrement utiles pour le moment, car les MTA seront (presque toujours) de replier à la livraison non SSL, car c'est la manière dont SMTP fonctionne pour le moment. La configuration sensible doit donc utiliser SSL si le serveur MX l'offre, que le certificat SSL vérifie ou non (étant donné que le cryptage sans authentification est meilleur qu'aucun cryptage et pas d'authentification). Vous pourriez donc aussi bien utiliser un certificat auto-signé à cette fin.
La tâche de vérifier le certificat de serveur et de correspondre au nom d'hôte du serveur est purement du rôle du client, pour tout protocole utilisant SSL/TLS.
En tant que tel, le nom d'hôte du certificat doit correspondre au nom que le client tente d'accéder.
Lorsque la connexion SSL/TLS est initiée à l'avant (SMTPS), le serveur n'a aucun moyen de voir ce que dit le message Helo avant la création de la connexion. Il doit donc utiliser celui avec lequel il a fait la demande.
Lorsque vous utilisez SSL/TLS après STARTTLS _, le client a toujours l'intention de parler au serveur avec lequel il a été configuré, c'est donc toujours ce qu'il devrait vérifier. L'échec de cela rendrait les attaques MITM possible:
- C-> S: Bonjour, je suis Alice, je veux parler à Bob.
- S-> C: Bonjour, je suis Chuck, voici mon cert pour Chuck.
- C-> S: OH OUI, votre certificat est en effet valable pour Chuck. Continuons.
- ... Il y a une faille là-bas bien sûr, puisque Alice voulait une communication sécurisée avec Bob.
Dans les deux cas, c'est l'adresse MX qui devrait être utilisée.
Les règles de correspondance de nom d'hôte ont récemment été recueillies à travers des protocoles dans RFC 6125 , mais peu de clients la mettent en œuvre complètement (c'est plus une meilleure pratique RFC que le changement complet, et il est encore assez récent).
Dans son appendice , il résume ce qui existait à propos de SMTP avant (tiré de RFC 3207 et RFC 4954 ). En particulier ", le client ne doit utiliser aucune forme de nom d'hôte de serveur dérivé d'une source distante non sécurisée (par exemple, une recherche DNS insécuritée). " (qui s'applique à la bannière du serveur bien sûr). En dehors de cela, les règles héritées SMTP étaient un peu plus détendues que https concernant les noms alternatifs de sujet (. au lieu de doit être utilisé).
La manière moderne est définitivement de placer le nom d'hôte dans une entrée en question DNS Entrée DNS. L'utilisation générique est également découragée .
Je pense que le mieux serait de copier ce qui se fait dans la pratique. J'ai vérifié une adresse e-mail en utilisant yahoo.com http://checktls.com Si tout va bien, Yahoo, ils ont utilisé un autre domaine pour leur nom d'hôte et pour leur domaine mx. Ainsi, leur nom d'hôte est un yahoo.com et leurs extrémités domaine mx avec yahoodns.net
Dig mx yahoo.com gives mta6.am0.yahoodns.net. among others
Résultat de checktls: le certificat SSL CN = MX domaine (* .yahoodns.net)
J'ai fait la même chose avec Cisco et j'ai eu le même résultat.
Encryption SSL/TLS, le client vérifie toujours la correspondance entre le nom d'hôte "réel"/"déclaré" sur la machine distante et les informations contiennent dans le certificat.
Donc, vous devriez probablement définir foo.example.com ou générer un certificat Wildcard ;-)