SMTP : la « killer app » de DNSSEC

DNSSEC assure l’intégrité cryptographique des enregistrements DNS. Sa faible adoption peut s’expliquer par une complexité à l’implémentation et lors de sa maintenance, et par le fait que cette technologie est inutile, la plupart du temps. En effet, le DNS est principalement utilisé pour la résolution de noms de domaine en adresses IP, en vue d’accéder à un service tiers. Si ce service est authentifié et protégé en confidentialité et en intégrité, comme c’est le cas avec TLS, alors l’attaque active est contrée au moment de l’établissement de cette communication sécurisée. À l’inverse, protéger en intégrité le DNS alors que le service contacté n’est pas lui-même authentifié semble au mieux inutile : l’attaquant actif pourra généralement attaquer le service directement.

SMTP, le protocole d’échange de courriers électroniques se trouve, hélas, dans le second cas de figure, bien que la plupart des implémentations prennent en charge TLS. En effet, pour des raisons historiques et de déploiements progressifs transparents, les serveurs de courriers électroniques ne vérifient pas ou mal les certificats X.509 fournis dans le cadre de SMTP sur TLS. Ainsi, les communications entre serveurs de courriers électroniques ne bénéficient généralement que d’une protection contre les écoutes passives ; un attaquant actif pourra effectuer une interception aisément, sans même avoir à fournir un certificat frauduleux usurpant l’identité de la victime.

Les attaques actives ne se limitent cependant pas au protocole SMTP, mais s’étendent à son écosystème. En effet, les serveurs de courriers emploient de nombreuses techniques pour éviter l’usurpation d’identité de l’expéditeur d’un courrier électronique, dont des politiques de sécurité publiées dans le DNS.

Cet article expose l’impossibilité de sécuriser les échanges SMTP en l’absence d’intégrité cryptographique des enregistrements DNS, que ce soit pour récupérer les politiques de sécurité évoquées ci-dessus, ou pour effectuer une vérification de certificats efficace.

1. État des lieux

Cette section dresse un état des lieux du déploiement des technologies utilisées dans l’écosystème SMTP et qui peuvent être sécurisées grâce à DNSSEC. Des mesures actives ont été effectuées par l’auteur de cet article en vue de présenter au lecteur une image dénombrée. L’outil de mesures, la méthodologie, ainsi que les résultats bruts peuvent être consultés en ligne [collect].

1.1 TLS pour SMTP

Dans le précédent numéro de MISC, Arthur Provost et Olivier Levillain présentaient les résultats de mesures actives sur les serveurs SMTP afin d’évaluer la qualité des déploiements de TLS. Leur étude permet d’obtenir une estimation intéressante de la sensibilisation des administrateurs de serveurs de courriers électroniques aux bonnes pratiques de sécurité. Elle ne permet, cependant, pas d’évaluer la quantité de courriers électroniques ainsi protégés, car elle comptabilise les serveurs et non les messages envoyés entre ces serveurs. Or, le trafic des courriers électroniques est extrêmement concentré sur quelques plateformes d’hébergement mutualisé [ObsANSSI].

Cette concentration implique que la sécurisation de quelques acteurs permet de protéger un grand pourcentage des communications. Ainsi, plusieurs initiatives nationales et internationales ont été lancées, afin d’encourager l’adoption de TLS pour sécuriser les échanges entre les grands fournisseurs de service de transport de courriers électroniques, au nombre desquelles celle de Google, de l’ANSSI ou encore du BSI, l’agence nationale de sécurité des systèmes d’information allemande.

À ce titre, Google publie des statistiques publiques sur l’utilisation de TLS entre ses serveurs SMTP et les serveurs SMTP des organismes avec lesquels ils échangent [SaferEmail]. Il y est notamment possible d’observer le pourcentage de courriers envoyés sur un canal chiffré, par domaine expéditeur/destinataire.

L’ANSSI a également rédigé une charte [Charte], en collaboration avec plusieurs fournisseurs de service français, afin d’ériger des engagements de sécurité minimaux devant être mis en œuvre par les signataires (Orange, SFR/Numéricable, Bouygues Télécom, Free et La Poste).

Finalement, le BSI a publié un document [BSI] fournissant des recommandations de sécurité pour les fournisseurs de service de courriers électroniques allemand s’étant autosaisis de la problématique. Il est intéressant de noter que le BSI encourage l’emploi de DNSSEC dans son document.

1.2 DNSSEC

L’auteur de cet article décrivait dans ces mêmes colonnes, en 2012, trois mécanismes employant DNSSEC afin de venir au secours de la validation des certificats X.509 : DNS-based Authentication of Named Entities (DANE) [RFC6698], Certification Authority Authorization (CAA) [RFC6844] et un mécanisme non standard d’épinglage des certificats par l’entremise de DNSSEC. Six ans plus tard, force est de constater que ces mécanismes sont peu implémentés [EtudeCAA, EtudeDANE]. Et pour cause : DNSSEC peine à se généraliser, avec un taux d’adoption autour de 12,5% des noms de domaine se terminant en « .fr. », dont la majorité sont signés automatiquement par les bureaux d’enregistrement dans le cadre de la création de nouveaux noms de domaine [ObsANSSI].

Du côté des autorités de certification, la prise en charge de DNSSEC n’est pas obligatoire, même pour les autorités de certification émettant des certificats où seul le contrôle temporaire d’un nom de domaine est validé (certificats dits « DV », pour « Domain Validation »). En fait, la seule mention de DNSSEC dans les prérequis minimaux édictés par le CA/B Forum – une entité réunissant les autorités de certification et les principaux navigateurs web – a trait au comportement à adopter dans le cas d’un échec de vérification d’une signature DNSSEC dans le cadre de CAA [CABForumBR].

Certaines autorités de certification, comme Let’s Encrypt, implémentent cependant la validation DNSSEC de leur propre chef pour l’émission de certificats DV ; un fait à porter à leur crédit.

1.3 SPF

Sender Policy Framework (SPF) [RFC7208] est une politique de sécurité permettant à un émetteur de courriers électroniques de spécifier la liste des serveurs/adresses IP autorisés à envoyer des courriers provenant de son nom de domaine. Cette politique est publiée sous la forme d’un enregistrement DNS de type TXT à l’apex (c’est-à-dire « tout en haut ») de la zone DNS correspondant au domaine DNS expéditeur à protéger. Par exemple, pour l’expéditeur john@example.com, l’enregistrement SPF suivant sera consulté :

Cette donnée est directement consommée par un validateur SPF et aucun autre mécanisme de sécurité n’intervient ultérieurement pour la protéger, comme c’est le cas avec TLS pour les courriers électroniques. Les enregistrements SPF mériteraient donc d’être protégés en intégrité grâce à DNSSEC. La RFC7208 n’oblige cependant pas la signature ou la validation cryptographique de cet enregistrement DNS, permettant ainsi à un attaquant actif de modifier cet enregistrement à la volée et autoriser des adresses IP sous son contrôle à émettre des courriers.

Le déploiement de SPF pour les domaines délégués depuis le nom de domaine de premier niveau (en anglais, Top-Level Domain ou TLD) « .fr » est d’environ 37%. Cependant, seuls 7,4% des zones étudiées contiennent des enregistrements SPF signés avec DNSSEC.

1.4 DKIM

DomainKeys Identified Mail (DKIM) Signatures [RFC6376] est une politique de sécurité permettant à un émetteur de courriers électroniques de signer cryptographiquement certains en-têtes et tout ou partie du contenu des courriers provenant de son domaine. Cette technologie vise ainsi à prévenir l’usurpation d’identité de l’expéditeur et permet la détection en cas d’altération des courriers pendant leur transit.

La signature DKIM est placée dans les en-têtes d’un courrier électronique. En voici un exemple :

La clé publique utilisée pour effectuer la vérification de cette signature est publiée dans le DNS, dans un enregistrement TXT. Cet enregistrement est publié dans un nom de domaine composé du domaine spécifié dans la métadonnée d= de la signature, préfixée de la chaîne constante _domainkey, elle-même préfixée d’un sélecteur (une chaîne de caractères arbitraire, spécifiée dans la métadonnée s= de la signature). Ainsi pour la signature donnée en exemple ci-dessus, l’enregistrement DNS suivant est récupéré :

Bien que la RFC6376 ne requière pas l’authentification cryptographique de la clé publique servant à vérifier la signature des courriers électroniques, DNSSEC permet de « certifier » cette clé, la protégeant ainsi d’attaquants actifs.

Le déploiement de DKIM ne peut être mesuré avec précision, les sélecteurs étant imprédictibles par l’outil de mesure. Il est cependant possible d’inférer l’absence d’enregistrements relatifs à DKIM grâce à la RFC8020 [RFC8020]. Celle-ci dicte que le DNS est une base de données arborescente, et donc qu’un domaine ne peut exister que si tous les domaines parents existent aussi. Ainsi, il est possible de déterminer un pourcentage de domaines n’utilisant pas DKIM, en comptant les domaines pour lesquels le sous-domaine _domainkey n’existe pas. Les autres domaines utilisent peut-être DKIM ou sont des faux positifs.

Pour les domaines délégués depuis le TLD « .fr », 81% des domaines n’emploient pas DKIM. Seul 1% des domaines étudiés sont susceptibles d’utiliser DKIM et sont signés avec DNSSEC. Ces 1% constituent la borne haute du nombre de noms de domaine utilisant DKIM avec une protection contre les attaquants actifs.

1.5 DMARC

Domain-based Message Authentication, Reporting and Conformance (DMARC) [RFC7489] est une politique de sécurité publiée dans le DNS, permettant de spécifier des actions à prendre en cas de violation des politiques SPF et DKIM. Cette politique est publiée dans un enregistrement TXT localisé dans le sous-domaine _dmarc du domaine de l’expéditeur d’un courrier, dont voici un exemple :

Des exemples d’actions à prendre en cas de violation de SPF et DKIM incluent de défausser les courriers jugés frauduleux, de les mettre en quarantaine, et éventuellement de rapporter cet échec auprès d’un serveur. De manière cruciale, ces rapports peuvent contenir des extraits de courriers électroniques. Pour un domaine n’étant pas protégé par DNSSEC, un attaquant est donc en mesure de modifier les enregistrements DKIM, de façon à faire passer un courrier électronique pour frauduleux, puis de retourner un faux enregistrement DMARC permettant l’exfiltration d’informations du courrier.

Le déploiement de DMARC est très faible, avec seulement 1,4% des noms de domaine délégués depuis le TLD « .fr » l’implémentant. Seuls les enregistrements de 1,5 domaine pour mille sont, en outre, protégés par DNSSEC. Finalement, comme noté dans la section 1.2, seuls 12,5% des domaines étudiés sont signés avec DNSSEC et sont donc à l’abri de toute attaque active impliquant DMARC en vue d’exfiltrer le contenu des courriers électroniques.

2. Modélisation d’un attaquant actif

Dans cette section, nous allons exposer une liste non exhaustive des possibilités d’un attaquant actif à l’encontre de SMTP sur TLS, en vue de casser la confidentialité des métadonnées ou des échanges en général.

2.1 Négociation TLS

Certains protocoles, comme IMAP ou POP disposent d’un mode d’usage de TLS dit « implicite ». Cela signifie que la version sécurisée de ces protocoles dispose d’un numéro de port TCP spécifique (IMAPS/993, POPS/995), et que lorsqu’un serveur est contacté sur ce port, TLS doit être employé dès les premiers segments échangés sur une nouvelle connexion TCP. La version TLS implicite de SMTP, appelée SMTPS et employant le port 465, a hélas été supprimée des registres de l’IANA, et le port 465 a été réalloué pour d’autres usages. SMTPS n’existe donc plus.

Certains protocoles disposant de TLS implicite existent également dans une version dite « explicite ». Dans ce cas, la connexion TCP est effectuée sur les ports « en clair » (IMAP/143, POP/110). C’est alors à la couche applicative (IMAP, POP), d’exprimer dans son dialecte qu’une amélioration de la sécurité de la communication est désirée. Cela s’exprime généralement par l’affichage d’une option STARTTLS par le serveur, et que le client est libre de solliciter en envoyant le message STARTTLS. Lorsque le client sollicite l’usage de TLS proposé par le serveur, les échanges en clair sont interrompus et la même connexion TCP est subitement employée pour échanger des messages TLS en vue de négocier des clés, puis de transférer du trafic chiffré. L’extrait de session SMTP ci-dessous illustre une négociation de STARTTLS. Les lignes préfixées par S: sont envoyées par le serveur, et celles par C: par le client.

L’avantage de l’emploi de TLS de façon implicite est que si la connexion TCP/TLS est ouverte avec succès, il n’y a aucun doute sur le fait que les messages transférés sont protégés. Avec TLS en mode explicite, la même assurance ne peut être fournie. Certains clients codés « un peu rapidement » poursuivent, en effet, l’envoi du courrier en clair, sans noter les erreurs renvoyées par les serveurs ne souhaitant pas recevoir en l’absence de TLS.

En outre, l’indication que le serveur prend en charge TLS et la sollicitation de chiffrement du client sont échangées en clair. Un attaquant actif est donc en mesure de corrompre le trafic afin de dissimuler/supprimer l’option/la sollicitation, afin que la négociation TLS ne soit pas effectuée. Cette attaque porte le nom de STARTTLS Stripping. Ce risque n’est pas théorique ; dans un excellent papier de Google, l’université du Michigan et l’université de l’Illinois [RainSnowMitm], des chercheurs ont effectué une étude des connexions SMTP vers les serveurs de Gmail. Ils ont ainsi découvert qu’une grande quantité des connexions SMTP avec TLS explicite à destination de Gmail était altérée par des attaquants actifs. Dans certains pays, comme la Tunisie, jusqu’à 96% des connexions sont affectées par un attaquant, tandis que 9% des connexions sont affectées en France, et plus particulièrement à l’île de la Réunion.

Le mode opératoire de l’attaquant est de remplacer à la volée dans la connexion TCP l’option du serveur ou la sollicitation du client par une chaîne de même longueur que STARTTLS, non reconnue par l’autre partie, comme XXXXXXXX. En conséquence, le client ne verra pas l’option STARTTLS, mais une option XXXXXXXX qu’il ne sait pas utiliser, ou le serveur recevra une commande XXXXXXXX du client, à laquelle il répondra avec un message d’erreur indiquant qu’il s’agit d’une commande invalide.

Finalement, la validation des certificats TLS dans le cadre de SMTP est très en retard par rapport à celle de HTTPS. Par exemple, dans l’étude [RainSnowMITM], environ 66% des certificats présentés par les serveurs SMTP sont invalides (mauvais sujet, principalement, mais aussi certificats périmés ou autosignés).

Le chiffrement est dit « opportuniste » lorsque les serveurs SMTP acceptent aveuglément tout certificat présenté. C’est le cas de la plupart des déploiements de SMTP sur l’Internet. De plus, au moment où ces lignes sont écrites, aucune implémentation de SMTP sur TLS connue de l’auteur n’est compatible avec Certificate Transparency. Comparativement, pour le web, tout certificat émis à partir d’avril 2018 et n’étant pas dans Certificate Transparency est jugé invalide par le navigateur Chrome.

2.2 Remplacement des enregistrements MX

Lorsqu’un serveur SMTP cherche à envoyer un courrier électronique à un tiers inconnu, la recherche du serveur SMTP à contacter s’effectue grâce au DNS. Pour cela, une recherche d’enregistrement de type MX (pour Mail eXchanger, ou relais de courriers, en français) est initiée. Ces enregistrements contiennent les noms des serveurs SMTP à contacter, noms qui doivent ensuite être résolus en adresse IP. Voici un exemple d’enregistrements MX :

Dans le même papier [RainSnowMITM], les chercheurs ont également évalué la propension des attaquants à remplacer les enregistrements MX légitimes par des enregistrements MX contenant des noms de domaine sous son contrôle. Ce faisant, le serveur expéditeur enverra le courrier directement aux serveurs de l’attaquant, qui pourra prendre connaissance du contenu. L’attaquant peut, ensuite, éventuellement faire suivre le courrier aux vrais serveurs destinataires afin de rendre « transparente » l’attaque, en l’absence d’une politique SPF sur le domaine expéditeur. En présence de SPF, l’attaquant peut émuler un problème serveur, à la suite de la réception du contenu du courrier, par exemple, en renvoyant une erreur temporaire, indiquant un espace de stockage insuffisant (erreur 452). Le serveur expéditeur original réessaiera alors de transmettre ultérieurement le courrier, cette fois-ci au serveur destinataire légitime, qui saura valider la légitimité de l’expéditeur avec SPF.

Les auteurs de [RainSnowMITM] ont interrogés les serveurs DNS récursifs et les relais DNS (forwarders) souffrant d’un défaut de contrôle d’accès (serveurs appelés résolveurs DNS ouverts) afin de collecter des réponses DNS depuis de nombreux points d’observation de l’Internet. Le résultat de ces mesures actives a révélé que 2% des serveurs DNS interrogés renvoyaient une réponse frauduleuse pouvant mener au détournement de courriers électroniques.

Il convient de noter que cette attaque ne saurait être prévenue même si l’expéditeur exigeait l’utilisation de TLS avec des certificats X.509 valides (sujet, dates, usage, etc.) de la part du destinataire. En effet, l’hébergement mutualisé de plusieurs domaines sur un seul serveur SMTP de réception n’emploie pas l’extension TLS appelée Server Name Indication (SNI). À la place, c’est le nom du serveur SMTP fourni dans l’enregistrement MX qui est généralement recherché à l’intérieur du certificat présenté par le serveur SMTP destinataire. Or, si l’enregistrement MX n’est pas signé avec DNSSEC, celui-ci peut être modifié à la volée par un attaquant pour y mettre tout nom sous son contrôle et pour lequel il est en mesure d’obtenir un certificat valide et légitime.

L’emploi de SNI aurait permis à un expéditeur de préciser pendant la négociation TLS qu’il envoyait un courrier électronique à destination d’une adresse en @example.com. Le serveur de destination aurait alors pu fournir un certificat valide pour example.com.

Plusieurs explications existent pour justifier ce choix qui semble sous-optimal. En premier lieu, les serveurs SMTP réutilisent les connexions TCP/TLS ouvertes entre deux hôtes, afin de créer un pipeline. Cette réutilisation vise à éviter, lorsque c’est possible, le coûteux établissement d’une connexion TCP/TLS pour l’envoi d’un unique courrier. Il ne semblerait donc pas correct de réutiliser une connexion établie et authentifiée pour example.com pour l’envoi d’un courrier au nom de domaine cohébergé example.net. À la place, deux connexions indépendantes vers la même adresse IP devraient être employées ; un coût que tous les opérateurs ne souhaitent pas payer.

Ensuite, utiliser SNI présente le défaut de divulguer une partie des métadonnées (le nom du domaine du destinataire parmi les N domaines cohébergés) à un attaquant passif écoutant le réseau.

3. La contre-mesure : DNSSEC et DANE

Comme vu dans les précédentes sections de cet article, DNSSEC fournit une aide contre les attaquants actifs. Notamment, les signatures cryptographiques des enregistrements DNS permettent d’assurer l’intégrité et l’authentification de la source des données des technologies SPF, DKIM et DMARC. En outre, une vérification effective des informations contenues dans les certificats TLS pourrait être effectuée puisque DNSSEC confirme l’authenticité des noms présents dans les enregistrements MX.

Un aspect « chiffrement opportuniste » demeure néanmoins, lors du signalement de la prise en charge de TLS par le client et le serveur, avec STARTTLS, comme expliqué dans la section 2.1 de cet article. Il est, bien sûr, possible de refuser de communiquer avec toute personne n’offrant pas TLS. L’attaquant qui corrompt la négociation de TLS ne pratique alors qu’un déni de service, puisque les deux parties refuseront de communiquer en l’absence de canal chiffré. Ce choix peut être raisonnable pour certains types d’infrastructures, d’interconnexions ou d’organismes. Sur l’Internet, et en particulier dans un réseau comme SMTP où toute partie peut écrire à un autre, une telle intransigeance n’est cependant pas réaliste. En conséquence, il est nécessaire de disposer d’un mécanisme de signalement de la prise en charge de TLS qui soit lui-même résistant aux attaquants actifs, largement déployable, et ce de manière incrémentale.

DNS remplit le cahier des charges, avec son rôle d’annuaire protégé en intégrité par DNSSEC. Il est ainsi possible de publier un enregistrement DNS indiquant que le serveur SMTP contacté prend en charge TLS ; cet enregistrement pourra alors être récupéré par un client SMTP, au moment où il demande les enregistrements MX.

La technologie DANE [RFC6698] permet d’effectuer ce signalement de la prise en charge de TLS par la simple présence d’un enregistrement DNS de type TLSA. Il convient de noter que la spécification requiert que l’enregistrement TLSA soit signé et vérifiable par DNSSEC, ce qui apporte la protection contre l’attaquant actif.

Cet enregistrement est situé dans un sous-domaine des noms de domaine contenus dans les enregistrements MX. Plus précisément, le nom du MX est préfixé de la chaîne _25._tcp.. Ainsi, le serveur smtp.gmail.com pourrait disposer d’un enregistrement TLSA comme celui-ci :

L’objectif de DANE dépasse celui du simple signalement de prise en charge de TLS, et permet notamment d’épingler le certificat ou la clé publique qui doivent être présentés par le serveur contacté. Pour cela, des outils comme [GenTLSA] permettent de générer l’enregistrement TLSA à partir d’un certificat. Il suffit alors de le publier dans la zone DNS appropriée et de signer cette dernière avec DNSSEC.

Côté serveurs SMTP expéditeurs, la configuration pour la prise en compte de DANE est un peu moins aisée, puisqu’il faut valider les réponses DNSSEC d’une part, et configurer le serveur pour demander les enregistrements DANE d’autre part. La validation DNSSEC en elle-même devrait être effectuée par un résolveur validant local (Unbound ou Knot-Resolver sont de bons choix). Ensuite, avec Postfix, l’administrateur doit indiquer dans son fichier de configuration main.cf les lignes suivantes :

Ces lignes indiquent à Postfix de se comporter comme suit : en présence d’un enregistrement TLSA validé, le serveur contacté doit prendre en charge TLS ; si un attaquant actif corrompt l’échange et que l’option STARTTLS n’est pas négociée, Postfix ne transmet pas le courrier électronique. En cas d’erreur de validation de l’enregistrement TLSA, ou d’absence de réponse du serveur, le même comportement conservatoire doit être adopté. Dans les cas où la réponse DNS n’est pas signée, ou si elle ne contient pas d’enregistrement TLSA, alors le chiffrement opportuniste est employé avec le serveur contacté. En conséquence, le mode dane de Postfix permet un déploiement progressif, offrant une sécurité contre les attaquants actifs si DANE est employé, et conservant le chiffrement opportuniste dans le cas contraire.

Conclusion

Dans cet article, nous avons étudié différentes menaces pouvant affecter les échanges de courriers électroniques, en présence d’un attaquant actif. La figure 1 rappelle ces dernières de manière synthétique.

Nous avons également observé l’effet positif que DNSSEC peut avoir pour améliorer la sécurité des échanges de courriers électroniques. Hélas, son faible taux de déploiement à ce jour, signifie que la plupart des courriers électroniques peuvent être et sont la proie d’attaques actives plus ou moins ciblées (comme le cas tunisien, évoqué en section 2.1 nous l’a montré).

Les utilisateurs souhaitant échanger de manière confidentielle sont encouragés à chiffrer le contenu de leurs courriers électroniques, en complément de la protection offerte, de manière opportuniste ou non, par TLS. Il existe pour cela plusieurs options, dont des moyens intégrés (comme S/MIME ou, dans une moindre mesure, OpenPGP), ou non (comme ceux listés dans le catalogue des produits certifiés par l’ANSSI). Dans le cas du chiffrement opportuniste, les métadonnées de ces échanges ne sont, cependant, protégées que contre les écoutes passives lors de leur transit sur le réseau. Les administrateurs de serveurs de courriers électroniques souhaitant offrir une sécurité adéquate à leurs utilisateurs contre les attaques actives devraient donc signer leurs zones DNS avec DNSSEC, publier des enregistrements TLSA, et configurer leurs serveurs pour utiliser DANE lorsqu’il est disponible.

Pour finir, publier des enregistrements SPF, DKIM et DMARC signés participe à lutter contre les usurpations d’identité. Il convient cependant d’exiger des signatures DNSSEC sur les enregistrements DMARC ou de désactiver l’envoi de rapports dans son validateur DMARC, lorsque la configuration logicielle le permet, afin d’éviter les exfiltrations de métadonnées sur les courriers électroniques.

Remerciements

Je tiens à remercier mes relecteurs, Baloo (@baloose), Olivier Levillain et Christophe Malinge, pour leurs remarques constructives qui ont significativement contribué à l’amélioration de cet article.

Merci également à Claudio Fiandrino pour son code TikZ pour topologies réseaux, publié en [CCBy].

Références

[collect] Outil de mesures DNS développé pour cet article : https://github.com/X-Cli/collectDNSSECEmailStats

[ObsANSSI] Observatoire de la résilience de l’Internet français : https://www.ssi.gouv.fr/observatoire

[SaferEmail] Site de Google pour la consultation de statistiques de SMTP sur TLS : https://transparencyreport.google.com/safer-email/overview

[Charte] Charte de l’ANSSI pour l’amélioration de la sécurité des échanges de courriers électroniques : https://www.ssi.gouv.fr/particulier/precautions-elementaires/charte-pour-la-securite-des-courriers-electroniques/

[BSI] Document équivalent au lien précédent, rédigé par l’homologue de l’ANSSI en Allemagne : http://www.project-consult.de/files/BSI_TR03108-1_Sichere_EMail.pdf

[RFC6698] The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol : TLSA https://tools.ietf.org/html/rfc6698

[RFC6844] DNS Certification Authority Authorization (CAA) Resource Record : https://tools.ietf.org/html/rfc6844

[EtudeCAA] CAA Study : https://caastudy.github.io/

[EtudeDANE] Measuring DANE TLSA Deployment : https://www.isi.edu/~liangzhu/presentation/dns-oarc/dane_tlsa_survey.pdf

[CABForumBR] Baseline Requirements Documents : https://cabforum.org/baseline-requirements-documents/

[RFC7208] Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 : https://tools.ietf.org/html/rfc7208

[RFC6376] DomainKeys Identified Mail (DKIM) Signatures : https://tools.ietf.org/html/rfc6376

[RFC8020] NXDOMAIN : There Really Is Nothing Underneath : https://tools.ietf.org/html/rfc8020

[RFC7489] Domain-based Message Authentication, Reporting, and Conformance (DMARC) : https://tools.ietf.org/html/rfc7489

[RainSnowMitm] Neither Snow Nor Rain Nor MITM… An Empirical Analysis of Email Delivery Security : https://static.googleusercontent.com/media/research.google.com/fr//pubs/archive/43962.pdf

[CCBy] Attribution 2.5 Generic : https://creativecommons.org/licenses/by/2.5/