fmaury/Broken-by-Design
1
0
Fork 0
Code Pull requests Releases Activity Actions

Add SMTP article

Browse source
This commit is contained in:
Florian Maury 2022-05-28 14:31:58 +02:00
parent 82d8234568
commit 486a82ca03
No known key found for this signature in database
2 changed files with 542 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

542
posts/smtp-killer-app/index.md Normal file
View file

@ -0,0 +1,542 @@
---
title: "SMTP : la « killer app » de DNSSEC"
slug: smtp-killer-app-dnssec
author: "Florian Maury"
date: 2018-05-01
type: posts
lang: fr
categories:
- internet
tags:
- security
- smtp
- dns
- dnssec
---
Huit ans après le déploiement de DNSSEC par la racine du DNS, cette technologie
peine encore à trouver son public et à prouver son utilité. Cet article démontre
que la sécurité des échanges de courriers électroniques avec SMTP contre des
attaquants actifs ne peut être atteinte en l’absence de DNSSEC, compte tenu des
standards et implémentations actuels.
<!--more-->
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.
# É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].
## 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.
## 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 : {{< abbr DANE "DNS-based Authentication of Named Entities"
>}} [^RFC6698], {{< abbr CAA "Certification Authority Authorization" >}}
[^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.
## SPF
{{< abbr SPF "Sender Policy Framework" >}} [^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é :
```
example.com. 86400 IN TXT “v=spf1 ip4:192.0.2.1 -all”
```
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, {{< abbr TLD "Top-Level Domain" >}}) « .fr » est
d’environ 37%. Cependant, seuls 7,4% des zones étudiées contiennent des
enregistrements SPF signés avec DNSSEC.
## DKIM
{{< abbr DKIM "DomainKeys Identified Mail" >}} 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 :
```
DKIM-Signature: d=example.net; s=chaine_arbitraire; …
```
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é :
```
chaine_arbitraire._domainkey.example.net. 86400 IN TXT “v=DKIM1; k=rsa; p=base64clef”
```
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.
## DMARC
{{< abbr DMARC "Domain-based Message Authentication, Reporting and Conformance"
>}} [^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 :
```
_dmarc.example.net. 86400 IN TXT “v=DMARC1; p=none; pct=100; ruf=mailto:dmarc-feedback@example.com"
```
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.
# 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.
## 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.
```
S: 220 smtp.gmail.com ESMTP 186sm7907497wmm.32 - gsmtp
C: EHLO x-cli.eu
S: 250-smtp.gmail.com at your service, [2001:41d0:51:1::716]
S: 250-SIZE 35882577
S: 250-8BITMIME
S: 250-STARTTLS
S: 250-ENHANCEDSTATUSCODES
S: 250-PIPELINING
S: 250-CHUNKING
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
```
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.
---
Certificate Transparency est une technologie et un écosystème qui permettent au titulaire d’un nom de domaine de lister les certificats émis pour son nom de domaine, et d’ainsi vérifier qu’ils ont tous été émis avec son accord. Certificate Transparency a été présenté dans MISC Hors-Série n°13, article « Souriez ! Les autorités de certification sont filmées ! ».
---
## 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 :
```
example.com. 86400 IN MX 5 mail1.example.com.
example.com. 86400 IN MX 10 smtp.example.net.
```
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 {{< abbr "SNI" "Server Name Indication" >}}. À 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.
---
SNI permet de spécifier lors de l’initialisation de la connexion TLS, un nom de domaine spécifique parmi plusieurs domaines cohébergés sur la même machine ; c’est ainsi que l’on peut avoir plusieurs hôtes virtuels (*Virtual Host*) sur une même adresse IP servant du HTTPS.
---
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.
# 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 :
```
_25._tcp.smtp.gmail.com. IN TLSA 3 1 1 Base64DuCertificatOuDeLaClefPublique
```
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 :
```
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
```
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.
![Synthèse des menaces étudiées dans cet article](./schema_smtp.jpg "Fig. 1 : Synthèse des menaces étudiées dans cet article pouvant affecter les échanges de courriers électroniques. Les flux en rouge sont créés ou modifiés par l’attaquant.")
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/
Publié par les [Editions Diamond](https://connect.ed-diamond.com/MISC/misc-097/smtp-la-killer-app-de-dnssec) sous licence [CC-BY-NC-ND](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.fr).

BIN
posts/smtp-killer-app/schema_smtp.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 363 KiB