Qu'est-ce que le SMTP TLS Reporting (TLS-RPT) ?
par
Dernière mise à jour : Temps de lecture : 11 min
Alors que les organisations utilisent de plus en plus le courrier électronique comme principal moyen de communication, on ne saurait trop insister sur l'importance de protéger ces canaux contre les menaces potentielles. La sécurité de la couche transport(TLS) garantit la confidentialité et l'intégrité des données transmises sur les réseaux.
Le rapport SMTP TLS (TLS-RPT) est un protocole essentiel qui fonctionne avec MTA-STS pour garantir que vos courriels sont livrés en toute sécurité. En fournissant des informations détaillées sur les problèmes de distribution des courriels, TLS-RPT aide les propriétaires de domaines à maintenir l'intégrité et la confidentialité de leurs communications. Dans ce guide complet, nous allons explorer ce qu'est le rapport SMTP TLS, comment il fonctionne et pourquoi il est essentiel pour votre stratégie de sécurité de la messagerie."
Plusieurs protocoles permettent de crypter les canaux de messages SMTP afin d'empêcher les cyberattaquants d'intercepter les communications par courrier électronique. Il s'agit notamment de STARTTLS, DANE et MTA-STS. Cependant, lorsque les tentatives de chiffrement échouent lors de l'utilisation de ces protocoles, il se peut que votre courrier électronique ne soit pas délivré. TLS-RPT (tel que décrit dans la RFC 8460) fournit un mécanisme de retour d'information pour signaler ces échecs de délivrabilité.
Nous recommandons vivement l'utilisation de TLS-RPT en conjonction avec l'application MTA-STS . Comprenons comment ces protocoles fonctionnent ensemble pour renforcer la la sécurité du courrier électronique.
Points clés à retenir
- La sécurité du courrier électronique peut être considérablement renforcée par la mise en œuvre de protocoles tels que TLS-RPT et MTA-STS.
- TLS-RPT fournit des informations essentielles sur les problèmes de distribution du courrier électronique liés au cryptage TLS, aidant ainsi les propriétaires de domaines à contrôler efficacement leurs canaux de courrier électronique.
- Les protocoles STARTTLS, DANE et MTA-STS collaborent pour garantir la sécurité des communications par courrier électronique, réduisant ainsi le risque de cyberattaques.
- La mise en place d'un enregistrement TLS-RPT implique la publication d'un enregistrement TXT dans vos paramètres DNS pour un sous-domaine spécifique.
- Il est essentiel de reconnaître les défaillances du cryptage TLS et d'y remédier pour maintenir la sécurité et la fiabilité des messages électroniques.
Qu'est-ce que le TLS-RPT ?
TLS-RPT (Transport Layer Security Reporting) est une norme permettant de signaler les problèmes d'acheminement du courrier électronique lorsqu'il n'est pas crypté avec TLS. Son importance dans l'authentification des courriels va de pair avec la raison pour laquelle le cryptage TLS est activé pour les courriels.
Le cryptage TLS garantit que tous les courriels qui vous sont envoyés sont délivrés en toute sécurité. Si la connexion n'est pas sécurisée, il arrive souvent que les courriels ne soient pas livrés. TLS-RPT permet aux propriétaires de domaines de surveiller la livraison des courriels et les échecs de connexion. Les rapports peuvent contenir des informations sur :
- Problèmes de gestion de la politique MTA-STS
- Raison et type de l'échec de la livraison
- Adresse IP des agents de transfert de courrier électronique qui envoient et reçoivent des courriels
- Nombre total de sessions de connexion TLS réussies et échouées
Cela permet d'avoir une visibilité sur vos canaux d'email et de contrer plus rapidement les problèmes de délivrabilité.
Simplifiez les rapports SMTP TLS avec PowerDMARC !
Comment fonctionnent les rapports TLS ?
Dans la communication SMTP, le cryptage TLS est "opportuniste". Cela signifie que si un canal crypté ne peut être négocié, le courrier électronique est tout de même envoyé en clair. En fait, il y a près de quarante ans, les protocoles de messagerie SMTP ne prenaient pas en charge le cryptage TLS. Il a fallu l'intégrer ultérieurement sous la forme de la commande STARTTLS.
La commande STARTTLS n'est utilisée dans les communications SMTP que si les deux parties supportent le cryptage TLS. Dans le cas contraire, le courrier électronique sera toujours envoyé en texte brut.
Pour se débarrasser du cryptage opportuniste dans SMTP, MTA-STS a été introduit (RFC 8461). Le protocole MTA-STS garantit que les courriels sont cryptés avant d'être délivrés. Votre serveur de messagerie ou agent de transfert de courrier (MTA) négocie avec le serveur de réception pour vérifier s'il prend en charge la commande STARTTLS. Si c'est le cas, l'e-mail est crypté avec TLS et délivré. Dans le cas contraire, la livraison échoue.
Explication étape par étape du fonctionnement de TLS-RPT
1. Comprendre le processus de la poignée de main TLS
La poignée de main TLS (Transport Layer Security) est le processus d'établissement d'une connexion sécurisée entre deux agents de transfert de courrier (MTA) qui communiquent entre eux. Ce processus comprend les étapes suivantes :
- Le MTA qui envoie le courrier électronique envoie un message "Client Hello" au MTA qui le reçoit. Ce message contient des paramètres utiles tels que les versions TLS et les suites de chiffrement.
- Le MTA qui reçoit le courrier électronique reçoit ce message et répond par un message "Server Hello". Ce message contient la version TLS et la suite de chiffrement sélectionnées.
- Après l'initiation de la poignée de main TLS, le MTA récepteur envoie son certificat SSL/TLS qui est délivré par une autorité de certification de confiance. Ce certificat contient la clé publique.
- Les deux MTA qui communiquent échangent en toute sécurité leurs clés cryptographiques et établissent une connexion cryptée TLS. Cela garantit une communication sécurisée entre les deux parties.
2. Scénarios d'échec de la poignée de main TLS
Les échanges TLS peuvent échouer pour diverses raisons :
- Erreurs de certification : Les certificats expirés ou les certificats émis par des autorités de certification non fiables peuvent entraîner des échecs de la poignée de main TLS.
- Inadéquation des versions : La non-concordance des versions TLS prises en charge par les MTA d'envoi et de réception peut entraîner l'échec de la poignée de main.
- Échecs de STARTTLS : Si la commande STARTTLS n'est pas correctement mise en œuvre, elle peut à nouveau entraîner un échec du cryptage TLS.
- Application de la politique MTA-STS : Si le destinataire du courrier électronique a défini le mode de sa politique MTA-STS sur "enforce", un échec de la poignée de main TLS peut entraîner le rejet du message.
3. Production et transmission des rapports
En cas d'échec du cryptage TLS, le serveur d'envoi génère un rapport TLS-RPT et l'envoie au propriétaire du domaine pour qu'il l'évalue et le dépanne.
Contenu du rapport
Détails du serveur d'envoi: Adresse IP et nom de domaine de l'expéditeur.
Détails du serveur de réception: Le domaine du destinataire et les informations sur le serveur de messagerie.
Description de l'erreur: Type et détails de l'erreur (par exemple, erreur de certificat, incompatibilité de protocole).
Le temps de l'échec: Heure à laquelle le problème s'est produit.
Policy Mode (Mode de politique) : Indique si le domaine est en mode "test" ou "application".
Remise du rapport
Ces rapports TLS sont envoyés au format JSON à l'adresse électronique spécifiée dans l'enregistrement DNS TLS-RPT du propriétaire du domaine.
Rôle du cryptage opportuniste dans le SMTP
Le protocole SMTP utilise traditionnellement un cryptage opportuniste. Cela signifie qu'il tente d'utiliser TLS, mais qu'il se rabat sur une livraison non chiffrée si le MTA de réception ne prend pas en charge TLS.
Toutefois, le chiffrement opportuniste présente une limitation majeure. Dans ce type de cryptage qui ne fixe aucun mandat, les courriels peuvent être envoyés en clair (dans un format non crypté) si le cryptage TLS échoue. Ces messages non chiffrés sont vulnérables à l'interception.
Fonctionnement conjoint de MTA-STS et de TLS-RPT
Mail Transfer Agent Strict Transport Security (MTA-STS) et TLS-RPT sont des protocoles complémentaires dans l'écosystème de l'authentification du courrier électronique. MTA-STS garantit que l'agent de transfert de courrier (MTA) d'envoi doit utiliser TLS pour la livraison et rejeter les courriels en cas d'échec du cryptage,
TLS-RPT permet aux propriétaires de domaines de surveiller les échecs des échanges TLS et de résoudre les problèmes. Lorsqu'ils sont mis en œuvre conjointement, ils peuvent empêcher l'interception des messages en transit et minimiser les problèmes de délivrabilité du courrier électronique.
Relation entre DANE et TLS-RPT
L'authentification des entités nommées basée sur le DNS (DANE) est un protocole qui permet aux propriétaires de domaines de spécifier des certificats TLS vérifiés via DNSSEC pour empêcher les attaques de type "man-in-the-middle". Alors que TLS-RPT surveille les défaillances TLS, DANE garantit que seuls des certificats de confiance sont utilisés. Ce faisant, DANE empêche activement les attaquants de procéder à des dégradations TLS et à des attaques par usurpation de certificat, préservant ainsi l'intégrité des communications par courrier électronique.
Pourquoi avez-vous besoin de la déclaration SMTP TLS ?
Les propriétaires de domaines doivent rester informés des problèmes de distribution des courriels dus à des défaillances du cryptage TLS pour les courriels envoyés à partir d'un domaine compatible MTA-STS. Les rapports TLS permettent de fournir ces informations.
- Sécurité du courrier électronique: Mettre en évidence les risques liés aux communications par courrier électronique non cryptées (par exemple, interception, attaques de type "man-in-the-middle").
- Conformité: Mentionnez comment TLS-RPT aide les organisations à répondre aux exigences réglementaires en matière de protection des données.
- Délivrabilité: Expliquer comment TLS-RPT améliore la délivrabilité du courrier électronique en identifiant et en résolvant les problèmes de cryptage.
Étapes de la mise en place de TLS-RPT
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
Étape 1 : Générer un enregistrement TLS-RPT (à l'aide d'un générateur d'enregistrement TLS-RPT)
Vous pouvez vous inscrire sur PowerDMARC gratuitement et utiliser notre générateur d'enregistrement TLS-RPT pour créer votre enregistrement.
Étape 2 : Saisissez votre adresse électronique de notification
Saisissez une adresse électronique à laquelle vous souhaitez recevoir vos rapports SMTP TLS.
Étape 3 : Publier l'enregistrement TLS dans votre DNS
Vous pouvez contacter votre registraire de domaine pour créer un nouvel enregistrement TXT pour TLS-RPT. Si vous gérez votre propre DNS, modifiez vos paramètres DNS pour inclure l'enregistrement.
Syntaxe et exemple d'enregistrement TLS-RPT
Syntaxe : v=TLSRPTv1 ; rua=mailto:[email protected] ;
Décortiquons les deux composantes de l'enregistrement de rapport TLS fourni :
- v=TLSRPTv1 : Cette balise indique la version du protocole TLS-RPT utilisée. Dans ce cas, "TLSRPTv1" indique la première version du protocole.
- rua=mailto:[email protected] : rua signifie "Reporting URI(s) for Aggregate Data". Cette balise indique où le serveur de messagerie du destinataire doit envoyer les rapports TLS agrégés.
Vous pouvez configurer plusieurs destinations pour la réception de vos rapports. Pour plusieurs destinations, séparez chaque entrée par une virgule (,). Vous pouvez soit utiliser "mailto :" pour spécifier une adresse électronique pour cette étape, soit demander au MTA de soumettre les rapports via POST à des URL de point final en utilisant "https :" dans le champ rua=. Si vous utilisez "https :" assurez-vous que le champ définit l'URL d'un serveur web compatible HTTPS avec un certificat valide. Les champs "mailto :" et "https :" peuvent également être utilisés dans un seul enregistrement, séparés par une virgule.
Exemple : v=TLSRPTv1 ; rua=mailto:[email protected],https://tlsreport.example.com ;
Remarque : En pratique, vous remplacerez "votredomaine.com" par le nom du domaine dans lequel vous souhaitez recevoir ces rapports.
Comprendre les rapports JSON de TLS-RPT
Structure d'un rapport JSON TLS-RPT
Les rapports TLS sont envoyés au format JSON. Vous trouverez ci-dessous un exemple de rapport TLS JSON :
{
"organization-name" : "Organization Inc.",
“date-range”: {
"start-datetime" : “2020-10-22T00:00:00Z”,
"end-datetime" : “2020-10-22T23:59:59Z”
},
"contact-info" : "[email protected]",
"report-id" : “2020-10-22T00:00:00Z_domain.com”,
"politiques" : [
{
“policy”: {
"policy-type" : "sts",
"policy-string" : [
"version : STSv1",
"mode : testing",
"mx : mx.domain.com",
"mx : mx2.domain.com",
"mx : mx3.domain.com",
"max_age : 604800"
],
"policy-domain" : "domain.com"
},
“summary”: {
"total-successful-session-count" : 15,
"total-failure-session-count" : 0
}
Champs clés et leur signification
Voici la répartition des principaux champs de ce rapport JSON TLS :
| Domaines | Description |
|---|---|
| l'organisation | L'organisation du domaine qui possède l'enregistrement TLS-RPT. |
| courriel | 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 |
| chaîne_politique | Spécifie la chaîne de politique associée à la politique |
| mode | Spécifie le mode de la politique MTA-STS (Enforce/Testing) |
| résumé | Contient des informations sommaires 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 | Nombre total d'échecs de sessions TLS. |
| failure_details | Un tableau d'objets qui fournissent des détails sur des échecs spécifiques. |
| raison | Chaîne de caractères indiquant la raison de l'échec (par exemple, "certificate_expired"). |
| compter | Le nombre de sessions qui ont échoué pour une raison spécifique. |
Format de rapport TLS-RPT JSON et interprétation des données
Métadonnées du rapport
{
"organization-name" : "Sending MTA Organization",
“date-range”: {
"start-datetime" : “2025-02-25T00:00:00Z”,
"end-datetime" : “2025-02-25T23:59:59Z”
},
"report-id" : “unique-report-id-12345”
}
Cette section de votre rapport JSON contient des informations de base telles que le nom de l'organisation de l'expéditeur du courrier électronique, la date et l'heure de début, la date et l'heure de fin et l'identifiant unique du rapport TLS généré.
Détails de la politique
“policy”: {
"policy-type" : "sts",
"policy-string" : "mode : enforce ; mx : mail.example.com ; max_age : 604800 ;"
}
Cette section décrit le mode de politique MTA-STS mis en œuvre, qui dans ce cas est le mode Enforce, mais qui peut également être configuré en mode Testing.
Détails de l'échec
"failure-details" : [
{
"result-type" : "certificate-expired",
"sending-mta" : "smtp.example.org",
"receiving-mta" : "mail.example.com",
"failure-reason" : "TLS handshake failed due to expired certificate" (échec de la poignée de main TLS en raison d'un certificat expiré)
}
]
Cette section est la partie la plus cruciale de votre rapport TLS, car elle détaille les raisons du chiffrement et des échecs potentiels de livraison. Dans ce cas, l'exemple indique qu'un certificat expiré est à l'origine de l'échec de la poignée de main TLS. Cela joue un rôle important dans la détection des erreurs lors d'échecs de la poignée de main TLS et favorise un dépannage rapide des communications TLS sécurisées.
Raisons de l'échec du chiffrement TLS et dépannage
Les échecs du chiffrement TLS peuvent avoir plusieurs causes. Outre l'absence de prise en charge du cryptage d'un côté ou de l'autre, des raisons plus sinistres telles qu'une attaque de déclassement SMTP peuvent entraîner l'échec de la connexion TLS. Mais les propriétaires de domaines voudraient être informés de l'échec de la livraison. Le rapport TLS (TLS-RPT) est un protocole qui vous informe. En cas d'échec de livraison, vous recevrez votre rapport TLS au format JSON à l'adresse électronique définie dans votre enregistrement TLS-RPT. Vous trouverez ci-dessous quelques raisons courantes des échecs de chiffrement et des conseils de dépannage :
1. Questions relatives aux certificats
certificat_expiré
Le certificat présenté par le serveur distant a dépassé sa date d'expiration. Il n'est donc pas digne de confiance pour le cryptage. Dans ce cas, vous devez renouveler votre certificat.
certificat_non_valide_encore
Le certificat présenté par le serveur distant n'est pas encore valide. Cela peut être dû à une heure de serveur incorrecte ou à une utilisation prématurée du certificat. Dans ce cas, il est préférable de contacter votre fournisseur de certificats.
certificat_révoqué
Le certificat présenté par le serveur distant a été révoqué par l'autorité de certification pour des raisons de sécurité. Dans ce cas, il est préférable de contacter votre fournisseur de certificats.
pas de signature valide
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é. Dans ce cas, il est préférable de contacter votre fournisseur de certificats.
certificat non pris en charge
Le certificat présenté par le serveur distant utilise des algorithmes de cryptage ou des longueurs de clé 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. Dans ce cas, il est préférable de contacter votre fournisseur de certificats.
2. 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. Cela indique une possible attaque de type "man-in-the-middle" ou un problème de configuration.
Vous pouvez vérifier les enregistrements MX dans votre fichier de stratégie MTA-STS pour vous assurer qu'ils correspondent à l'enregistrement MX du domaine.
3. 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 d'établissement de la liaison TLS entre le serveur de messagerie de l'expéditeur et le serveur de messagerie du destinataire, ce qui a empêché l'établissement du canal sécurisé. Vérifiez à nouveau que la connexion SMTP STARTTLS a été établie. Plusieurs raisons peuvent être à l'origine des échecs de chiffrement, comme l'absence de prise en charge de STARTTLS ou une attaque de rétrogradation TLS.
4. Questions de politique 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 stratégie MTA-STS pour le domaine du destinataire. Vérifiez votre fichier de stratégie MTA-STS. Vous devez vérifier votre enregistrement MTA-STS pour vous assurer qu'il a été publié correctement.
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 ne respecte pas la spécification MTA-STS. Vérifiez votre fichier de stratégie MTA-STS. Spécifiez un mode de stratégie MTA-STS approprié. Il peut s'agir de None, Enforce ou Testing. Ce mode indique aux serveurs d'envoi comment traiter les courriers électroniques dont la validation de la stratégie MTA-STS a échoué.
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 stratégie MTA-STS à partir des enregistrements DNS du domaine du destinataire. Vous devez valider les enregistrements MTA-STS dans votre DNS pour vous assurer que la syntaxe de l'enregistrement est correcte.
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. Vous devez vérifier la validité de votre certificat et vous assurer qu'il est conforme à la norme TLS la plus récente.
mta_sts_invalid_hostname
Cet échec se produit lorsque le nom d'hôte du serveur de messagerie du destinataire, tel qu'il est spécifié dans la stratégie MTA-STS, ne correspond pas au nom d'hôte réel du serveur. Vous devez vérifier les enregistrements MX dans votre fichier de stratégie MTA-STS pour vous assurer qu'ils correspondent à l'enregistrement MX du domaine.
Bonnes pratiques pour la mise en œuvre de TLS-RPT
Contrôler régulièrement les rapports TLS
Les rapports TLS doivent être contrôlés régulièrement pour s'assurer que vous ne manquez pas de messages non délivrés. Vous pouvez le faire en surveillant manuellement votre boîte aux lettres pour les rapports JSON ou en utilisant un outil d'analyse de rapports comme PowerTLS-RPT.
S'assurer que la politique MTA-STS est correctement configurée
Pour garantir une mise en œuvre correcte de TLS-RPT, votre politique MTA-STS doit être configurée correctement et ne pas comporter d'erreurs de syntaxe. Vous pouvez vérifier votre enregistrement à l'aide de notre vérificateur MTA-STS pour cette étape.
Remédier rapidement aux défaillances de chiffrement
Lorsque vous détectez des défaillances de chiffrement dans votre rapport TLS, il est important de prendre rapidement des mesures pour éviter les problèmes de délivrabilité des courriels à l'avenir.
Utiliser des versions sécurisées du protocole TLS
Il est essentiel de n'utiliser que les versions les plus récentes et prises en charge du protocole TLS pour éviter les échecs de chiffrement indésirables.
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
Vos rapports TLS-RPT JSON complexes 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 et met en évidence le problème auquel vous êtes confronté afin que vous puissiez le résoudre sans perdre de temps.
Il n'y a pas une chose que j'aime dans la plateforme PowerDMARC, ils ont une présentation facile à utiliser et à comprendre avec ce que j'appellerais des fonctionnalités complètes permettant un contrôle DMARC hébergé, l'aplatissement duSPF la possibilité d'étendre facilement les inclusions SPF pour inspecter les spécificités de l'enregistrement et même le support complet de MTA-STS et TLS-RPT !
Dylan B (Propriétaire de l'entreprise)
Questions fréquemment posées sur la sécurité de la couche transport
- Que signifie TLS ?
TLS est l'abréviation de Transport Layer Security.
- Qui délivre les certificats TLS ?
Les autorités de certification (AC) peuvent émettre des certificats TLS. Le processus de délivrance du certificat comprend la vérification de l'identité du détenteur du certificat. Une fois l'identification réussie, le certificat est délivré.
- Pourquoi ai-je besoin d'un certificat TLS ?
Les certificats TLS jouent un rôle essentiel dans la sécurisation des communications sur l'internet. Ils permettent de crypter les informations sensibles échangées entre des serveurs web communicants. Parmi les utilisations les plus courantes, on peut citer la sécurisation des communications par courrier électronique et le protocole HTTPS.
- Quelle est la norme TLS actuelle ?
TLS 1.3 est la dernière version de Transport Layer Security. TLS-RPT peut être mis en œuvre en utilisant n'importe quelle version de TLS. Il peut s'agir d'anciennes versions du protocole ou de versions futures. La version est généralement déterminée par des critères tels que les capacités des serveurs communicants.
Ressources complémentaires
Expert en sécurité des domaines et des courriels chez PowerDMARC
Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.
Derniers messages de Yunes Tarada (voir tous)
