Qu'est-ce que la déclaration SMTP TLS ?
TLS Reporting est un mécanisme de rétroaction qui aide les propriétaires de domaines à trouver les problèmes de livraison des courriels avec une grande précision. Il fonctionne en conjonction avec l'outil MTA-STS et fournit des données de suivi sur les courriels rejetés qui n'ont pas été délivrés en raison d'un échec de l'accord TLS.
Que signifie le rapport TLS ?
TLS Reporting (TLS-RPT) est une norme permettant de signaler les problèmes de livraison d'e-mails qui surviennent lorsqu'un e-mail n'est pas crypté avec TLS. Il supporte le protocole MTA-STS qui est utilisé pour garantir que tout email envoyé à votre domaine est crypté avec TLS.
- Le cryptage TLS garantit que tous les courriels qui vous sont envoyés sont délivrés en toute sécurité. Toutefois, un pirate peut tenter un déclassement SMTP, un type d'attaque où le courriel vous est envoyé sans être chiffré, ce qui lui permet d'en lire ou d'en modifier le contenu. MTA-STS lutte contre ce problème en obligeant tous les courriels à être cryptés avant de vous être envoyés. Si un pirate tente d'effectuer un déclassement SMTP, le courriel ne sera pas envoyé du tout.
- Le TLS-RPT vous permet, en tant que propriétaire de domaine, de recevoir des rapports sur chaque courriel qui n'est pas crypté et qui ne vous est pas envoyé. Vous pouvez alors identifier la source du problème et résoudre vos problèmes de livraison.
Comment fonctionnent les rapports TLS ?
Le rapport TLS (TLS-RPT) est utilisé pour prendre en charge le protocole MTA-STS, qui garantit que les courriels sont chiffrés avant d'être livrés. Normalement, votre serveur de messagerie ou agent de transfert de courrier (MTA) négocie avec le serveur de réception pour voir s'il prend en charge la commande STARTTLS. Si c'est le cas, l'e-mail est crypté avec TLS et est remis au MTA récepteur.
Un attaquant pourrait tenter une attaque de déclassement SMTP à ce stade, ce qui implique le blocage de la négociation entre les MTA d'envoi et de réception. Le serveur émetteur pense que le récepteur ne prend pas en charge la commande STARTTLS et envoie le courriel sans cryptage TLS, ce qui permet à l'attaquant de voir ou de modifier le contenu du courriel.
Lorsque vous implémentez MTA-STS dans votre domaine, votre serveur d'envoi doit obligatoirement crypter les messages avant de les envoyer. Si un pirate tente une attaque SMTP par rétrogradation, l'e-mail ne sera tout simplement pas envoyé. Cela garantit le cryptage TLS de tous vos courriels sans faille.
Le rapport TLS (TLS-RPT) est un protocole qui vous notifie, en tant que propriétaire du domaine, lorsque les courriels envoyés par l'intermédiaire de votre domaine rencontrent des problèmes de livraison. Si un courriel n'est pas envoyé en raison d'un déclassement SMTP ou d'un autre problème, vous recevrez un rapport au format JSON contenant les détails du courriel qui a échoué. Ce rapport ne contient pas le contenu de l'e-mail.
Pourquoi avez-vous besoin de la déclaration SMTP TLS ?
Il est essentiel pour les propriétaires de domaines de rester informés des problèmes de livraison des courriels dus à des défaillances du cryptage TLS pour les courriels envoyés à partir d'un domaine compatible avec MTA-STS. Le rapport TLS permet de fournir ces informations.
Recevoir les rapports d'évaluation
Si un message n'est pas envoyé, les rapports TLS vous permettent d'en être informé.
Pour une visibilité totale des canaux d'e-mail
Obtenez des informations détaillées sur votre flux d'e-mails grâce aux rapports TLS
Éliminer les problèmes de livraison
Les rapports TLS vous aident à identifier la source du problème et à le résoudre sans délai.
Étapes de l'activation du rapport TLS
Vous pouvez activer le reporting TLS pour votre domaine en créant un enregistrement TXT pour TLS-RPT et en le publiant sur votre DNS. Cet enregistrement doit être publié dans le sous-domaine _smtp._tls.votredomaine.com
Exemple d'enregistrement TLS-RPT
v=TLSRPTv1 ; rua=mailto:[email protected] ;
Décortiquons les composants de l'enregistrement de rapport TLS fourni :
v=TLSRPTv1 :
Cette balise indique la version du protocole TLS-RPT utilisée. Dans le cas présent, "TLSRPTv1" indique la première version du protocole TLS-RPT.
rua=mailto:[email protected] :
Cette balise indique l'URI de rapport pour les rapports agrégés (RUA). Elle indique où le serveur de messagerie du destinataire doit envoyer les rapports agrégés sur les échecs TLS. rua signifie "Reporting URI for Aggregated Reports" (URI de rapport pour les rapports agrégés).
La valeur "mailto:[email protected]" est un URI qui spécifie une adresse électronique ([email protected]) à laquelle les rapports agrégés doivent être envoyés par courrier électronique.
En pratique, vous remplacerez "votredomaine.com" par le nom du domaine dans lequel vous souhaitez recevoir ces rapports.
L'importance de chaque élément :
v=TLSRPTv1 :
Indique la version du protocole TLS-RPT utilisée. Elle permet d'assurer la compatibilité entre l'expéditeur et le destinataire des rapports.
rua=mailto:[email protected] :
Ceci spécifie la destination des rapports agrégés pour les problèmes de livraison TLS. En fournissant une adresse électronique de rapport, les propriétaires de domaines peuvent recevoir des informations sur les connexions TLS qui ont échoué ou qui posent problème. Ces rapports sont utiles pour diagnostiquer les problèmes potentiels de sécurité ou de configuration liés à la communication par courrier électronique.
Format de rapport TLS et exemple de rapport
Un rapport TLS JSON suit un format spécifique défini par la spécification TLS-RPT (Transport Layer Security Reporting Policy). Ce format est utilisé pour transmettre des informations sur les problèmes de livraison de courrier électronique liés au cryptage TLS. Vous trouverez ci-dessous un exemple de ce à quoi peut ressembler un rapport JSON TLS :
Voici la répartition des principaux champs de ce rapport JSON TLS :
organisation: L'organisation du domaine qui possède l'enregistrement TLS-RPT.
email: L'adresse électronique à laquelle les rapports agrégés sont envoyés.
date_début: La date de début de la période de déclaration.
date_fin: La date de fin de la période de déclaration.
politiques: Un tableau d'objets de politiques qui décrivent les politiques appliquées au cours de la période de déclaration.
politique: Contient des informations sur la politique appliquée.
type_politique: Spécifie le type de politique (par exemple, "policy" pour une politique TLS).
chaîne_politique: Spécifie la chaîne de politique associée à la politique (par exemple, "reject" pour une politique TLS stricte).
résumé: Contient des informations récapitulatives sur les sessions qui ont été tentées.
total_successful_session_count: Nombre total de sessions TLS établies avec succès.
total_failure_session_count: Le nombre total d'échecs de sessions TLS.
détails_de_l'échec: Un tableau d'objets fournissant des détails sur des échecs spécifiques.
raison: Une chaîne de caractères indiquant la raison de l'échec (par exemple, "certificat_expiré").
compter: Le nombre de sessions qui ont échoué pour une raison spécifique.
Raisons et types d'échec du chiffrement TLS
Questions relatives aux certificats :
- certificat_expiré: Le certificat présenté par le serveur distant a dépassé sa date d'expiration, ce qui le rend indigne de confiance pour le cryptage.
- certificat_non_valide_encore: Le certificat présenté par le serveur distant n'est pas encore valide, peut-être en raison d'une heure de serveur incorrecte ou d'une utilisation prématurée du certificat.
- certificat_revoked: Le certificat présenté par le serveur distant a été révoqué par l'autorité de certification pour des raisons de sécurité.
- certificat non fiable: La chaîne de certificats présentée par le serveur distant n'est pas approuvée par le serveur de messagerie ou le client de l'expéditeur, ce qui indique un risque potentiel pour la sécurité.
- pas_de_signature_valide: Le certificat présenté par le serveur distant n'est pas correctement signé par une autorité de certification de confiance, ce qui soulève des doutes quant à son authenticité.
- certificat non supporté: Le certificat présenté par le serveur distant utilise des algorithmes de cryptage ou des longueurs de clés qui ne sont pas pris en charge par le serveur de messagerie de l'expéditeur, ce qui empêche une connexion sécurisée.
Mauvaise correspondance entre le nom d'hôte et l'identité
- incompatibilité du nom d'hôte: Le nom d'hôte spécifié dans le certificat du serveur ne correspond pas au nom d'hôte du serveur auquel le serveur de messagerie de l'expéditeur tente de se connecter, ce qui indique une éventuelle attaque de type man-in-the-middle ou un problème de configuration.
Suite de chiffrement et configuration du chiffrement
- suite_de_chiffrement_insécurisé: La suite de chiffrement négociée entre les serveurs de messagerie de l'expéditeur et du destinataire est considérée comme faible ou peu sûre, ce qui peut compromettre la confidentialité et l'intégrité de la communication.
- inadéquation_version_protocole: Les versions du protocole TLS prises en charge par les serveurs de messagerie de l'expéditeur et du destinataire ne correspondent pas, ce qui les empêche d'établir une connexion cryptée compatible.
- no_shared_cipher_suite: Il n'y a pas de suite de chiffrement commune disponible pour les serveurs de messagerie de l'expéditeur et du destinataire pour le chiffrement, ce qui entraîne l'échec de la connexion.
Questions relatives à la poignée de main et au protocole
- échec de la poignée de main: Un problème s'est produit au cours du processus initial de prise de contact TLS entre le serveur de messagerie de l'expéditeur et le serveur de messagerie du destinataire, empêchant l'établissement d'un canal sécurisé.
- message_inattendu: Le serveur de messagerie de l'expéditeur a reçu un message inattendu ou non pris en charge au cours du processus d'échange TLS, ce qui indique une inadéquation potentielle du protocole ou de l'implémentation.
Questions politiques MTA-STS
- mta_sts_policy_not_found: Cet échec se produit lorsque le serveur de messagerie de l'expéditeur ne parvient pas à trouver une politique MTA-STS pour le domaine du destinataire.
- mta_sts_policy_invalid: Cet échec se produit lorsque la politique MTA-STS trouvée dans le DNS pour le domaine du destinataire n'est pas valide, contient des erreurs ou n'adhère pas à la spécification MTA-STS.
- mta_sts_policy_fetch_error: Cet échec se produit lorsque le serveur de messagerie de l'expéditeur rencontre une erreur en essayant de récupérer la politique MTA-STS à partir des enregistrements DNS du domaine du destinataire.
- mta_sts_connection_failure: Cet échec se produit lorsque le serveur de messagerie de l'expéditeur tente d'établir une connexion sécurisée à l'aide de MTA-STS mais échoue pour des raisons telles que des certificats non fiables, des suites de chiffrement non prises en charge ou d'autres problèmes TLS.
- mta_sts_invalid_hostname: Cet échec se produit lorsque le nom d'hôte du serveur de messagerie du destinataire, tel que spécifié dans la politique MTA-STS, ne correspond pas au nom d'hôte réel du serveur.
- mta_sts_policy_upgrade: Cet échec se produit lorsque le serveur de messagerie de l'expéditeur tente de passer à une connexion sécurisée en utilisant MTA-STS, mais que le serveur du destinataire ne prend pas en charge la mise à niveau.
Rapports SMTP TLS simplifiés avec PowerDMARC
L'expérience de PowerDMARC en matière de rapports SMTP TLS vise à améliorer votre sécurité tout en vous facilitant la vie avec un service hébergé.
Rapports TLS traduits
Les rapports JSON complexes pour les rapports TLS sont convertis en informations simplifiées que vous pouvez parcourir en quelques secondes ou lire en détail.
Questions relatives à l'autodétection
La plateforme PowerDMARC identifie automatiquement le problème auquel vous êtes confronté afin que vous puissiez le résoudre sans perdre de temps
