MTA-STS pour Postfix

MTA-STS est la norme RFC8461 proposée qui est sortie du statut provisoire et publiée officiellement le 26 septembre 2018. Cette norme offre un mécanisme pour détecter la possibilité d'utiliser TLS complet entre les serveurs de messagerie, avec cryptage des données et authentification du serveur. Autrement dit, cette norme protège presque complètement contre les interférences avec le trafic de messagerie entre les serveurs.

Simplifié, l'essence de la norme est la suivante:

1. Les services de messagerie pris en charge publient une stratégie (1 enregistrement TXT et 1 ressource HTTPS pour chaque domaine).
2. Les services de messagerie lors de l'envoi de courrier vers d'autres domaines détectent la stratégie de domaine du destinataire.
3. Les services de messagerie se connectent au serveur de messagerie du domaine destinataire, en appliquant, le cas échéant, les restrictions TLS définies par la stratégie détectée.

Il existe de bons articles ( par exemple ) qui parlent de la norme elle-même et pourquoi elle est nécessaire, comparant MTA-STS avec d'autres initiatives similaires, et montrant même comment écrire et publier une politique. Mais trouver comment dépasser la première étape n'était pas si simple.

Recommencer

Avant d'implémenter MTA-STS, vous devez nettoyer les certificats du serveur de messagerie. Sinon, les serveurs de messagerie qui prennent en compte votre politique STS rejetteront la connexion à votre serveur. Les conditions suivantes doivent être remplies:

• Le certificat de serveur est délivré par une autorité de certification reconnue (Let's Encrypt est bon).
• La chaîne de certificats envoyée par le serveur comprend tous les certificats nécessaires des autorités de certification intermédiaires.
• Le certificat a un champ Subject Alternative Name avec le nom DNS de votre serveur MX.

Vous pouvez vérifier le serveur configuré avec le certificat avec la commande suivante:

[ "$(LANG=C openssl s_client -connect MX.EXAMPLE.COM:25 -starttls smtp -verify_hostname MX.EXAMPLE.COM < /dev/null 2>&1 | fgrep 'error')" = "" ] && echo OK || echo FAIL 

où MX.EXAMPLE.COM est le nom de domaine de votre serveur MX. Pour une conformité totale avec la norme, il est conseillé de vérifier que le nom de domaine souhaité est présent non seulement dans le nom commun du certificat, mais au moins dans le nom alternatif du sujet.

Publication de politique

Afin de désigner votre domaine comme prenant en charge une connexion sécurisée avec lui, vous devez publier la politique MTA-STS. Pour ce faire, effectuez les étapes simples suivantes dans l'ordre spécifié (des exemples sont donnés pour le domaine example.com).

1. Placer à

  https://mta-sts.example.com/.well-known/mta-sts.txt 

fichier texte du formulaire:

 version: STSv1
 mode: appliquer
 mx: mail.example.com
 mx: * .example.net
 mx: backupmx.example.com
 max_age: 604800

Le fichier doit être fourni avec Content-Type: text / plain. Les redirections ne sont pas autorisées. Les sauts de ligne doivent être LF ou CRLF. Les lignes vides ne sont pas autorisées. La dernière ligne peut se terminer par un saut de ligne, ou elle ne peut pas se terminer par elle - les deux options sont autorisées. L'espace vide avant les deux points et au début de la ligne n'est pas autorisé. L'espace vide après les deux points est autorisé en n'importe quelle quantité. Les espaces blancs (espaces, tabulations, etc.) à la fin de chaque ligne sont ignorés.

Valeurs de champ:

version : format version. Il doit toujours être égal à "STSv1".
mode : mode politique. Options possibles: aucune, test, appliquer. Le mode d'application correspond au fonctionnement normal de la norme - exiger le certificat correct et une connexion TLS stable lors de la connexion au serveur. Le mode de test vous oblige à essayer d'utiliser une connexion sécurisée, mais en cas d'erreur, envoyez un courrier électronique avec une notification d'administrateur via le mécanisme TLSRPT. Aucun mode correspond à la situation comme si la politique n'était pas publiée du tout. Ce mode est utile pour désactiver correctement une stratégie.
mx : un ou plusieurs champs contenant les noms de tous les serveurs de domaine MX autorisés. Comme vous pouvez le voir dans l'exemple, les modèles sont autorisés, mais uniquement en tant que domaine de niveau inférieur.
max_age : durée en secondes pendant laquelle la politique peut être mise en cache et pendant laquelle les expéditeurs peuvent continuer à l'utiliser si la politique n'est plus disponible. En raison de cette fonctionnalité de la norme, la désactivation de STS est plus rapide en publiant une nouvelle stratégie sans mode.

2. Créez un enregistrement TXT _mta-sts.example.com avec le contenu du formulaire:

  v = STSv1;  id = 20160831085700Z; 

Les espaces autour d'un point-virgule peuvent être arbitrairement disposés en n'importe quelle quantité. Dans d'autres endroits, les espaces blancs ne sont pas autorisés. Le dernier point-virgule peut être présent ou absent.

Valeurs de champ:

v : format de version. Il doit toujours être le premier champ, il doit toujours être égal à STSv1.
id : identifiant unique de la politique publiée. Il peut s'agir d'une chaîne de 1 à 32 caractères, composée de lettres de registres et de chiffres. La modification de la valeur de l'ID indique aux expéditeurs que la stratégie a été mise à jour. Par conséquent, vous devez mettre à jour la stratégie en publiant d'abord un nouveau fichier de stratégie, puis en changeant l'ID dans l'enregistrement TXT.

Désormais, les serveurs de messagerie qui prennent en charge MTA-STS n'enverront que du courrier à votre domaine via une connexion sécurisée authentifiée par certificat. C’est là que se terminent la plupart des manuels, mais la partie la plus intéressante à venir est d’obtenir la politique MTA-STS depuis votre propre serveur lors de l’envoi de courrier.

Le plus intéressant

La principale difficulté est que cette norme n'est pas prise en charge par les serveurs de messagerie, y compris Postfix. Cependant, cette bagatelle désagréable ne devrait pas nous arrêter.

Trouver une solution m'a amené aux archives de la liste de diffusion des utilisateurs de postfix discutant du timing de cette norme. Dans un article, Witsa Venema, auteur de Postfix, indique la direction préférée pour implémenter cette fonctionnalité - utiliser un serveur externe pour rechercher des politiques TLS. Il est proposé d'utiliser la directive de configuration du formulaire:

  smtp_policy_maps = socketmap: inet: hôte: port: nom 

J'ai implémenté un tel serveur pour obtenir la politique MTA-STS.

→ Code source
→ Package en PyPI

Il manque à l'application certaines des fonctions prescrites par la RFC8461, telles que: récupération proactive des politiques, rapports et limitation de la fréquence des demandes de politique. Cependant, la fonction principale - détecter la politique TLS et la mettre en cache - elle fonctionne.

L'application nécessite Python 3.5.3+. L'installation et la configuration de ce démon peuvent être effectuées à l'aide des étapes suivantes.

Installation du package

Il suffit d'exécuter la commande:

 pip3 install postfix-mta-sts-resolver 

Des méthodes d'installation alternatives sont écrites ici .

Création d'un fichier de configuration

Si vous êtes satisfait des paramètres par défaut, la commande suffit

 touch /etc/postfix/mta-sts-daemon.yml 

Sinon, la configuration peut être tirée de l' exemple et adaptée à vos besoins.

Le paramètre le plus important, à mon avis, est le paramètre strict_testing. S'il est défini sur true (false par défaut), l'application renvoie une stratégie sécurisée même pour les domaines avec une stratégie en mode test. Ce comportement est contraire à la norme, mais il est conseillé pour des raisons pratiques: si le propriétaire du domaine a publié la politique STS même en mode test, il est probablement prêt pour cela. C'est-à-dire qu'aujourd'hui, le courrier gmail.com sera envoyé via une connexion fiable.

Organisation de démarrage

Dans le cas de systemd, il suffit de placer un simple fichier d'unité dans /etc/systemd/system/mta-sts-daemon.service

Après cela, il reste à relire la configuration de systemd, activer l'exécution automatique du démon et le démarrer:

 systemctl daemon-reload systemctl enable mta-sts-daemon.service systemctl start mta-sts-daemon.service 

Bilan de santé

En supposant que le port par défaut est utilisé, la commande

 /usr/sbin/postmap -q dismail.de socketmap:inet:127.0.0.1:8461:postfix 

devrait apporter

  correspondance sécurisée = mx1.dismail.de 

Connectez-vous à Postfix

Ajoutez une ligne à main.cf:

 smtp_policy_maps = socketmap:inet:127.0.0.1:8461:postfix 

Redémarrez Postfix:

 systemctl reload postfix.service 

Si tout est fait correctement, alors pour les connexions STS dans le journal /var/log/mail.info à la place

  Connexion TLS sécurisée établie 

les enregistrements commencent à apparaître

  Connexion TLS vérifiée établie 

Conclusion

Si vous arrivez à cet endroit, cela signifie très probablement:

• Vous lisez l'article sans une seule image.
• De jour en jour, la probabilité d'interception de courrier dans votre domaine diminuera, car d'autres services de messagerie implémenteront la nouvelle norme.