Sécurité et authentification de courriel

Les méthodes ont beaucoup évolué avec le temps. Elles se sont surtout simplifiées. Je me souviens encore dès l’assermentation de « notaire » pour authentifier un courriel avec PGP. Un réseau intéressant, mais d’une complexité qui en a rebuté plus d’un. À l’époque le nom de domaine se confirmait encore avec une télécopie... Depuis il existe plusieurs solutions que l’on applique couche après couche. Les 4 normes d’authentification les plus utilisées sont :

Bien entendu, à part l’entrée SPF, ces mesures ne sont pas obligatoires pour authentifier un courriel. Mais il n’a rien comme ajouté des couches en sécurité pour la renforcer. Particulièrement dans le contexte où la grande majorité des communications qui transigent sur le web sont justement des pourriels (pourriel, hameçonnage...). Et outre les états, les conventions, et les FAI (qui d’ailleurs en profitent), la responsabilité incombe tout autant aux gestionnaires de domaine, c’est-à-dire au commun des mortels. Votre domaine doit être protégé, et ce à plusieurs égards.

D’autant qu’il est question de simples entrées DNS. C’est-à-dire la redirection de requête vers le bon IP. Un serveur DNS (Domaine Nom System) transforme un nom de domaine en adresse IP et vice-versa, soit pour une redirection, soit pour une validation, sans plus. Mais on profite de l’occasion pour traiter la demande, en ajoutant par exemple des entrées « txt » qui seront ajoutées à l’entête de la requête, dans le cas présent à l’entête du courriel, pour ensuite être validé par une requête du receveur au serveur DNS.

Et pourtant, quel bordel ! il y a tellement de confusion et de serveur mal configuré. Tellement de problèmes que nombre d’entreprises changent carrément de solution (et de IP) pour sauver les meubles. Si simple qu’une simple entrée DNS, une petite ligne de quelques caractères ironiquement dédié à l’authentification, à permit à Zachary Harris de « spoofer » les serveurs de Google (« How a Google Headhunter’s E-Mail Unraveled a Massive Net Security Hole par Kim Zetter - Wired ») ! Rien d’étonnant à ce que la majorité des serveurs utilise une configuration minimaliste !

Vous voulez voir si votre infrastructure de messagerie est prête DMARC? Résultat du test SPF, DKIM, DMARC et signature « DomainKeys ». Envoyer un courriel vide à checkmyauth@auth.returnpath.net et Return Path va analyser automatiquement tous les aspects de vos pratiques d’authentification de courriel pour retourner le un rapport par courriel à l’adresse qui a envoyé la demande.

SPF - C’est devenu quasi impossible d’envoyer un courriel sans SPF (même si le « Soft Fail » est toujours pratique courante). Comment faire autrement quand Gmail l’exige! Une simple entrée DNS pour un SPF permet en gros d’indiquer au receveur du courriel de vérifier si l’IP de l’envoyeur correspond bien aux IPs spécifié par le SPF du serveur envoyeur.
DKIM - Implanté par Yahoo! Mail (et Cisco), pionnier en la matière, la mesure DKIM permet aussi, comme le SPF, d’authentifier l’envoyeur en comparant l’IP avec ceux de l’entrée DNS « selecteur._domainkey » mais cette fois en cryptant (sha-256) l’information avec un « sélecteur ».
Sender ID - Le principe est globalement identique à celui du SPF et repose sur une déclaration au niveau du DNS de domaines ou adresses IP déclarés comme pouvant envoyer des courriels signés du domaine considéré.
DMARC - Enfin, l’entrée DNS _dmarc (DMARC), qui n’est pas vraiment une mesure mais une suggestion d’action à prendre par le serveur receveur pour traiter la réponse du SPF ou du DKIM. Le DMARC est une demande de rapport, alors vous recevrez un courriel quotidiennement pour indiquer l’état de la configuration pour envoyer un courriel.

SPF (Sender Policy Framework)

SPF est une norme qui permet d’identifier les serveurs qui sont autorisés à envoyer des courriels pour un nom de domaine donné. Le principe est de vérifier à la réception du message que le domaine ou l’adresse IP utilisée pour envoyer le message est un domaine ou serveur utilisé et déclaré par le domaine s’identifiant comme expéditeur.

Pour utiliser la norme SPF, le domaine expéditeur doit mettre à jour son profil au niveau du DNS en déclarant les différents domaines ou adresses IP pouvant être utilisée pour envoyer du courrier en son nom. Les serveurs de messageries destinataires peuvent alors interroger le DNS pour vérifier la correspondance entre l’expéditeur et le serveur utilisé pour envoyer le message.

La chaine doit toujours débuter par la version : v=spf1 suivit d’une suite de « mécanisme ». Par exemple, l’entrée suivante autorise les courriels envoyés uniquement par les domaines avec une entrée MX déclarée sur le serveur.

v=spf1 mx -all

Ou encore en précisant un ou un bloc d’adresse IPv4 et IPv6.

v=spf1 ip4:xx.xxx.xxx.xxx -all

Mécanismes

ALL: Correspond toujours.
A: Correspond si le nom de domaine possède un enregistrement IN A (ou AAAA) qui peut être résolu comme adresse d’expéditeur.
IP4: Correspond si l’expéditeur est dans cette plage IPv4.
IP6: Correspond si l’expéditeur est dans cette plage IPv6.
MX: Correspond si le nom de domaine contient un enregistrement Mail eXchanger pointant vers l’adresse de l’expéditeur (ex : si le mail provient d’un des serveurs entrants du domaine).
PTR: Correspond si le domaine de l’adresse IP (PTR record) correspond au domaine spécifié, et que ce dernier pointe vers l’IP en retour (forward-confirmed reverse DNS (en)). Ce mécanisme est toutefois désuet et ne doit plus être utilisé4.
EXISTS: Correspond si domaine donné existe, c’est-à-dire s’il est résolu en n’importe quelle adresse (peu importe la résolution de cette dernière). Ce mécanisme est rarement utilisé. Avec le macrolangage SPF il offre des correspondances plus complexes, comme les requêtes DNSBL.
INCLUDE: Correspond si la règle incluse passe le test. C’est typiquement utilisé pour gérer les règles quand il y a plusieurs FAI.

Préfixes

+ (par défaut): autorise la transaction si le résultat est favorable. Par défaut ce préfixe est optionnel.
?: Interprété comme NONE, aucune règle.
~: autorise la transaction même s’il y a un échec. Le courriel est envoyé quand même avec une mention « Soft Fail ». Utilisé en principe pour les test, le « Soft Fail » est malheureusement très répendus pour éviter les complications d’une bonne configuration.
-: échec total (Hard Fail). Le courriel est rejeté, ce qui devrait toujours être, idéalement, le cas.

Ajouter à celà les « Modifieurs »

exp=some.example.com: donne le nom du domaine avec un enregistrement TXT (interprété comme utilisant le macrolangage SPF) pour obtenir une explication des résultats en échec. Typiquement, une URL ajoutée au code erreur SMTP.
redirect=some.example.com: alternative au mécanisme ALL, pour lier à un enregistrement de règle d’un autre domaine. Il est similaire au mécanisme INCLUDE.

Domainkeys ou DKIM (DomainKeys Identified Mail)

Le DKIM est un important mécanisme d’authentification encodée avec clé publique pour protéger les courriers électroniques de l’hameçonnage et de la falsification de courriel qui a été initiée par Yahoo (et Cisco). La procédure DKIM fonctionne selon le même principe que le SPF ou Sender ID et repose sur une déclaration de domaines et adresses IP autorisés qui se fait au niveau des données DNS d’un domaine à la différence qu’elle est cryptée (cryptage sha-256).

À la réception d’un courriel, le serveur de messagerie s’assure que le domaine ou l’adresse IP utilisée pour expédier le courriel est bien déclaré ou habilité par le domaine affiché comme expéditeur en le décryptant avec une clé publique..

Générer une clé DKIM à l’aide de Domain Key / DKIM Generation Wizard, l’open source comme DKIM Core Tools ou directement à l’aide de votre serveur de courriel comme MailEnable. Avec MailEnable il faut au préalable activer la fonctionnalité (Selector).

Utiliser le nom de domaine sans extension comme sélecteur suivit du « ._domainkey » : mondomaine._domainkey
Entrer votre domaine : mondomaine.com

Exemple DNS sous IIS

Même chose en ajoutant l’entrée DNS, ajouter dans l’entête du fichier txt « mondomaine._domainkey ». (voir l’image)

mondomaine._domainkey
mondomaine.com
v=DKIM1;p=UA4NADBiQKBQD.......A0CSqGIb;

DKIM Test avec had-pilot.com

Envoyez un courriel à pythentic at had-pilot.biz et le sujet « register » pour vous enregistrer. Puis un autre avec le sujet « dkim ».

Chiffrage à 1 024 bits

Exemple d’abus de clé DKIM à 1024 bits — Exemple d’abus de clé DKIM à 1024

Pour des raisons de sécurité, la norme DKIM préconise l’utilisation de clés d’une longueur minimale de 1 024 bits. En 2012, Zachary Harris découvrait que Google utilisait une clé de 512 bits. Malheureusement pour Google, une clé de 512 bits peut facilement être décomposée en moins de 72 h ! Depuis Google est passé à un chiffrement de 2,048 bits ;- )

« ...In 1998 it was an academic breakthrough of great concerted effort to crack a 512 bit key. Today little old me can do it by myself in 72 hours on AWS. The field of cryptography keeps developing and breaking new ground just like everything else, and you can’t just install a private key, or select a hash algorithm, and expect it to be good forever... » - Source : How a Google Headhunter’s E-Mail Unraveled a Massive Net Security HoleTexte par Kim Zetter

Ce qui est bien avec cette technique, si elle fonctionnait vraiment et s’il y avait un véritable avantage, c’est les innombrables rapports DMARC envoyés par Google ou Yahoo. On peut effectivement être avisé d’abus, qui en général ne passe pas le test. C’est très intéressant, on peut aussi découvrir les failles de notre système, etc. Mais si ça fonctionnait vraiment encore une fois.

De un, mes courriels sont toujours identifiés comme pourriel (spam) par Google ou Outlook malgré toutes ces mesures, alors c’est davantage pour se prémunir du « spoofing ». Mais de deux, aujourd’hui, je viens de recevoir un rapport DMARC de Google qui m’indique clairement qu’un IP (209.91.128.43), qui n’est pas le mien et qui d’ailleurs ne passe pas le SPF (softfail!!), passe malgré tout le test DKIM avec une clé de 1024 bits comme on peut voir dans l’image !!! Ou bien Google en arrache ou bien cette technique n’est toujours pas fiable !

Quand une mesure de sécurité ouvre une faille de sécurité...

Références et outils

Domain Key / DKIM Generation Wizard par SocketLabs
DKIM Explained: How to Set Up and Use DomainKeys Identified Mail Effectively par Anne P. Mitchell
Creating DKIM TXT Records in Windows DNS
MailEnable : Domain - DKIM (DomainKeys)
DKIM Core Technical Specification
Check a DKIM

Sender ID

Le « Sender ID » est une norme d’authentification du domaine expéditeur d’un courriel développée et proposée par Microsoft et donc utilisée pour le filtrage par Hotmail et WindowsMail. Le Sender ID ne diffère pas du SPF. Les deux valident les adresses de l’expéditeur du courriel en utilisant des méthodes similaires pour le faire. Tout deux utilisent une entrée DNS pour propager leur politique avec la même syntaxe. Tout pour les confondre à première vue. Ils ne diffèrent qu’au niveau de ce qui est validé et de la couche du système de courriel qui les concerne.

La balise pour les enregistrements SPF est "v=spf1". Il est défini par le RFC 4408 seulement pour les identités FROM et HELO. La balise pour les enregistrements Sender ID peut être "spf2.0/par", "spf2.0/mfrom", ou "spf2.0/mfrom,par", selon les identités affecté par la politique. Néanmoins, le Sender ID n’est pas la dernière version de SPF. Un peu comme le RSS 2.0 n’est pas une amélioration du RSS 1.00 - le spf2.0 est un protocole obsolète et indépendant. Le nom de la balise est un accident historique. D’ailleurs le Sender ID Framework SPF Record Wizard génère une chaine SPF1.0.

record =: version terms *SP
version =: "v=spf1" | ( "spf2." ver-minor scope)
ver-minor =: 1*DIGIT
scope =: "/" scope-id *( "," scope-id )
scope-id =: "mfrom" / "pra" / name

Exemple

spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all

DMARC « Domain-based Message Authentication, Reporting & Conformance »

DMARC est une spécification technique créée par un consortium afin de réduire le risque d’abus et d’hameçonnage (phishing) par messagerie électronique. L’idée est de simplifier le déploiement et autres finalités relatif au protocole d’authentification de courriel. DMARC signifie authentification, génération de rapports et conformité de messages basée sur un domaine. Il s’agit en fait d’un ensemble de règles permettant de vous informer de la qualité des messages électroniques reçus de votre domaine.

DMARC normalise la façon dont les serveurs effectue une authentification de messagerie en utilisant les mécanismes SPF et DKIM bien connus. Cela signifie que les expéditeurs connaîtront les résultats d’authentifications cohérentes pour leurs messages à AOL, Gmail, Hotmail, Yahoo! et tout autre serveur de messagerie mettant en œuvre DMARC. Elle permet aux détenteurs de domaines d’indiquer aux serveurs de messageries quelle conduite tenir lorsqu’un courriel signé de leur domaine n’est pas formellement identifié par une norme DKIM ou SPF. En l’occurrence : ne rien faire, refuser ou placé en quarantaine (None, Quarantine, Reject). Un site bancaire peut par exemple demander à ce que les messages apparemment issus de son domaine soient bloqués et supprimés lorsque non authentifiés. Dans l’espoir que cela encourage les expéditeurs à authentifier plus largement leur courrier sortant de manière à rendre la communication via courriel plus fiable.

Autre détail important, la norme DMARC permet d’avoir des rapports de statistiques sur les tentatives d’hameçonnage utilisant leur domaine en signature. Pour ce faire vous pouvez spécifier votre adresse de courriel ou encore vous inscrire à un de ces services en ligne qui fera le travail de veille pour vous :

DMARC Record Assistant
Agari DMARC Record Generator
Return Path DMARC Record Generator (demande une inscription)
DMARC Wizard (création d’enregistrement) chez UnlockTheInbox.com

Shéma DMARC (Source : dmarc.org) traduit par Oznog

Exemple :

La chaîne de base est semblable à une entrée SPF, version, politique (None|Quarantine|Reject) et pourcentage.

// Nom de l’enregistrement : _dmarc
v=DMARC1; p=none; pct=100; rua=mailto:admin@mondomaine.com; ruf=mailto:admin@mondomaine.com;

Balise	Objectif	Exemple
v	Version du protocole	v=DMARC1
pct	Pourcentage du message à filtrage	pct=20
ruf	Adresse (URI) pour rapport d’erreur d’authentification	ruf=mailto:authfail@example.com
rua	Adresse (URI) pour rapport de compilation	rua=mailto:aggrep@example.com
p	Politique pour le domaine de l’organisation	p=quarantine
sp	Politique pour les sous-domaines de l’OD	sp=reject
adkim	Mode d’alignement pour DKIM	adkim=s
aspf	Mode d’alignement pour SPF	aspf=r

Exemple de rapport DMARC

Comme on peut lire dans la spécification (RFC 7489), RUA signifie « Reporting URI of Aggregate Reports ». En l’utilisant, vous dites à chaque serveur destinataire conforme à la DMARC de vous envoyer un rapport global (quotidien) pour les courriels qu’ils reçoivent ou que vous envoyez en votre nom.

Le nom d’utilisateur dans l’enregistrement TXT dmarc rua=mailto:exemple@trucsweb.com indique l’adresse où envoyer les rapports XML. Notez que la règle de traitement pour les messages en échec : p=none signifie que vous voulez uniquement voir les résultats des contrôles.

<?xml version="1.0"?>	
<feedback>	
  <report_metadata>	
    <org_name>Yahoo! Inc.</org_name>	
    <email>postmaster@dmarc.yahoo.com</email>	
    <report_id>xxxxxxxxxx.xxxxxx</report_id>	
    <date_range>	
      <begin>xxxxxxxxxx</begin>	
      <end>xxxxxxxxxx</end>	
    </date_range>	
  </report_metadata>	
  <policy_published>	
    <domain>trucsweb.com</domain>	
    <adkim>r</adkim>	
    <aspf>r</aspf>	
    <p>none</p>	
    <pct>100</pct>	
  </policy_published>	
  <record>	
    <row>	
      <source_ip>192.168.0.100</source_ip>
      <count>2</count>	
      <policy_evaluated>	
        <disposition>none</disposition>	
        <dkim>pass</dkim>	
        <spf>pass</spf>	
      </policy_evaluated>	
    </row>	
    <identifiers>	
      <header_from>trucsweb.com</header_from>	
    </identifiers>	
    <auth_results>	
      <dkim>	
        <domain>trucsweb.com</domain>	
        <result>pass</result>	
      </dkim>	
      <spf>	
        <domain>trucsweb.com</domain>	
        <result>pass</result>	
      </spf>	
    </auth_results>	
  </record>	
</feedback>

Un message envoyé par une adresse exemple@trucsweb.com et reçu par les serveurs de messagerie Yahoo! entre deux dates est correctement signé (DKIM) et a été envoyé à partir d’une adresse IP autorisée (SPF). Nous pouvons raisonnablement dire que Yahoo! n’a reçu que des messages légitimes de ce domaine.

<date_range> Indique la plage de temps à laquelle ce rapport fait référence;
<policy_published> C'est le contenu analysé de l'enregistrement dmarc trouvé par Yahoo! dans la zone DNS;
<source_ip> L'adresse IP à partir de laquelle le courriel a été envoyé;
<policy_evaluated> Le résultat des contrôles DKIM et SPF.

IMPORTANT : Redirection ou flux de messagerie indirects (Forwarders)

Il ne s’agit pas ici d’abus de votre domaine, mais de mauvaise configuration des autres services. Attention par exemple de bien vérifier vos DNS, notamment vos SPF et MX si vous utiliser des hébergements gratuits comme Wix.com particulièrement si vous utilisez un serveur SMTP externe avec Gmail. La combinaison des deux peut être hasardeuse...

Lors du déploiement de DMARC, les propriétaires de domaine constatent souvent que le courrier électronique peut transiter par les redirecteurs avant d’arriver à une destination finale. Les propriétaires de domaine se demandent alors si le transitaire est capable d’interagir avec DMARC. Certains transitaires, comme Gmail, acceptent le courrier électronique pour la livraison, puis le transmettent à différentes destinations. « Gmail recommande de ne pas modifier l’expéditeur du message lors d’un transfert vers Gmail. Car parfois, il arrive que l’expéditeur soit remplacé par votre domaine. Dans ce cas, Gmail peut en conclure que votre domaine envoie un spam, et il risque de considérer comme spam tous les autres messages provenant de ce domaine. source : Meilleures options pour transférer des messages vers Gmail ». Et vous recevrez un rapport DMARC... Si vous utilisez ce genre de service, je vous invite à lire sur le sujet : Envoyer des e-mails avec une adresse ou un alias différents.

ATTENTION : N’implanter pas la norme DMARC sans SPF ni DKIM sinon votre domaine risque d’être blacklisté!

Bonnes habitudes et nétiquette

Bien sûr il ne faut jamais oublier l’essentiel :

Éviter d’afficher vos adresses de courriel dans des pages Web ou dans des communications est déjà une première mesure. Notez que les registraires abusent à leur tour en facturant un autre montant annuel pour assurer la confidentialité des contacts par nom de domaine, notamment lors des requêtes « whois »...
Éviter surtout de distribuer les adresses d’autrui. Par exemple en Copie-conforme! Ce n’est pas seulement une responsabilité mais un minimum de savoir-vivre, pure nétiquette!
Éviter d’abuser à votre tour. C’est-à-dire en respectant les politiques du pays du destinataire qui demande de plus en plus une inscription en bonne et dû forme avec la possibilité de se retirer d’une liste à tout moment. Le publipostage n’est pas seulement une tare, c’est aussi une des plus grandes forces du Web pour rejoindre rapidement un grand nombre de personnes et ce en temps quasi réel. Pourquoi s’en passer? Mais c’est un art qui peut aisément faire basculer votre domaine dans une liste noire et ainsi anéantir l’ensemble de vos mesures de sécurité et d’authentification... D’ailleurs il est préférable d’utiliser un domaine spécifique pour votre publipostage, distinct de votre site Web par exemple.
Installer antipourriel et antivirus, tant sur le serveur que localement.