Lorsque nous parlons d'"authentification du courrier électronique", nous faisons référence à une technique qui fournit au destinataire d'un message un certain niveau de certitude que le message provient bien de la source déclarée du message. L'idée derrière ces techniques est d'atteindre un certain niveau de défense contre les e-mails frauduleux, tels que le phishing et l'usurpation d'identité, qui pourraient éroder la confiance d'un destinataire dans la réception d'e-mails. Cela dit, l'envoi d'un courrier électronique authentifié ne signifie pas qu'il s'agit d'un bon courrier ou d'un courrier souhaité ; cela signifie seulement que le courrier est tel qu'une réputation pour la partie authentifiée peut être établie de manière fiable et utilisée dans les décisions d'acceptation et de placement du courrier électronique.

Il existe deux formes d'authentification des e-mails utilisées aujourd'hui :

• Sender Policy Framework (SPF)

• Courrier identifié par des clés de domaine (DKIM)

Dans le billet d'aujourd'hui, je vais vous expliquer ce qu'est DKIM et comment il fonctionne.

Aperçu de DKIM

Unlike its authentication counterpart SPF, which provides a way for a domain to authorize a host to send mail on its behalf, DKIM provides a way for an entity (domain, organization, person, etc.) to take responsibility for a message, independent of the entity that actually sent the message. While in many cases the responsible entity and the sending entity will be the same, or at least closely related, with DKIM there’s no requirement that this be so.

L'objectif de cet article est de vous permettre d'apprendre et de comprendre les concepts suivants concernant DKIM :

• DKIM est une authentification "basée sur le contenu", contrairement au SPF "basé sur le chemin".

• L'entité responsable affirme sa responsabilité en "signant" le message avec une paire de hachages cryptographiques insérés dans l'en-tête du message.

• La validation de DKIM est effectuée par le domaine récepteur qui tente de générer les deux mêmes hashs.

• Dans de nombreux cas, la validation de DKIM ne peut pas être achevée tant que le message complet n'a pas été transmis par le serveur d'envoi.

• Les échecs de validation peuvent être difficiles à dépanner.

• 
  

"Authentification basée sur le contenu

DKIM est appelé authentification "basée sur le contenu", plutôt que "basée sur le chemin d'accès", car le fait qu'un message passe ou non la validation DKIM repose uniquement sur le fait que le contenu a été modifié ou non entre le moment où il a été signé et celui où la validation a été tentée.

Signature et validation de DKIM

Les organisations qui souhaitent signer le courrier DKIM doivent d'abord générer deux clés cryptographiques. L'une des clés est privée et disponible pour le serveur d'envoi pour la signature du courrier, et l'autre doit être rendue publique dans le DNS pour être utilisée par les domaines de réception dans les tentatives de validation de la signature. Les méthodes de génération et d'installation de ces clés dépendent de la plate-forme et dépassent le cadre de ce billet, même si je décrirai plus loin la publication dans le DNS de la clé publique DKIM.

L'en-tête DKIM-Signature

Pour commencer à comprendre DKIM, examinons d'abord un en-tête DKIM-Signature :

DKIM-Signature : v=1 ; a=rsa-sha256 ; d=welcome.foo.com ; s=notices ; c=relaxé/relaxé ; q=dns/txt ; i=@welcome.foo.com ; t=1454417737 ; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version :Content-Type ; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc= ; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss= ;

L'en-tête DKIM-Signature se compose d'une série de paires clé-valeur, dont certaines sont plus intéressantes que d'autres pour le lecteur, mais je vais toutes les décrire ici.

Nous examinerons d'abord celles qui présentent le plus souvent un intérêt passager pour le lecteur :

• v=1 ; – Specifies the DKIM version (1 is the only valid value)

• a=rsa-sha256 ; – Le algorithm used to construct the cryptographic hashes

• c=relaxed/relaxed; – There are two sets of rules regarding removal of whitespace in the headers and body that can be applied when creating the hashes in a DKIM signature; these rules are called “canonicalization rules” (hence the key of c) and the rulesets are either “relaxed” or “strict”.

• t=1454417737 ; – Le timestamp of when the signature was created.

Ces trois parties de l'en-tête contiennent les informations relatives à la signature proprement dite :

• bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc= ; - This is the hash of the body of the message.

• h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type ; - This is a list of the headers that were used to create the signature data shown below.

• b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss= ; - This is the acutal DKIM signature data

Ces trois parties sont les plus intéressantes pour le serveur récepteur qui validera la signature :

• d=welcome.foo.com ; - This identifies the domain that signed the message

• s=notices ; - The selector; domains can have multiple selectors that they use when signing messages.

• i=@welcome.foo.com ; - This is the identity on whose behalf the message was signed. Syntactically, this will look like an email address, and might even be one; the localpart of the email address can be empty, as in this example, and the domain part must be the same as, or a subdomain of, the domain in the d= part of the signature.

La raison pour laquelle ces parties sont intéressantes pour le serveur récepteur est qu'elles fournissent les informations nécessaires pour aider le récepteur à valider les signatures.

DKIM Validation

In addition à la requirement mentioned that the i= domain must be the same as or a sub-domain of the d= domain, the d= and s= bits are used by the validator to look up the signer’s public DKIM key in DNS. The key is a TXT record in DNS, and it’s always found au location selector._domainkey.domain. So, in our example here, with s=notices and d=welcome.foo.com, the public DKIM key would be found in DNS at avis._domainkey.welcome.foo.com, and it might look something like this:

notices._domainkey.welcome.foo.com. texte descriptif "v=DKIM1\ ; h=sha256\ ; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+/qIpQIDAQAB\ ; s=email"

Le validateur utilise cette clé (les bits p=) pour produire son propre ensemble de hachages du message. Si ces hachages correspondent, le message n'a pas été modifié en transit et il peut donc contribuer à la réputation du signataire du message, voire en bénéficier.

Échec de la validation et dépannage

J'ai mentionné plus haut que les défaillances de DKIM peuvent être difficiles à résoudre, et je vais vous expliquer pourquoi.

Certains échecs de validation DKIM ont des causes évidentes, comme le fait que le message n'a pas été signé, que la clé publique du domaine de signature n'a pas été trouvée dans le DNS ou que sa syntaxe n'est pas correcte, ou encore que le message a manifestement été modifié en transit. Lorsque ce type de défaillance se produit, il est facile de déterminer le problème et de recommander une solution. Les cas les plus difficiles, et ceux qui conduisent à une expérience de support des plus frustrantes, sont ceux où le message a été signé, la clé publique existe dans le DNS, et le message n'a pas été manifestement altéré, mais le validateur rapporte que la signature n'a pas été validée.

La raison pour laquelle ces problèmes sont difficiles à résoudre est qu'il n'existe aucun moyen réel pour l'une ou l'autre des parties de reproduire les conditions dans lesquelles le message a été signé et validé. Le message contient dans son en-tête DKIM-Signature les hachages générés par le signataire au moment de la signature, mais le validateur n'a probablement pas accès à l'infrastructure du signataire et ne peut donc pas essayer de reproduire la signature dans les conditions du signataire. De même, le signataire n'a probablement pas accès à l'infrastructure du validateur et n'a donc aucun moyen d'essayer de valider le message de la même manière que le validateur.

Les échecs comme ceux que je décris ici sont rares, et les échecs de validation DKIM n'ont généralement pas d'impact sur le placement des messages. D'après mon expérience, ces échecs génèrent plus de tickets de support que tout autre type de problème DKIM.