Comme on l'a vu, il n'est pas réaliste pour l'administrateur d'un serveur de courrier d'imposer le chiffrement pour toutes les transmissions sortantes. En revanche, il peut être utile de le faire pour les noms de domaines destinataires dont on sait qu'ils le prennent en charge avec une configuration correcte.
Voici donc comment le faire avec Postfix. Avertissement : je n'ai pas essayé, pas encore du moins. Dans /etc/postfix/master.cf, définir un nouveau transport forcetls :
Ensuite, définir une table de transports, dans /etc/postfix/main.cf :
transport_maps = hash:/etc/postfix/transport
Créer cette table, en y mettant les noms de domaines pour lesquels on veut transmettre exclusivement en TLS avec vérification :
laposte.net force-tls:
Hacher cette table, puis redémarrer Postfix :
# postmap /etc/postfix/transport
# service postfix restart
À noter qu'avec cette configuration, pour un nom de domaine donné, Postfix ira chercher les MX, par résolution DNS souvent non sécurisée — DNSSEC est encore loin d'être la norme — puis, s'il fait partie de cette liste des noms de domaines pour lesquels il doit transmettre exclusivement en TLS avec vérification, vérifier que le certificat utilisé couvre bien le nom du MX choisi — et non le nom de domaine destinataire.
Cela laisse donc un vecteur d'attaque, par réécriture des réponses DNS, qui permet à l'attaquant d'indiquer son propre MX qui prendra en charge TLS avec un certificat qui couvre bien son nom. Postfix permet d'éviter cela en vérifiant à la place que le certificat utilisé couvre bien le nom de domaine destinataire. Cela a plus de sens, puisqu'on cherche à s'assurer qu'on est bien en train de transmettre aux serveurs d'un nom de domaine destinataire donné, et non à un MX précis. L'ennui, c'est qu'il semble qu'il est justement courant d'utiliser un certificat qui couvre le nom de MX et non le nom de domaine destinataire, ce qui est donc moins sûr, mais beaucoup plus pratique lorsqu'on fait de l'hébergement virtuel de noms de domaines multiples, faute de SNI : cette vérification correcte serait donc en pratique peu utilisable... À vérifier toutefois ; pour info, cela se fait avec une autre valeur de smtp_tls_security_level ou en modifiant globalement le smtp_tls_verify_cert_match.
# Postfix
Posté par 🚲 Tanguy Ortolo (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 8. Dernière modification le 12 octobre 2015 à 17:44.
Comme on l'a vu, il n'est pas réaliste pour l'administrateur d'un serveur de courrier d'imposer le chiffrement pour toutes les transmissions sortantes. En revanche, il peut être utile de le faire pour les noms de domaines destinataires dont on sait qu'ils le prennent en charge avec une configuration correcte.
Voici donc comment le faire avec Postfix. Avertissement : je n'ai pas essayé, pas encore du moins. Dans
/etc/postfix/master.cf, définir un nouveau transportforcetls:Ensuite, définir une table de transports, dans
/etc/postfix/main.cf:Créer cette table, en y mettant les noms de domaines pour lesquels on veut transmettre exclusivement en TLS avec vérification :
Hacher cette table, puis redémarrer Postfix :
À noter qu'avec cette configuration, pour un nom de domaine donné, Postfix ira chercher les MX, par résolution DNS souvent non sécurisée — DNSSEC est encore loin d'être la norme — puis, s'il fait partie de cette liste des noms de domaines pour lesquels il doit transmettre exclusivement en TLS avec vérification, vérifier que le certificat utilisé couvre bien le nom du MX choisi — et non le nom de domaine destinataire.
Cela laisse donc un vecteur d'attaque, par réécriture des réponses DNS, qui permet à l'attaquant d'indiquer son propre MX qui prendra en charge TLS avec un certificat qui couvre bien son nom. Postfix permet d'éviter cela en vérifiant à la place que le certificat utilisé couvre bien le nom de domaine destinataire. Cela a plus de sens, puisqu'on cherche à s'assurer qu'on est bien en train de transmettre aux serveurs d'un nom de domaine destinataire donné, et non à un MX précis. L'ennui, c'est qu'il semble qu'il est justement courant d'utiliser un certificat qui couvre le nom de MX et non le nom de domaine destinataire, ce qui est donc moins sûr, mais beaucoup plus pratique lorsqu'on fait de l'hébergement virtuel de noms de domaines multiples, faute de SNI : cette vérification correcte serait donc en pratique peu utilisable... À vérifier toutefois ; pour info, cela se fait avec une autre valeur de
smtp_tls_security_levelou en modifiant globalement lesmtp_tls_verify_cert_match.