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.

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. Toutefois, 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 . Voyons comment ces protocoles fonctionnent ensemble pour renforcer la sécurité du courrier électronique.

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é.

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.

Les échecs du chiffrement TLS peuvent avoir plusieurs causes. Outre l'absence de prise en charge du chiffrement 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 d'une connexion TLS. Lorsque MTA-STS est activé, les attaquants ne parviennent pas à transmettre des messages en texte clair en cas d'échec de la connexion.

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 en informera. En cas d'échec de livraison, vous recevrez votre rapport TLS au format JSON à l'adresse électronique définie dans votre enregistrement TLS-RPT.

Pourquoi avez-vous besoin de la déclaration SMTP TLS ?

Les propriétaires de domaines doivent se tenir au courant de l'évolution de l'email d

Les problèmes de livraison 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. TLS-RPT

Pour recevoir des rapports de retour d'information qui mettent en évidence votre type de police et votre type d'assurance.
Pour identifier la raison des échecs du cryptage TLS
Gagner en visibilité sur les canaux de courrier électronique
Pour résoudre les problèmes de livraison

É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 : Sélectionner un outil de génération d'enregistrements 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.

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 "maito :" 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 : Dans la pratique, vous remplacerez "votredomaine.com" par le nom du domaine dans lequel vous souhaitez recevoir ces rapports.

Format de rapport TLS

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

}

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.

Raisons et types d'échec du chiffrement TLS

Questions relatives aux certificats

Types de défaillance	Raisons	Suggestions de dépannage possibles
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.	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 incorrecte du serveur ou à une utilisation prématurée du certificat.	Contactez votre fournisseur de certificat.
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é.	Contactez votre fournisseur de certificat.
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é.	Contactez votre fournisseur de certificat.
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 toute connexion sécurisée.	Contactez votre fournisseur de certificat.

Mauvaise correspondance entre le nom d'hôte et l'identité

Type de défaillance	Raison	Suggestions de dépannage possibles
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.	Vérifiez les enregistrements MX dans votre fichier de stratégie MTA-STS pour vous assurer qu'ils correspondent à l'enregistrement MX du domaine.

Questions relatives à la poignée de main et au protocole

Types de défaillance	Raisons	Suggestions de dépannage possibles
échec de la poignée de main	Un problème s'est produit au cours du processus initial d'échange 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é.	Vérifiez que la connexion SMTP STARTTLS a bien été établie. Il peut y avoir plusieurs raisons qui contribuent aux échecs de cryptage, comme le manque de support pour STARTTLS, ou une attaque de rétrogradation TLS.

Questions politiques MTA-STS

Types de défaillance	Raisons	Suggestions de dépannage possibles
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.	Examinez votre fichier de stratégie MTA-STS. Vérifiez 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 n'adhère pas à la spécification MTA-STS.	Examinez votre fichier de stratégie MTA-STS. Spécifiez un mode de stratégie MTA-STS approprié. Il peut s'agir de None (Aucun), Enforce (Appliquer) ou Testing (Tester). Ce mode indique aux serveurs d'envoi comment traiter les courriers électroniques dont la validation de la politique MTA-STS a échoué. Pour en savoir plus sur les modes d'action, cliquez ici.
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.	Validez 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.	Vérifiez la validité de votre certificat, assurez-vous que le certificat est à jour avec la dernière norme 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 stratégie MTA-STS, ne correspond pas au nom d'hôte réel du serveur.	Vérifiez les enregistrements MX dans votre fichier de stratégie MTA-STS pour vous assurer qu'ils correspondent à l'enregistrement MX du domaine.

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 seule 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 le contrôle DMARC hébergé, l'aplatissement SPF, la possibilité d'étendre facilement les inclusions SPF pour inspecter les spécificités de l'enregistrement et même un support complet pour 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

1. Que signifie TLS ?

TLS est l'abréviation de Transport Layer Security.

2. 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é.

3. 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 les serveurs web qui communiquent entre eux. Parmi les utilisations les plus courantes, on peut citer la sécurisation des communications par courrier électronique et le protocole HTTPS.

4. 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.

Yunes Tarada

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)

Comment réparer 550 SPF Check Failed ? [SOLVED] - 7 janvier 2025
Vulnérabilités DNS : Les 5 principales menaces et les stratégies d'atténuation - 1er janvier 2025
Comment corriger l'erreur "La signature DKIM n'est pas valide" ? - 24 décembre 2024

Qu'est-ce que la déclaration SMTP TLS ?