Postfix permet d'éviter cela en vérifiant à la place que le certificat utilisé couvre bien le nom de domaine destinataire
C’est plus compliqué que ça.
En pratique, il ne faut pas vérifier le nom de domaine du certificat, car à l’inverse de HTTPS, SMTP+STARTTLS ne permet pas SNI, ie. de sélectionner un certificat pour chaque domaine de destination, sauf à sous-entendre que 1 domaine = 1 serveur SMTP & 1 IP.
C’est par exemple particulièrement vrai pour les fournisseurs mutualisés, comme OVH, Google ou Microsoft, qui n’ont qu’un seul MX pour l’ensemble des domaines servis.
Au mieux on pourrait seulement vérifier que domaine du certificat = domaine du MX (ou de son reverse), mais en aucun cas la vérification domaine du certificat = domaine du récepteur n’est possible. Une usurpation du DNS ne pourra donc pas être détectée par ce moyen.
De plus, les RFC mentionnent aussi qu’il faut considérer que les serveurs SMTP émetteurs n’ont pas les compétences nécessaires pour vérifier la chaîne de validité, par exemple pas de liste de CA valides (cf https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-3.1.3).
Un MitM serait dans tous les cas facilement faisables, via un simple certificat auto-signé usurpant le domaine visé...
En clair, le mail est non sécurisable parce que personne ne l’a envisagé comme ça quand il a été définit au début du monde, et toutes les couches de sécu actuelles sont des hacks plus ou moins ignobles et (in)efficaces pour corriger le tir.
[^] # Vérif du certificat
Posté par Aeris (site web personnel) . En réponse au journal Chiffrement de SMTP, une obligation?. Évalué à 4.
C’est plus compliqué que ça.
En pratique, il ne faut pas vérifier le nom de domaine du certificat, car à l’inverse de HTTPS, SMTP+STARTTLS ne permet pas SNI, ie. de sélectionner un certificat pour chaque domaine de destination, sauf à sous-entendre que 1 domaine = 1 serveur SMTP & 1 IP.
C’est par exemple particulièrement vrai pour les fournisseurs mutualisés, comme OVH, Google ou Microsoft, qui n’ont qu’un seul MX pour l’ensemble des domaines servis.
Au mieux on pourrait seulement vérifier que domaine du certificat = domaine du MX (ou de son reverse), mais en aucun cas la vérification domaine du certificat = domaine du récepteur n’est possible. Une usurpation du DNS ne pourra donc pas être détectée par ce moyen.
De plus, les RFC mentionnent aussi qu’il faut considérer que les serveurs SMTP émetteurs n’ont pas les compétences nécessaires pour vérifier la chaîne de validité, par exemple pas de liste de CA valides (cf https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-3.1.3).
Un MitM serait dans tous les cas facilement faisables, via un simple certificat auto-signé usurpant le domaine visé...
En clair, le mail est non sécurisable parce que personne ne l’a envisagé comme ça quand il a été définit au début du monde, et toutes les couches de sécu actuelles sont des hacks plus ou moins ignobles et (in)efficaces pour corriger le tir.