Ce que « dkim=pass » signifie vraiment

Si vous avez ouvert les en-têtes d’un e-mail, y avez trouvé une ligne comme dkim=pass header.d=supplier.com; spf=pass; dmarc=pass et voulez savoir si cela signifie que le message est sûr : cela signifie que le message vient bien de ce domaine, et rien de plus. Cela ne dit rien de l’authenticité de la facture, de l’exactitude des coordonnées bancaires, ni du fait que la personne qui écrivait était votre fournisseur.

Ce n’est pas un détail technique. La fraude à la facture la plus coûteuse d’Europe passe les trois contrôles, à chaque fois, parce qu’elle est envoyée depuis la vraie boîte du fournisseur. Si vous avez une demande de paiement entre les mains, la vérification de courriel fournisseur lit le message et indique lesquelles de ces choses elle a réellement pu établir — et, tout aussi important, lesquelles elle n’a pas pu établir.

Ce que demande réellement chacun des trois contrôles

On les écrit souvent comme s’ils formaient un seul verdict. Ce sont trois questions différentes, et aucune n’est « cet e-mail est-il honnête ».

SPF demande si le serveur qui a délivré le message fait partie de ceux que le propriétaire du domaine a déclarés autorisés à envoyer. C’est une question sur une adresse IP. Elle ne dit rien de qui a écrit le message, ni de ce qu’il contient.

DKIM demande si une signature cryptographique portant sur des parties du message correspond à une clé publique publiée dans le DNS du domaine. Une réussite signifie que quelqu’un détenant la clé privée de ce domaine a signé ces parties, et qu’elles n’ont pas été modifiées depuis. C’est le plus fort des trois — et c’est une affirmation sur le domaine, pas sur l’intention de l’expéditeur.

DMARC demande si SPF ou DKIM a réussi pour un domaine correspondant à l’adresse From: que voit le lecteur, et indique aux serveurs destinataires quoi faire quand ni l’un ni l’autre n’y parvient. Il rattache les deux autres à l’expéditeur visible. C’est réellement utile, et ce n’est toujours pas une affirmation sur le contenu.

Donc dkim=pass header.d=supplier.com signifie : c’est bien le domaine de votre fournisseur. Ce qui est exactement ce à quoi vous vous attendriez si un criminel était installé dans la boîte de votre fournisseur.

La fraude qui passe tous les contrôles

La version de la fraude à la facture qui réussit n’est pas un domaine sosie. C’est un vrai e-mail depuis la vraie boîte du vrai fournisseur, atteinte le plus souvent avec un mot de passe issu d’une fuite sans rapport, ou via une page d’hameçonnage remplie des semaines plus tôt.

Tout s’authentifie, parce que tout est authentique :

• le message est signé par le domaine du fournisseur lui-même, donc DKIM passe ;
• il part du prestataire de messagerie du fournisseur lui-même, donc SPF passe ;
• l’adresse From: correspond, donc DMARC passe ;
• l’historique du fil est réel, car c’est le vrai fil.

Seules les coordonnées bancaires sont nouvelles. L’authentification des e-mails n’a aucun avis sur les coordonnées bancaires.

C’est pourquoi « l’e-mail s’est authentifié » n’est jamais une raison de payer, et pourquoi chaque résultat sur ce site — y compris ceux qui ne relèvent rien — se termine par la même phrase sur l’appel à un numéro que vous aviez déjà. Un déroulé plus long figure dans un fournisseur demande par e-mail de changer ses coordonnées bancaires.

Qui a écrit la ligne que vous lisez

Il y a un second piège, et il est facile à manquer.

Authentication-Results: est un en-tête écrit par le serveur de messagerie qui a reçu le message — votre propre prestataire, en général. Quand vous y lisez dkim=pass, vous lisez le verdict de quelqu’un d’autre, consigné au moment de la remise. C’est normalement digne de confiance, parce que c’est votre propre prestataire qui l’a écrit.

Mais les en-têtes ne sont que du texte. Si le bloc vous a été transféré, collé dans un ticket, recopié depuis la capture d’écran d’un collègue, ou remis par celui-là même qui demande à être payé, alors la ligne qui dit dkim=pass est une affirmation de celui qui a produit le texte — et n’importe qui peut la taper. Aucune cryptographie ne protège un en-tête affirmant que la cryptographie a réussi.

La distinction honnête sépare trois situations très différentes :

Ce dont vous disposez	Ce qui peut être établi
Le message brut complet, signature comprise	La signature peut être vérifiée maintenant, par vous
Seulement les en-têtes, avec une ligne Authentication-Results	Le verdict consigné par le serveur destinataire, pris sur parole
Ni l’un ni l’autre — seulement l’e-mail visible	Uniquement ce que le domaine publie : SPF, DMARC, MX

Tout outil qui vous montre le deuxième en l’appelant le premier vous dit une chose que vous n’avez aucun moyen de contrôler. La vérification de courriel fournisseur indique lequel des trois elle effectue, et n’en promeut jamais un au rang d’un autre : un dkim=pass figurant dans un bloc d’en-têtes collé est rapporté comme le verdict du destinataire, dans ces termes-là.

Quand un « fail » compte plus qu’un « pass »

Une réussite est une preuve faible. Un échec est une preuve forte, et mérite qu’on s’arrête.

Si la vérification DKIM s’exécute réellement et contredit — la signature ne correspond pas au contenu —, le message a été modifié après signature, ou n’a jamais été signé par ce domaine. Si DMARC est réglé sur p=reject et que le message a malgré tout échoué, il n’aurait pas dû être remis.

Une asymétrie mérite d’être retenue : impossible à vérifier n’est pas la même chose qu’échoué. Une requête DNS injoignable, une clé révoquée, une signature expirée ou une signature ne couvrant qu’une partie du corps signifient toutes que le calcul n’a pas pu aller à son terme. Ce n’est pas un constat à charge contre l’expéditeur, et un outil qui le présente ainsi gâche le seul signal sur lequel il aurait valu la peine d’agir.

Que faire d’un message dont vous n’êtes pas sûr

1. N’y répondez pas. Si la boîte est compromise, votre réponse part chez l’attaquant, et une règle de boîte peut la cacher au vrai fournisseur.
2. Appelez le fournisseur sur un numéro tiré d’une ancienne facture, de votre logiciel comptable, ou de son site web auquel vous avez accédé en tapant l’adresse vous-même.
3. Vérifiez les identifiants séparément — le numéro de TVA, l’inscription au registre des sociétés et, pour un fournisseur polonais, si le compte est sur la liste blanche. Le vérificateur de factures fait tout cela à partir du document lui-même.
4. Traitez le changement de coordonnées bancaires comme l’événement, et non l’e-mail qui l’entoure. C’est cela qui mérite un appel, quoi que disent les en-têtes.

Ce que cela ne peut pas vous dire

L’authentification des e-mails contrôle le canal, pas l’affirmation. Elle ne peut pas vous dire que la marchandise a été commandée, que le montant est juste, que la personne qui écrit travaille encore là, ni que le compte appartient à votre fournisseur. La Pologne est le seul pays de l’UE à publier une réponse à cette dernière question, raison pour laquelle la liste blanche vaut d’être utilisée là où elle s’applique.

Partout ailleurs, le contrôle qui attrape cela est un appel de vive voix à un numéro que vous aviez déjà.