Le protocole DKIM n’a pas seulement pour but d’empêcher la modification d’un message après signature, mais aussi d’interdire l’ajout de caractéristiques de nature à le dévoyer. La RFC 6376 décrit précisément la technique à appliquer, aussi élégante qu’ignorée. Les acteurs d’internet ne tirant pas partie de cette capacité du protocole, il suffit une fois en possession d’un courriel qui n’a ni Reply-To ni Cc, de le « rejouer » en y ajoutant ces champs pour l’envoyer à qui il n’était pas adressé, lui laissant croire qu’il en était également destinataire. Le message étant réel et son authenticité validée par la signature réputée « inviolable » du vrai domaine expéditeur, sa victime aura peu de chances de déceler la combine. Si elle répond, la conversation pourra se poursuivre sur l’adresse frauduleusement placée dans le Reply-To.

Pire, de nombreux messages sont émis via des serveurs qui ne verrouillent pas le champ To (Exchange On Line, notamment). On peut donc les rejouer vers n’importe qui sans même devoir faire figurer l’adresse du destinataire initial dans la copie frauduleuse, ce qui étend les possibilités de tromperie.

Il me semble que l’absence de verrouillage du To concerne près du tiers des courriels signés par DKIM, tandis que je n’ai encore pu trouver qu’un seul opérateur verrouillant l’ajout a posteriori d’un Cc initialement inexistant (SendinBlue).

Je suis preneur d’autres contre-exemples et de chiffres plus précis.

Encouragements aux émetteurs de mails, verrouillez les champs Cc et Reply-To, Y COMPRIS dans les messages qui n’en contiennent pas, quitte à retoucher les packages qui n’ont pas prévu cette option pourtant parfaitement décrite par les auteurs du protocole.

#DKIM#email#authentication#phishing#spoofing