Retour à l’expéditeur : améliorer la sécurité avec l’authentification d’email

De nombreux exploits modernes hautement médiatisés trouvent leur origine dans un simple message électronique. La capacité de l’expéditeur à usurper l’identité d’un partenaire commercial ou d’un collègue constitue une étape importante pour rendre plausible un email malicieux. Et traditionnellement, le courrier électronique n’offre que peu d’éléments pour authentifier l’émetteur. Les entêtes peuvent être aisément maquillées et le destinataire, cible de l’attaque, est laissé sans défense pour déterminer quels messages sont légitimes et lesquels ne le sont pas.

Le courrier électronique peut être authentifié de deux manière différentes : de personne à personne ou de serveur à serveur. La première option consiste ainsi à ajouter une signature électronique. Si l’émetteur ajoute une telle signature, le destinataire doit la vérifier. Mais l’approche de la signature électronique du courrier électronique n’a pas été largement adoptée en raison des difficultés associées au déploiement sûr et efficace des certificats requis, dans la cadre de vastes déploiements. En outre, les individus utilisant des terminaux multiples pour recevoir et envoyer des courriers électroniques ont des problèmes à configurer leurs terminaux de manière cohérente, avec ces certificats. Enfin, les systèmes de messagerie Web ne sont généralement pas supportés.

Dès lors, il s’avère plus simple de recourir à l’authentification entre serveurs. Deux mécanismes ont été traditionnellement utilisés pour accomplir cela : DKIM, ou DomainKey Identified Mail, et SPF, Sender Policy Framework. Récemment, ces standards ont été intégrés au sein de DMARC – Domain-based messaging authentification, reporting and compliance -, une spécification émergente que Google, Yahoo, Microsoft et de nombreux autres utilisent pour aider à améliorer la sécurité du courrier électronique.

Afin de tirer profit de DMARC, une entreprise doit commencer par publier les informations DKIM et SPF dans les enregistrements DNS relatifs à ses noms de domaine. DKIM utilise le chiffrement à clé publique pour signer les entêtes de courrier électronique sur le serveur. La clé publique est publiée dans les enregistrements DNS, et une clé privée est déployée sur le serveur de messagerie afin de lui permettre de signer les emails envoyés par ses utilisateurs. Cela permet d’assurer qu’un serveur est bien autorisé à envoyer des emails pour le domaine considéré. DKIM peut être difficile à déployer si des services de messagerie tiers sont utilisés. Mais certains fournisseurs, comme Google avec Gmail, autorisent désormais leurs clients entreprises à ajouter leurs clés de chiffrement.

SPF ne repose pas sur le chiffrement et s’avère plus simple à configurer. L’enregistrement DNS SPF liste tous les serveurs autorisés à expédier des messages pour le domaine considéré. Cela fonctionne bien pour un nombre limité de serveurs de messagerie. Mais des serveurs tiers peuvent être aisément ajoutés.

DMARC n’utilise toutefois pas que DKIM et SPF pour vérifier qu’un message provient bien d’un serveur autorisé pour le domaine considéré. Il fournit également des informations à l’émetteur en cas d’échec de livraison du message, et permet au domaine expéditeur de déterminer le comportement à adopter en cas de message non conforme.

Comme pour le cas des stratégies DKIM et SPF, l’information utilisée pour prendre des décisions est publiée via les enregistrements DNS. DNS est une méthode très souple de publication d’informations avec une latence limitée. Et le destinataire peut conserver ces informations en cache afin de limiter les requêtes DNS.

Avec DMARC, une organisation publie une liste sous la forme d’un enregistrement SPF mentionnant les serveurs autorisés à envoyer des emails en son nom. En outre, elle publie un enregistrement DMARC indiquant quoi faire des messages non conformes. En général, ceux-ci sont placés en quarantaine ou supprimés.

Dans l’exemple qui suit, l’enregistrement SPF identifie deux réseaux à partir desquels des emails peuvent être envoyés pour le domaine considéré. Il spécifie en outre que Google est susceptible d’envoyer des emails pour le domaine parce que certains utilisateurs utilisent des comptes Gmail.

v=spf1 mx ip4:192.0.2.0/24 ip6:2001:db8::/48 include:_spf.google.com

Comme le montre l’enregistrement DMARC ci-dessous, il est demandé aux destinataires de rejeter les emails non conformes aux règles spécifiées dans les enregistrements DKIM et SPF, et d’envoyer des rapports quotidiens sur les rejets à [email protected] en utilisant le format afrf, un format de reporting basé sur XML.

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r\; aspf=r; pct=100; rf=afrf; ri=86400;

De nombreuses organisations sont réservées quant à l’implémentation de SPF ou de DKIM. Un enregistrement SPF ou DKIM mal configuré peut conduire au rejet de couriers légitimes. En ajoutant un enregistrement DMARC, une organisation peut fournir une adresse email où envoyer des rapports sur ces rejets. Google, par exemple, supporte cette fonction. Et si le géant du Web rejette des messages, il en enverra une synthèse au destinataire annoncé dans l’enregistrement DMARC, à raison, en général, d’un résumé par jour.

En plus de problèmes de configuration, ces rapports informent sur les éventuelles tentatives d’usurpation d’identité.

Adapté de l’anglais par la rédaction.