dit courrier électronique ? Le courrier électronique d'Internet repose sur deux piliers : ◦ RFC 5321 Simple Mail Transfer Protocol comme protocole d'échange des messages. ◦ RFC 5322 Internet Message Format qui spécifie le format des messages RFC 5321 gère l'enveloppe du mail pour son acheminement. RFC 5322 gère le contenu du mail qui peut être transporté par SMTP. Analogie de la poste ◦ La lettre avec son contenu suivant un format : courrier administrative ◦ L'enveloppe pour l'acheminement de la lettre à disposition. Email : nimportequoi@nimportequoi 4
? Pas du tout sûr Impossible d'authentifier l'expéditeur. Facilité de forger des emails (expéditeur) Facilité d'usurper des emails (expéditeur) Facilité d'usurper une adresse IP Facilité de porter atteinte au contenu du mail. ... 7
(1/2) Sender Policy Framework ou SPF (RFC 7208) est un standard ouvert permettant de prévenir l'usurpation de l'expéditeur. La version actuel (SPFv1) protège la partie expéditeur de l'enveloppe du courrier qui est utilisé pour le transport. SPF permet au propriétaire d'un domaine de définir dans un enregistrement DNS, ses règles (politique) d'envoi de courrier ; par exemple quel serveur est autorisé à envoyé du courrier pour ce domaine. 9
(2/2) SPF combine deux composantes : 1. Publication dans la zone de la politique dans une ressource de type SPF et TXT. 2. Vérification de la politique par le serveur mail de réception. $ dig +short txt arouna.net "v=spf1 mx:arouna.net include:websitewelcome.com a -all" $ dig +short txt client.isoceltelecom.net "v=spf1 a mx -all" $ dig +short txt uac.bj "v=spf1 mx a:tempest.info.ucl.ac.be ~all" $ dig +short txt otitelecom.com "v=spf1 mx a:zimbraserver.otitelecom.com ip4:41.74.9.234/30 -all" $ dig +short txt isoceltelecom.com "v=spf1 mx a:mail.isoceltelecom.com ptr:mail.isocelmail.com mx:mail.isoceltelecom.com mx:mx20.isoceltelecom.com a:mail.isocelmail.com include:mail.isocelmail.com mx:mail.isocelmail.com -all" → → $ dig +short txt moov.bj "v=spf1 ip4:41.191.70.130 ~all" "v=spf1 ip4:41.191.70.131 ~all" 10
Il est toujours possible ◦ De modifier le mail lors de son passage. ◦ D'usurper *l'adresse IP d'*un serveur de messagerie. DomainKeys Identified Mail (RFC 4871) déporte la signature de l'email du MUA au MTA. Derive du DomainKeys de Yahoo ! et du Cisco Identified Internet Mail. Permet à une organisation (au sens DNS du terme) d'assumer la responsabilité pour la transmission d'un message, d'une manière qui peut être vérifié par un destinataire. Fonctionne par signature cryptographique du corps du message et d'une partie de ses en-têtes. Transparent pour les utilisateurs. 11
(2/3) Valide l'émetteur et l'intégrité du message. End-to-end (échange directe entre serveurs) Source : 1. Publication dans la zone de la clé publique (se fait en une fois normalement) 2. Signature de certaines parties du mail avec la clé privée. 3. Envoi du mail avec l'entête DKIM-Signature # dig +short txt dkim2k._domainkey.client.isoceltelecom.net "v=DKIM1; k=rsa; s=email; " "p=MIIBIjANBgkqhkiG9w0BAQEFAA..." 12
Réception : 1. Vérification de la signature du mail par le serveur de réception. Ne précise pas l'attitude à tenir en cas d'absence de signature DKIM ou de signature invalide ... Received: by smtp.client.isoceltelecom.net ... DKIM-Signature : v=1 ; a=rsa-sha256 ; c=simple/simple ; d=client.isoceltelecom.net ; s=dkim2k ; t=1413623933 ; bh=0SkFV1BD6HvC0yytwQcSR1fGSPzKmBP/0eVoYrbyqfo=; h=Subject :From :To :Date ; b=UQY+Lj6Qo6Evaz5/aQYJ0GIJ8IfxlRtfxCGxEsIfI9aQOpq09j0D5k76HXaGAN9NJ f6Y3SlnkDEnrrAzf/meJYgBHtgYu0U1AGRELckKLuKEfPsxy7lx3IG52eeYe5gFkmQ HNPedV8NeHGBqUsAF9RWlLp/enVolYLDkc1qy3QQe+XfdQ7eB8DjArvZR4PblSh98p rOy773EWx6xUh1sZnGgIMz3EmPgf0F8qXa0gXKEuGny07oo4JY/tsYzBeuT0gsDnzF bpi4zVgl/91i2DO41b85iv0J5htD6FEC87dQWMtWAKHlgN0w53PXb/6KQR3b3QG98q so8EgB/K5SrJw== Subject: Abuse from <ip> ... 13
Confor- mance Définition des méthodes d'authentification : SPF et/ou DKIM Conduite à tenir au cas où ces méthodes d'authentification échouent. Le R de DMARC permet au destinataire d'envoyer des rapports d'évaluation (de DMARC) avec succès ou non à l'émetteur. Non encore complètement standardisé. 15
Confor- mance Définition des méthodes d'authentification : SPF et/ou DKIM Conduite à tenir au cas où ces méthodes d'authentification échouent. Le R de DMARC permet au destinataire d'envoyer des rapports d'évaluation (de DMARC) avec succès ou non à l'émetteur. Non encore complètement standardisé. 16
Signing Practices (RFC 5617) reclassifer comme « intérêt historique seulement » 1. Son rôle était pourtant intéressant : publier ses pratiques de signature DKIM au cas où le mail ne serait plus signer avec DKIM. Vouch by Reference (RFC 5518) basé sur une chaîne de confiance à partir d'une autorité comme pour les certificats X.509 du HTTPS. Forward-confirmed reverse DNS 2 qui n'est pour le moment essentiellement que de la vérification de PTR 1. http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ 2. https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations- 19
tout serveur DNS (Bind,etc). SMTP : tout serveur de messagerie (postfix, sendmail, etc). DKIM : OpenDKIM 3 DMARC : OpenDMARC 4 Enregistrement DNS classique : ◦ SPF ◦ PTR ◦ Clé publique DKIM ◦ Règle DMARC Le DNS est le maillon faible du système. D'où l'intérêt de le protéger (TSIG et DNSSEC) 3. http://www.opendkim.org/ 4. http://www.trusteddomain.org/opendmarc/ 21
alfredarouna
cibmc
bigtree
takusamar
florets1
renderpool
kawaiirailroads
n0bisuke2
ddeimeke
scbc1167
kurotaky
yumechi
sonatard
addyosmani
cassininazir
chriscoyier
palkan
mclloyd
quramy
62gerente
lemiorhan
zakiyama
hannesfritz
jeffersonlam
