Signer et Vérifier ses e-mails avec DKIM

1. L'identité et l'E-mail

L'authentification des e-mails, c'est un peu l'Arlésienne du sysadmin. On a vu passer un peu tout et n'importe quoi depuis que SMTP existe, en passant par le génialement novateur PGP jusqu'au presque réussi SenderID (tombé à l'eau pour une histoire de brevet, encore). On a vu des formats tordus, et d'autres plus raisonnables, mais incroyablement complexes à mettre en œuvre (S/MIME). 

Pourtant, au final, ce que veut l'utilisateur, c'est juste pouvoir envoyer un e-mail. A part dans certains cas, l'authenticité de ses correspondances, il s'en fiche un peu et il fait confiance « au système ». Alors, bon, c'est quand même frustrant de ne pas savoir qui se cache derrière le clavier. Surtout quand on ne connaît pas bien la personne et que l'on ne peut pas se baser sur le contenu du mail pour savoir s'il est vraisemblable ou pas. Et vu les enjeux que représente l'utilisation de l'e-mail aujourd'hui, cela explique que les grands noms du domaine aient tous, à un moment donné, proposé ou intégré une solution d'authentification.

2. DKIM, c'est quoi ?

DKIM semble pouvoir résoudre ce problème de manière élégante. Comme le faisait SenderID (mais sans les brevets cette fois), il déporte la signature de l'e-mail du MUA au MTA : ce n'est plus le client qui signe son e-mail, mais le serveur lorsqu'il le prend en charge. Le serveur dispose d'une paire de clés RSA et utilise la clé privée pour signer les e-mails sortants. La clé publique est diffusée via DNS à qui veut bien pour vérifier la signature a posteriori. Le destinataire d'un e-mail signé via DKIM ne verra pas, à première vue, la différence avec un e-mail classique. Mais s'il va jeter un coup d'œil aux en-têtes, il verra la chose suivante (sur un e-mail venant de gmail) :

Charge à lui de valider cette signature, qui va donc nous garantir deux choses :

1. Que l'e-mail a été envoyé par le domaine propriétaire de la clé (charge au domaine d'authentifier ses utilisateurs avant de les laisser envoyer des messages).

2. Que les champs définis dans la valeur h= ont été signés et que leur intégrité est donc assurée.

Alors tout cela est, bien évidemment, défini dans une RFC. Pour DKIM Signature, on ira voir la RFC 4871 qui date de mai 2007. Ce que nous allons voir dans cet article, c'est la mise en place d'une passerelle DKIMproxy pour d'une part signer les mails sortants de notre domaine géré par Postfix, et d'autre part vérifier les signatures des e-mails entrants.

3. Architecture

L'architecture se décompose en deux parties. La première se chargera de l'émission des e-mails par le domaine de l'émetteur. Cette émission nécessite d’ajouter une signature avant l'envoi de l'e-mail sur le réseau (voir figure 1). La seconde partie fera l'inverse, à réception d'un e-mail venant du réseau, elle validera la signature éventuellement présente dans les headers et apposera un header contenant le statut de validation (voir figure 2).

3.1 Architecture de Signature

Le mécanisme un peu particulier à comprendre, et qui fait la force de DKIM, est que celui-ci n'utilise pas de gestionnaire de clés. Ici, pas de PKI, pas de serveur de clés GPG ou autres. On va positionner la clé publique de mondomaine.net dans les enregistrement DNS du domaine. Comme on va le voir plus tard, Bind permet de faire cela via un enregistrement de type TXT. Et lorsqu'un e-mail contenant une signature est reçu, le vérificateur va faire une requête DNS pour obtenir cette clé publique et vérifier la signature.

Cela signifie deux choses. Tout d'abord, la sécurité de DKIM dépend entièrement de la sécurité du DNS. Si un individu peut modifier la clé publique affichée par mondomaine.net, il contrôle toutes les signatures du domaine. De plus, le vérificateur va devoir faire un grand nombre de requêtes DNS afin d'obtenir toutes les clés publiques des domaines environnants. L'IETF annonce dans la RFC 4871 plus de 70 millions de domaines fournissant des services e-mails. Ca peut représenter un énorme volume de requête, et un blocage du resolver DNS bloquerait tout le processus de vérification, et donc la remise des e-mails entrants à leurs destinataires.

4. Mise en place de la signature

Supposons que mondomaine.net fournisse un service e-mail à ses clients. Il est constitué d'un serveur Postfix, pour le SMTP, d'un serveur IMAP quelconque (j'ai une préférence toute personnelle pour Cyrus-Imap) et d'un serveur maître DNS sous Bind 9. Nous allons, dans l'ordre, mettre en place DKIMproxy, puis générer les clés, puis configurer Postfix pour qu'il envoie les mails à signer à DKIMproxy, et enfin Bind pour qu'il mette à disposition la clé publique sur le réseau des réseaux.

4.1 DKIMproxy

DKIMproxy est un ensemble de programmes Perl écrit par Jason Long. Il se compose du module Mail::DKIM et des programmes DKIMproxy.in (pour la vérification) et DKIMproxy.out (pour la signature). La bibliothèque Mail::DKIM peut être installée avec apt-get. Pour le proxy, on préférera les sources de la version 1.3-beta1.

Pour DKIMproxy :

Puis, le classique de l'installation : on crée un répertoire dans ~/dkimproxy puis on ./configure et on make install :

Le répertoire etc/ contient deux fichiers d'exemples pour les deux proxy in et out. Nous allons, nous, créer un fichier de configuration pour le proxy out.

Rien de très original dans ce petit fichier de configuration. C'est dans le fichier sender_map, créé pour l'occasion, que nous allons trouver les informations intéressantes :

La ligne déclare formellement la manière de signer les e-mails pour le domaine mondomaine.net. Les champs sont décrits dans la RFC et sont les suivants :

s= le « selector », qui correspond au nom de l'enregistrement TXT dans le serveur Bind (nous verrons cela dans les sections suivantes) ;

d= le nom du domaine à signer ;

c= le mode de signature. La RFC en définit deux : un « simple », qui est strict et n'autorise aucune manipulation des headers du type modification de casse ou autre, et un « relaxed », qui est plus permissif et donc interopérable ;

a= le mode de signature, soit rsa-sha1, soit rsa-sha256 ;

key= le chemin vers la clé privée à utiliser pour la signature.

Et d'ailleurs, en parlant de clé, on va tout de suite en générer une paire avec OpenSSL :

Le fichier private.key obtenu contient un modulo, des exposants public et privé, les nombres premiers originaux, etc. Si ça vous intéresse, essayez la commande openssl rsa -in private.key -text. Pour le DNS, il faut que l'on exporte le modulo et l'exposant public. Cela se fait de la manière suivante :

La Caste des Ayatollah de la Sécurité me somme de vous rappeler qu'une clé privée, ça se protège au minimum avec un chmod 400. A bon entendeur...

La configuration de dkimproxy.out étant maintenant terminée, essayons de le démarrer. Le répertoire bin contient le programme à lancer avec, en paramètre, le chemin du fichier de configuration :

Ca démarre ! Si, depuis un autre terminal, on essaie de se connecter sur le port 10017, on verra le message suivant :

Ca fonctionne ! Comment ça, ça fonctionne ? Pas du tout, il me dit « Internal Error » le bougre ... Oui, mais c'est tout à fait normal, car dkimproxy.out étant un... proxy (merci de suivre), il essaie de se connecter au relais Postfix (le paramètre « relay ») de la configuration, que nous n'avons pas encore configuré. Alors allons-y.

4.2 Relayer de Postfix vers DKIMProxy

4.2.1 Petit rappel concernant Postfix

Il s'agit d'un serveur SMTP écrit par Wietse Venema en remplacement de Sendmail. Son architecture interne se veut modulaire, et c'est bien là ce qui va nous intéresser, car nous allons utiliser un module de Postfix pour transférer les e-mails sortants à dkimproxy.out. La mécanique interne de Postfix est trop complexe pour être couverte par cet article. Toutefois, il est important de détailler deux concepts :

4.2.1.1 La prise en charge des e-mails

La plupart des serveurs SMTP reçoivent tous les e-mails à traiter sur le port TCP/25. Ici, cela n'est pas possible car, si un e-mail venant de l'extérieur doit effectivement pouvoir arriver sur le port 25 (sinon, il n'arrivera pas), nous allons devoir utiliser un autre port pour les soumissions locales. Pourquoi ? Revenons au schéma d'architecture en figure 1. Si dkimproxy.out était sur le chemin de TOUS les e-mails, qu'ils soient des soumissions ou des réceptions, alors il appliquerait une signature DKIM à tous les e-mails provenant de mondomaine.net. Cela n'est pas acceptable car, dans ce cas-là, une personne de l'extérieur se faisant passer pour jeanpierretroll@mondomaine.net pourrait envoyer un e-mail à jeankevin@mondomaine.net avec une signature DKIM valide. Nous allons donc dissocier la soumission de la réception.

4.2.1.2 La déclaration des services

Postfix dispose d'un fichier master.cf, qui contient tous les services démarrées par Postfix et éventuellement les services externes. Ce fichier permet de gérer l'architecture modulaire de Postfix. Et c'est ici que nous allons déclarer notre service de soumission et notre service de réception.

4.2.2 Configuration

Je suppose ici que vous avez une installation de Postfix fonctionnelle sous Debian. Debian n'est pas indispensable, mais vous aurez besoin d'adapter les chemins pour une autre distribution.

Dans le fichier /etc/postfix/master.cf, on va ajouter deux sections : une pour la soumission des e-mails, écoutant sur le port TCP/587 et auquel les utilisateurs devront se connecter, et une pour la connexion relay venant de dkimproxy.out, écoutant donc sur le port 10018. Le module de submission possédera un paramètre de content_filter vers dkimproxy.out.

C'est tout pour la configuration de Postfix. Redémarrons le serveur, ainsi que dkimproxy.out.

Et retentons la connexion à dkimproxy.out :

Si je configure mon webmail pour me connecter sur le port 587 pour l'envoi de mails, et réalise une tentative d'envoi depuis jeankevin@mondomaine.net vers jeanpierretroll@gmail.com, alors ce cher Jean-Pierre recevra un e-mail avec la signature suivante :

Et dans la console de dkimproxy.out, on voit la ligne suivante :

4.3 Exporter sa clé publique

Oui, parce que, jusque-là, Jean-Pierre reçoit bien des e-mails contenant une signature, mais il est incapable de la vérifier. En effet, nous avons encore à configurer le serveur Bind pour servir la clé publique via le DNS.

Encore une fois, je ne vais pas rentrer dans les détails de la configuration de Bind9. L'opération nous concernant n'est toutefois pas très compliquée. Il faut créer dans le fichier de zone mondomaine.net deux enregistrements comme suit :

Ces deux lignes reprennent les éléments que nous avons déjà définis lors de la mise en place de dkimproxy.out. La seconde ligne commence avec la valeur de selector et contient la clé publique dans le tag k=. On redémarre la zone DNS avec ces valeurs (n'oubliez pas d'incrémenter le numéro de série) et on réalise un petit test avec dig :

Dig nous confirme que la clé publique est bien servie par le DNS. Jean-Pierre est content (non, sans déconner, ça lui arrive) car il peut maintenant vérifier la signature du domaine de Jean-Kevin.

Et Jean-Kevin dans tout cela ? Eh bien lui, il aimerait bien pouvoir vérifier la signature de Jean-Pierre qui, comme il utilise une adresse gmail, dispose déjà de la signature DKIM. Alors pour cela, on va passer à l'étape suivante et la mise en place de dkimproxy.in.

5. Vérifier les signatures des e-mails entrants

Cette dernière partie va, en fait, être beaucoup plus légère que les précédentes, car la validation des signatures ne demande que peu de travail du côté du récepteur. On va, dans un premier temps, démarrer dkimproxy.in avec seulement deux paramètres (son adresse d'écoute et son adresse de relais), puis on va configurer Postfix pour qu'il lui transmette les messages entrants sur son port 25.

Comme vu en figure 2, tous les mails entrants sur le port 25 de Postfix passeront donc par dkimproxy.in. Ce dernier requêtera si besoin la clé publique via le DNS et vérifiera la ou les signatures présentes dans les headers DKIM-Signature. Enfin, il ajoutera deux headers au corps de l'e-mail :

- Authentication-Results : ce header est normé par la RFC 5451, il contient le résultat de l'opération de validation.

- X-DKIM-Authentication-Results : un header propre à DKIMproxy, qui va contenir pass ou fail selon le résultat de l'opération.

5.1 dkimproxy.in

Revenons dans notre répertoire ~/dkimproxy/etc. Nous allons simplement y créer un fichier dkimproxy_in.conf contenant les lignes :

Et nous lançons le programme de la même façon que précédemment :

5.2 Et finalement, Postfix

De même que précédemment, nous allons modifier le fichier master.cf pour y ajouter les points de sortie et d'entrée vers dkimproxy.in. En fait, Postfix reçoit les mails entrants dans le module smtpd et c'est dans ce module que nous allons définir un proxy_filter vers dkimproxy.in.

On pourrait ajouter, après avoir récupéré l'e-mail de dkimproxy.in, un passage dans Spamassassin via la directive content_filter, mais ce n'est pas le sujet de l'article. Une fois que ces paramètres sont sauvegardés, il convient de relancer Postfix et d'admirer le résultat dans les headers des e-mails reçus.

6. User Experience

La partie technique de l'architecture est maintenant en place. Il convient cependant de regarder plus en détail le fonctionnement de DKIM, car la partie technique ne fait pas tout. En effet, DKIM met à disposition du destinataire une information dont le niveau de confiance varie. Dans un premier temps, il convient, ou pas, d'accorder sa confiance au domaine de l'auteur. On pourra ainsi refuser de faire confiance à MyHomeServerInTheBasement.org sous le prétexte que les utilisateurs du système de messagerie ne sont pas authentifiés correctement, et qu'ainsi, n'importe qui peut envoyer des e-mails depuis ce domaine.

Mais un aspect plus complexe à gérer est la confiance que l'on accorde aux signatures réalisées par des tiers. En effet, YahooGroup va, par exemple, apposer une signature DKIM tout à fait valide aux abonnés d'un groupe envoyant des e-mails. Ainsi, si Jean-Kevin envoie un e-mail à linuxmag@yahoogroup.com, Jean-Pierre le recevra avec une signature DKIM valide. Toutefois, cette signature n'a en aucun cas été réalisée par le domaine de Jean-Kevin, mais par le domaine de Yahoo!. Quel niveau de confiance accorder alors à ce type de signature ? Et comment le représenter ? Les différentes RFC ne donnent pas de réponse définitive et laissent cela à l'appréciation des administrateurs de chaque domaine.

6.1 Dans un webmail: Roundcube

Roundcube dispose d'un plugin afin d'afficher le résultat du header Authentication-Results au moyen d'une icône appropriée. Modifié par votre serviteur, ce plugin permet de déterminer si la signature a été réalisée par le domaine de l'auteur ou par un domaine tiers. L'utilisateur final verra ainsi apparaître quelque chose de similaire à la figure 3.

Conclusion

DKIM permet clairement d'améliorer la confiance des utilisateurs dans les communications par e-mail. Il n'est toutefois pas au terme de son développement et de nouvelles RFC fleurissent chaque mois (comme Author Domain Signing Practices, RFC 5617, qui permet d'annoncer via DNS la politique DKIM d'un domaine). A n'en pas douter, l'adoption de DKIM par les plus grands fournisseurs de services e-mails va pousser sa progression vers les clients de messagerie et les webmails. Encore peu de domaines d'entreprises et d'organismes signent et valident leurs e-mails avec DKIM. Espérons que des articles comme celui-ci aideront à faciliter son adoption.