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) est la pierre angulaire de la garantie de la confidentialité et de 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 signifie Transport Layer Security Reporting (rapport sur la sécurité de la couche transport). Il s'agit d'une norme permettant de signaler les problèmes de distribution des courriels qui surviennent lorsqu'un courriel 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:tlsrpt@yourdomain.com ;
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:tlsrpt@yourdomain.com : 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:tlsrpt@example.com,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" : "smtp-tls-reporting@organization.com",
"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.
Ressources complémentaires
