Signer et Vérifier ses e-mails avec DKIM

Magazine
Marque
GNU/Linux Magazine
Numéro
125
|
Mois de parution
mars 2010
|


Résumé
DomainKeys Identified Mail est une alternative aux systèmes d'authentification forte des e-mails que sont PGP et S/MIME. DKIM permet non pas d'authentifier l'auteur d'un e-mail, mais plutôt le domaine auquel il appartient. DKIM est le fils légitime de DomainKeys de Yahoo! et  Identified Internet Mail de Cisco.

Body

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) :

DKIM-Signature: v=1; a=rsa-sha256;c=relaxed/relaxed;d=gmail.com;s=gamma;

h=domainkey-signature:mime-version:received:date:message-id:subject:from:to:

content-type;bh=+h+GzK7vCkJwfpUPIHylR/vBv4qM5Cu1dYDVBxcvmqM=;b=Bhj

1OhxJOnKBzu0/6ooJGzYJRfR69wNYQOJcQiJmnK+eMpicdxI8uWlHw+E6NdHBt0f6dRXe

VCSLM2wjK41ZaFdFObKZNczOl86LyannP3/L806fuv1v99Xw1IiHhLAxUYA+7mE3vkSKAJ

3Y6aCFNGHXkze0uJVtD6MLFR3Sz90=

   

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

signature

Architecture de signature : Jean-Kevin envoie un e-mail vers l'extérieur. Postfix le prend en charge, puis le passe à DKIMProxy. Ce dernier le signe avec la clé privée du domaine mondomaine.net, stocke la signature dans le header DKIM-Signature et renvoie le mail signé à Postfix, qui le diffuse sur Internet vers son destinataire.

verification

Architecture de verification : Jean-Kevin reçoit un e-mail de l'extérieur. Postfix le prend en charge, puis le passe à DKIMProxy, qui requête via DNS la clé publique du domaine ayant apposé la signature, puis vérifie cette signature. Il stocke le résultat de la vérification dans le header Authentication-Results et renvoie le mail à Postfix, qui le stocke dans le serveur Imap. Jean-Kevin n'a plus qu'à consulter ses e-mails comme il le fait normalement.

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.

root@zerhuel:~# apt-get install libmail-dkim-perl

Pour DKIMproxy :

julien@zerhuel:~$ wget http://dkimproxy.sourceforge.net/dkimproxy-1.3beta1.tar.gz

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

julien@zerhuel:~/dkimproxy-1.3beta1$ mkdir ~/dkimproxy

julien@zerhuel:~/dkimproxy-1.3beta1$ ./configure --prefix=~/dkimproxy

[ ... ]

julien@zerhuel:~/dkimproxy-1.3beta1$ make install

[ ... ]   

julien@zerhuel:~/dkimproxy-1.3beta1$ cd ~/dkimproxy

julien@zerhuel:~/dkimproxy$ ls -l

total 16

drwxr-xr-x 2 julien julien 4096 jan 26 12:10 bin

drwxr-xr-x 2 julien julien 4096 jan 26 12:10 etc

drwxr-xr-x 3 julien julien 4096 jan 26 12:10 lib

drwxr-xr-x 3 julien julien 4096 jan 26 12:10 share

    

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.

julien@zerhuel:~/dkimproxy$ cd etc

julien@zerhuel:~/dkimproxy$ vim dkimproxy_out.conf

# ip et port pour recevoir les emails de postfix

listen 127.0.0.1:10017

# ip et port vers lesquels on renvoi les emails pour postfix

relay 127.0.0.1:10018

# le fichier qui contient les règles de signature

sender_map /home/julien/dkimproxy/etc/sender_map

    

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 :

julien@zerhuel:~/dkimproxy$ vim sender_map

mondomaine.net dkim(s=mondomaine-dkim,d=mondomaine.net,c=relaxed,a=rsa-sha256,key=/home/julien/dkimproxy/etc/private.key)

   

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 :

julien@zerhuel:~/dkimproxy/etc$ openssl genrsa -out private.key 1024

Generating RSA private key, 1024 bit long modulus

.............++++++

.++++++

e is 65537 (0x10001)

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 :

julien@zerhuel:~/dkimproxy/etc$openssl rsa -in private.key -pubout -out public.key

writing RSA key

julien@zerhuel:/home/julien/dkimproxy/etc$ cat public.key

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrbcmFbR41RmAZ3GfahHhxFz9I

69JpmEcqariKMw40iTLQ3vIAHrbtwe3/HUtJD+7o0tRE7l5vCgIBA2tw7V5ohMDM

jwYTNMsf4zpZ11bgVoq4Yk+TOOuNmi0bEJJt/PRpdUO2ktAdUc0kG0BzWoDIzegD

18FIO8cgATws86k12QIDAQAB

-----END PUBLIC KEY-----

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 :

julien@zerhuel:/home/julien/dkimproxy/etc$ cd ../bin/

julien@zerhuel:/home/julien/dkimproxy/bin$ ls

dkimproxy.in dkimproxy.out dkim_responder.pl dkimsign.pl dkimverify.pl

julien@zerhuel:/home/julien/dkimproxy/bin$ ./dkimproxy.out --conf_file=/home/julien/dkimproxy/etc/dkimproxy_out.conf

Becoming sub class of "Net::Server::PreFork"

2010/01/26-12:57:07 main (type MySmtpProxyServer) starting! pid(22144)

Binding to TCP port 10017 on host 127.0.0.1

Group Not Defined. Defaulting to EGID '1000 4 20 24 25 29 44 46 1000 1004 1005 1664'

User Not Defined. Defaulting to EUID '1000'

 

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

julien@zerhuel:~$ nc localhost 10017

421 Internal error (Next hop is down)

 

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.

# le service submission permet d'envoyer des mails en passant par la signature dkim

submission inet n       -       -       -       -       smtpd

   -o receive_override_options=no_address_mappings

   -o content_filter=dksign:[127.0.0.1]:10017

   -o smtpd_tls_security_level=may

   -o smtpd_sasl_auth_enable=yes

   -o smtpd_client_restrictions=permit_sasl_authenticated,permit_mynetworks,reject

[...]

#receive from dkimproxy after signature

127.0.0.1:10018 inet    n       -       n       -       10      smtpd

-o content_filter=

   -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks

   -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject

   -o smtpd_authorized_xforward_hosts=127.0.0.0/8

  

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

root@zerhuel:/etc/postfix# /etc/init.d/postfix restart

Stopping Postfix Mail Transport Agent: postfix.

Starting Postfix Mail Transport Agent: postfix.

root@zerhuel:/etc/postfix# exit

julien@zerhuel:/etc/postfix$ cd /home/julien/dkimproxy/bin/

julien@zerhuel:/home/julien/dkimproxy/bin$ ./dkimproxy.out --conf_file=../etc/dkimproxy_out.conf

Becoming sub class of "Net::Server::PreFork"

2010/01/26-13:21:13 main (type MySmtpProxyServer) starting! pid(22497)

Binding to TCP port 10017 on host 127.0.0.1

Group Not Defined. Defaulting to EGID '1000 4 20 24 25 29 44 46 1000 1004 1005 1664'

User Not Defined. Defaulting to EUID '1000'

Et retentons la connexion à dkimproxy.out :

julien@zerhuel:~$ nc localhost 10017

220 smtp.mondomaine.net

 

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 :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=mondomaine.net; h=

 mime-version:date:from:to:subject:message-id:content-type:

 content-transfer-encoding; s=mondomaine-dkim; bh=g3zLYH4xKxcPrHO

 pQcnk/GaJedfustWU5uGs=; b=QeUaXiEgRznE/WlJF4mf6ejD7a+cT8Wf6Ag6+s

 3BupDZzwXgKEwy9s6PIK6KZbPk8ana6aqLHeOS662McJQQOYLzvTb43Ws73KHfVz

 wtXdDQ6Vh1+kVQ4G52ruEAEUoh8ayyfLctwbJUK/IdRPdSTp+7vOrVj9s1cb5aOY

 LEpxo=

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

dkimproxy.out[22515]: DKIM signing - signed; message-id=<68d1e42906c74bb3f7ae9cd0bb93a204@localhost>, signer=<@mondomaine.net>, from=<jeankevin@mondomaine.net>

DKIM signing - signed; message-id=<68d1e42906c74bb3f7ae9cd0bb93a204@localhost>, signer=<@mondomaine.net>, from=<jeankevin@mondomaine.net>

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 :

root@zerhuel:/etc/bind# vim mondomaine.net.db

[ ... ]

;DKIM pour la signature des mails

_domainkey.mondomaine.net.                   IN      TXT "k=rsa; t=s; o=-;"

mondomaine-dkim._domainkey.mondomaine.net.   IN      TXT "k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrbcmFbR41RmAZ3GfahHhxFz9I69JpmEcqariKMw40iTLQ3vIAHrbtwe3/HUtJD+7o0tRE7l5vCgIBA2tw7V5ohMDMjwYTNMsf4zpZ11bgVoq4Yk+TOOuNmi0bEJJt/PRpdUO2ktAdUc0kG0BzWoDIzegD18FIO8cgATws86k12QIDAQAB;"

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 :

julien@zerhuel:~$ dig txt mondomaine-dkim._domainkey.mondomaine.net @localhost

[ ... ]

;; ANSWER SECTION:

mondomaine-dkim._domainkey.mondomaine.net. 259200 IN TXT "k=rsa\; t=s\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrbcmFbR

41RmAZ3GfahHhxFz9I69JpmEcqariKMw40iTLQ3vIAHrbtwe3/HUtJD+7o0tRE7l5vCgIBA2tw7V5ohMDMjwYTNMsf4zpZ11bgVoq4Yk+TOOuNmi0bEJJt/P

RpdUO2ktAdUc0kG0BzWoDIzegD18FIO8cgATws86k12QIDAQAB;"

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.

Authentication-Results: zerhuel.domaine.net; dkim=pass header.i=@messiah.edu; domainkeys=pass header.from=jlong@messiah.edu

- 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 :

julien@zerhuel:~/dkimproxy$ vim dkimproxy_in.conf

# Adresse d'écoute pour la réception des mails entrants

listen    127.0.0.1:10015

# Adresse de retour vers Postfix

relay     127.0.0.1:10016

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

julien@zerhuel:/home/julien/dkimproxy/bin$ ./dkimproxy.in --conf_file=../etc/dkimproxy_in.conf

Becoming sub class of "Net::Server::PreFork"

2010/01/26-14:32:55 main (type MySmtpProxyServer) starting! pid(23179)

Binding to TCP port 10005 on host 127.0.0.1

Group Not Defined. Defaulting to EGID '1000 4 20 24 25 29 44 46 1000 1004 1005 1664'

User Not Defined. Defaulting to EUID '1000'

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.

root@zerhuel:~# vim /etc/postfix/master.cf

smtp inet n - - - - smtpd

-o smtpd_proxy_filter=127.0.0.1:10015 #dkim verify

   

   [ ... ]

   

#reçoit les retours de dkimproxy.in

127.0.0.1:10016 inet    n       -       n       -       10      smtpd

-o content_filter=

  -o smtpd_authorized_xforward_hosts=127.0.0.0/8

  -o receive_override_options=no_unknown_recipient_checks

  -o smtpd_recipient_restrictions=permit_mynetworks,reject

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.

dkimverified

Capture du résultat du module DKIMStatus dans Roundcube

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.


Par le même auteur

Mozilla InvestiGator : quand vos serveurs se prennent pour Sherlock Holmes

Magazine
Marque
MISC
HS n°
Numéro
11
|
Mois de parution
juin 2015
|
Domaines
Résumé

Avec suffisamment de serveurs à surveiller, l'investigateur expérimenté se retrouve souvent à chercher l'aiguille dans la botte de foin. Pour peu que l'infrastructure soit hétérogène, la recherche peut prendre plusieurs heures et souvent ne pas couvrir l’intégralité du domaine. Si vous êtes familier de ce problème et que PSSH ne fait plus l'affaire, la suite devrait vous intéresser. Une note toutefois : les personnages et situations qui suivent sont purement fictifs et ne représentent pas forcément la routine des investigations réalisées par l'auteur dans le cadre de son activité.

TLS, état des lieux côté serveur

Magazine
Marque
MISC
Numéro
72
|
Mois de parution
mars 2014
|
Domaines
Résumé
Configurer TLS côté serveur est difficile. 19% des sites en HTTPS proposent toujours SSLv2. 28% vont négocier une session avec DES_CBC_SHA et ses clés de 56 bits si le client le demande. Il y a un peu plus d'un an, la majorité des experts en SSL/TLS recommandaient RC4 à AES. Quelques mois plus tard, c'était l'inverse. Une partie de la communauté cryptographique supporte Perfect Forward Secrecy, alors qu'une autre le refuse pour cause de lenteur. Il existe même des doutes sur le niveau réel de sécurité fourni par AES-256, par rapport à la version 128 bits. Ajoutons à cela une bonne dose de perte de confiance dans les standards existants, en particulier depuis que l'on sait Dual_EC_DRBG backdoored, et nous voici avec une parfaite recette de confusion et d'incohérence. Les désaccords sur la meilleure façon de configurer HTTPS sont nombreux. Et si le débat est utile aux experts, il est presque impossible pour un non-initié de naviguer dans la nébuleuse TLS, et d'en extraire une configuration de référence.

Postscreen, l'exterminateur de zombies

Magazine
Marque
GNU/Linux Magazine
Numéro
147
|
Mois de parution
mars 2012
|
Domaines
Résumé
Il y a plus d'un an de cela, je vous présentais dans ces pages un formidable répulsif à Sus scrofa domesticus, j'ai nommé DSPAM. Au même moment, notre rédacteur en chef préféré m'avouait sa passion déraisonnable et certainement bien personnelle pour ce formidable résidu de cuisine qu'est le pâté de jambon, communément appelé Spam de mon côté de l'Atlantique. Fort de ma machine à tokens dopée aux amphétamines (toujours DSPAM), je m'empressais de pondérer les propos du malheureux finnois d'une statistique bien négative, et éventuellement repoussais lesdits échanges aux confins de mon dossier spam (sans pour autant bannir complètement l'intéressé, dont la conversation est toujours des plus constructive et bienvenue). Heureux de ma vie tranquille, lisant plaisamment mes courriels sans l'once d'une distraction viagriarienne « enlarge your peniche » pendant presque un an, je relâchais donc ma garde. Mais le spammer est malin, et sous prétexte de bricoler des bidules électroniques, le voilà qui libérait toute une armée de zombies spammers prêts à délivrer leurs contenus dégoûtants dans les entrailles de l'Internet.

Développement web en Perl avec Mojolicious

Magazine
Marque
GNU/Linux Magazine
Numéro
138
|
Mois de parution
mai 2011
|
Résumé
Cela fait maintenant quelques années que Perl, en tant que langage de développement web, se fait discret. Beaucoup de développeurs l'utilisent toujours, mais la (relativement récente) vague Python/Ruby s'est ajoutée à PHP pour occuper l'essentiel du Web. En tant que sysadmin, j'ai une tendance naturelle au conservatisme : si ça marche, ne touche à rien. Bon, évidemment, ça ne s'applique pas partout, mais quand il s'agit de programmation, j'aime bien me dire que Perl fera le boulot au moins aussi bien, et peut-être mieux, que d'autres langages.J'étais donc curieux du petit dernier de la communauté Perl : le framework MVC Mojolicious. Petit frère du très reconnu Catalyst, Mojolicious est un projet récent qui essaie de corriger certains mécontentements que les moines de Perl ont pu ressentir en utilisant Catalyst. Dans la mesure où les robes en bure, hormis le fait que ça gratte, ce n'est pas ma spécialité (et n'étant pas développeur de nature), cet article n'est pas un rapport d'expertise sur Perl et les frameworks MVC, mais plutôt une introduction au développement web avec Perl et Mojolicious 1.1.

Combattre efficacement le spam avec DSPAM

Magazine
Marque
GNU/Linux Magazine
Numéro
132
|
Mois de parution
novembre 2010
|
Résumé
Vous avez déjà goûté du spam ? Je veux dire, du vrai spam. Celui qui est servi en boîtes rectangulaires et a vaguement la couleur du jambon. On m’en a servi, une fois, lors d’un réveillon, et je peux vous assurer que ce n’est vraiment pas bon ! Mais le spam dont on va parler ici est différent, plus électronique, mais tout aussi dégoûtant.Combattre le spam est probablement la tâche la plus complexe du postmaster. Les techniques sont nombreuses et il est indispensable de les cumuler pour obtenir un résultat pertinent.