% $Id: lmap.tex,v 1.4 2004/09/14 08:05:57 bortzmeyer Exp $ \documentclass[a4paper,twoside]{article} \usepackage[latin1]{inputenc} \usepackage{bortzmeyer-utils} \usepackage[french]{babel} \usepackage{fancyhdr} \usepackage{lastpage} \usepackage[smaller]{acronym} \usepackage{palatino} \newcommand{\spam}[0]{\foreign{spam} } \newcommand{\spams}[0]{\foreign{spams} } \newcommand{\Spam}[0]{\foreign{Spam} } \newcommand{\spamming}[0]{\foreign{spamming} } \newcommand{\spammer}[0]{\foreign{spammeur} } \newcommand{\spammers}[0]{\foreign{spammeurs} } \newcommand{\optin}[0]{\foreign{opt-in} } \newcommand{\optout}[0]{\foreign{opt-out} } \newcommand{\phising}[0]{\foreign{phising} } \setcounter{tocdepth}{1} \pagestyle{fancy} \fancyhead[C]{\thepage/\pageref{LastPage}} \fancyhead[LE]{\textbf{AFNIC}} \fancyhead[RO]{\textbf{AFNIC}} \fancyhead[LO]{} \fancyhead[RE]{} \fancyfoot[LE]{Sender-ID - Contribution \textbf{AFNIC} au groupe de contact contre le \spam} \fancyfoot[LO]{Sender-ID - Contribution \textbf{AFNIC} au groupe de contact contre le \spam} \fancyfoot[C]{} \title{Sender-ID, SPF et leur famille : authentifier l'émetteur de courrier via le DNS} \author{Stéphane Bortzmeyer\\ \url{}\\ Représentant l'AFNIC au groupe de contact contre le \spam} \date{14 septembre 2004} \begin{document} \maketitle \abstract{On sait que le système de courrier électronique sur Internet et notamment son protocole \ac{SMTP} n'authentifient aucune des informations reçues depuis un autre serveur de courrier. Cette absence d'authentification facilite la tâche des \spammers ou bien des usurpateurs d'identité\footnote{Ce qu'on nomme le \phising}. Une famille de protocoles, comme \ac{SPF} et \ac{Sender-ID}, a été développée pour permettre une authentification des émetteurs de courrier, en publiant dans le \ac{DNS} la liste des serveurs autorisés pour un domaine. Ces protocoles sont d'ores et déjà en cours de déploiement et sont susceptibles de modifier profondément le fonctionnement du courrier électronique. Cet exposé explique le fonctionnement de ces protocoles, pour un public non technique.} \section{Rappels} Le protocole utilisé pour le transport du courrier sur Internet, \ac{SMTP}, normalisé dans le \rfc{2821}, a un défaut : il fait entière confiance à l'émetteur du message quant à l'authenticité des adresses d'expédition. Avant de s'exclamer que les auteurs de \ac{SMTP} étaient vraiment imprudents, il faut se rappeler que c'est l'architecture qu'ils ont conçu qui a assuré le succès de l'Internet et le développement formidable de la messagerie électronique, alors que des normes peut-être plus sûres, mais extrêmement rigides, n'ont jamais été déployées et donc évidemment jamais utilisées pour le \spam. Le fonctionnement du courrier sur Internet repose sur trois piliers : \begin{enumerate} \item Une architecture (qui n'a jamais été décrite par écrit) où il n'y a pas d'arrangement préalable entre les parties, ni d'autorité centralisée. Chaque serveur de courrier envoie potentiellement à chaque autre serveur. \item Un protocole, \ac{SMTP} \item Un format des messages, souvent connu par le numéro du \ac{RFC}, 2822, qui spécifie un certain nombre d'en-têtes au message (\computer{From}, qui indique l'expéditeur, \computer{Date}, et des en-têtes plus techniques, destinés au déboguage et à l'enquête, comme \computer{Received}, qui indique les serveurs traversés). \end{enumerate} \subsection{Architecture} Il est courant que plusieurs serveurs successifs, appartenant à des organisations différentes, soient utilisés pour que le message atteigne sa destination. La figure \ref{architecture} montre un tel cas. \begin{figure} \ifpdf \includegraphics[scale=0.70]{email.pdf} \else \includegraphics[scale=0.80]{email.eps} \fi \caption{Architecture du courrier électronique\label{architecture}} \end{figure} \subsection{Protocole\label{smtp}} Lors d'une session \ac{SMTP} entre deux serveurs, l'appelant transmet à l'appelé l'adresse de l'expéditeur. C'est ce qu'on appelle l'enveloppe (en anglais, \foreign{enveloppe from} ou bien \computer{MAIL FROM} ou encore \computer{2821 FROM}, du numéro du \ac{RFC}. La figure \ref{smtp-session} montre une session SMTP typique, qui correspond au scénario \ref{scenar-forward}. On y voit la transmission de l'enveloppe (notamment le \computer{MAIL FROM}) et le tout début du message. \begin{figure} \begin{info} Récepteur: 220 afnic.fr ESMTP server ready Émetteur : EHLO mail.u-paris.fr Récepteur: 250-afnic.fr Récepteur: 250 SIZE Émetteur : MAIL FROM: Récepteur: 250 sender ok Émetteur : RCPT TO: Récepteur: 250 recipient ok Émetteur : DATA Récepteur: 354 okay, send message Émetteur : Resent-From: jerome@u-paris.fr Émetteur : (Autres en-têtes puis corps du message) \end{info} \caption{Une session SMTP\label{smtp-session}} \end{figure} \subsection{Format} Voici (figure \ref{message}) un message tel qu'il apparait sur le réseau. Naturellement, la plupart des logiciels de courrier le présentent de manière plus adaptée à l'utilisateur. Le message est séparé en deux parties, les en-têtes, structurés selon le \rfc{2822} et un corps qui est typiquement du texte (c'est la partie après la ligne vide). On ne voit pas l'enveloppe ici, elle est gérée par \ac{SMTP} (voir section \ref{smtp}) et typiquement jamais affichée, comme si votre courrier papier était toujours ouvert avant de vous être transmis. \begin{figure} \begin{info} Received: from localhost (net-206-66.noicomnet.it [194.153.206.66]) by rs2.bips.noicomnet.it (8.11.6/8.11.6) with SMTP id i8A97Rr24581; Fri, 10 Sep 2004 11:07:27 +0200 Subject: Re: [governance] selection process From: Vittorio Bertola To: avri@acm.org Cc: governance@lists.cpsr.org Date: Fri, 10 Sep 2004 11:06:31 +0200 If we can make it happen in time, I agree that this could be a good solution. But in this case ... \end{info} \caption{Un message\label{message}} \end{figure} Si on suspecte un faux, il faut analyser ces en-têtes, qui sont souvent mal documentés et faire appel à diverses bases de données en ligne comme celles des \ac{RIR}. C'est actuellement un travail d'expert que le destinataire ne peut pas faire seul. \subsection{Identités\label{identite}} Les sections précédentes ont montré que la question de l'authentification allait être un peu plus complexe que prévu. En effet, il existe plusieurs identités lors de l'envoi et de la réception d'un message et il n'est pas évident de savoir laquelle authentifier. Voyons quelques scénarios. \subsubsection{Le cas le plus courant\label{scenar-simple}} \url{jean@example.fr} écrit à \url{nicole@laposte.net}. C'est le cas le plus classique et le plus simple. Les serveurs de messagerie de la Poste recevront le message depuis les serveurs de messagerie d'Example. Les différentes identités (\computer{From} de l'en-tête, \computer{MAIL FROM} de l'enveloppe) seront les mêmes, \url{jean@example.fr}. \subsubsection{Les listes de diffusion} Maintenant, \url{jean@example.fr} écrit à la liste de diffusion \url{cheval@cru.fr}, où se retrouvent les amateurs de chevaux, parmi lesquels \url{nicole@laposte.net}. Lorsque le message sera reçu par les serveurs de messagerie de la Poste, le \computer{From} de l'en-tête vaudra toujours \url{jean@example.fr} alors que le \computer{MAIL FROM} de l'enveloppe vaudra quelque chose comme \url{cheval-list-admin@cru.fr}. Les identités seront différentes. \subsubsection{Suivi automatique\label{scenar-forward}} Inlassable, \url{jean@example.fr} écrit à \url{jerome@u-paris.fr}. Mais ce dernier a quitté l'Université et travaille désormais à l'AFNIC. Il a mis en place un suivi automatique du courrier\footnote{Par exemple par le biais d'un fichier \url{.forward} sur une machine Unix} vers \url{jerome@afnic.fr} et le message arrivera donc sur les serveurs de l'AFNIC avec un \computer{MAIL FROM} de l'enveloppe inchangé, \url{jean@example.fr}, mais sans venir des serveurs d'Example, puisque le message a été retransmis par les serveurs de l'Université. \subsubsection{Un travailleur nomade\label{scenar-nomade}} \url{jean@example.fr} est à un congrès à Washington. Il envoie du courrier depuis l'hôtel en utilisant le serveur de messagerie de l'hôtel. Le \computer{MAIL FROM} de l'enveloppe sera fixé par l'hôtel, par exemple \url{guest-services@hotel.com} et le \computer{From} de l'en-tête sera \url{jean@example.fr} . \subsubsection{Envoyez donc cet article à un ami\label{scenar-sendfriend}} \url{jean@example.fr} lit un article sur le site Web du Quotidien du Cheval et il veut le transmettre via le classique bouton ``Envoyez à un ami''. Lorsqu'il le fait, on lui demande son adresse de courrier. Le message partira avec \computer{From} de l'en-tête à \url{jean@example.fr} et un champ \computer{Sender} de l'en-tête à \url{webmaster@cheval.fr}, qui identifiera le site Web\footnote{Dans la réalité, les sites comme celui du Quotidien du Cheval utilisent des techniques très variées pour gérer ce problème, en raison de l'absence de règles claires. La technique présentée ici avec le champ \computer{Sender} n'est qu'une des techniques possibles.}. \subsection{Jusqu'ici, tout allait bien} Dans tous les scénarios cités plus haut, le serveur émetteur pouvait mettre ce qu'il voulait, aucune authentification n'étant effectuée. Mais aujourd'hui, cette absence d'authentification est largement utilisée par des méchants. Citons deux exemples courants, un \spammer et un escroc. \subsubsection{Les délinquants se masquent} La sensibilité (justifiée) des utilisateurs au problème du \spam est telle que la plupart des \spammers mentent sur leur identité. Soit ils veulent échapper aux poursuites judiciaires, si leur action est illégale, soit ils veulent passer les filtres qu'ont mis en place les \ac{FAI}. Si on sait que \dns{amazon.com} est dans beaucoup de listes blanches, il est tentant de se faire passer pour Amazon, c'est ce que l'on voit sur la figure \ref{spam-amazon}. Le nom de domaine dans le \computer{From} est mensonger\footnote{Le message de la figure \ref{spam-amazon} comprend d'autres mensonges comme le faux numéro de version d'Outlook, que SpamAssassin a su détecter. L'utilisation d'Outlook fait penser à un utilisateur individuel alors que les \spams sont typiquement envoyés par des logiciels spécialisés.}. \begin{figure} \begin{info} Received: from (146.82.138.7) [211.216.136.75] by master.debian.org with smtp (Exim 3.35 1 (Debian)) id 1C5ATe-0005Fu-00; Wed, 08 Sep 2004 16:59:43 -0500 Received: from (HELO xpv) [99.148.158.201] by 146.82.138.7 with ESMTP id 48155C866E2; Wed, 08 Sep 2004 22:58:44 +0100 Message-ID: From: Subject: (Un texte en coréen) To: benoit@debian.org Date: Wed, 08 Sep 04 22:58:44 GMT X-Mailer: Microsoft Outlook Express 5.50.4522.1200 \end{info} \caption{Un spam prétendument envoyé depuis Amazon\label{spam-amazon}} \end{figure} Ces mensonges garantissent ainsi au \spammer un quasi-anonymat. \subsubsection{Ayez confiance, tapez votre mot de passe} Une autre forme d'usurpation d'identité se produit lorsque l'envoyeur tente de vous faire croire que le message vient d'une grande institution respectable, une banque, par exemple, et va tenter d'obtenir de vous des informations confidentielles. C'est le \phising. Typiquement, le message semble envoyé depuis \dns{serious-bank.com}, la page Web qu'il indique ressemble à celle de Big Bank et le mot de passe de votre compte que vous taperez atterrira chez l'usurpateur. La figure \ref{phising-ebay} montre un tel exemple, où la première victime est le site de vente en ligne eBay. Une astuce HTML permet de déguiser l'adresse du lien pour ceux qui regardent le message avec un logiciel de courrier qui comprend HTML. \begin{figure} \begin{info} Received: from s9009.hostcentric.net (s9009.hostcentric.net [66.40.7.4]) by mx1.nic.fr (Postfix) with ESMTP id 288D094005 for ; Mon, 6 Sep 2004 13:46:33 +0200 (CEST) Received: (qmail 18974 invoked by uid 48); 6 Sep 2004 11:36:31 -0000 Date: 6 Sep 2004 11:36:31 -0000 To: nic@nic.fr Subject: Security Measures (SafeHarbor) (KMM05092004618V76837L0KM) From: CustomerSupport@eBay.com Dear eBay member We recently noticed one or more attempts to log in to your eBay account from a foreign IP address and we have reasons to belive that your account was hijacked by a third party without your authorization. If you recently accessed your account while traveling,the unusual log in attempts may have been initiated by you. However,if you are the rightfull holder of the account, click on the link below, fill the form and then submit as we try to verify your identity. http://66.132.227.169/e/a/signin.ebay.com/aw-cgi/index2.htm \end{info} \caption{Une usurpation : le message est prétendument envoyé depuis eBay\label{phising-ebay}} \end{figure} \subsubsection{Aux grands maux, les grands remèdes} Le problème du \spam et celui du \phising sont tels que beaucoup d'acteurs sont prêts à casser des \oe{}ufs pour faire l'omelette, selon un cliché qui revient très fréquemment dans les discussions sur la lutte anti-spam. Ils sont prêts à imposer une authentification des domaines émetteurs. Avant de voir \ac{SPF} et \ac{Sender-ID}, voyons les autres solutions. \section{Solutions plus anciennes} L'authentification des individus émetteurs existe depuis très longtemps, via des techniques comme \ac{PGP}, normalisée dans le \rfc{2440}. Très efficace, elle est utilisée par tous ceux qui veulent faire des annonces incontestables (découverte d'une faille de sécurité par un \ac{CERT}, par exemple). Mais elle n'a jamais décollé dans le grand public. Toutes les techniques bâties sur la cryptographie ont connu le même sort : trop lourdes, trop difficiles pour l'utilisateur et nécessitant parfois des infrastructures chères et complexes comme les \ac{PKI}. \section{Authentification dans le DNS} On envisage donc aujourd'hui un mécanisme plus léger : authentifier le domaine et non pas l'individu, et le faire en publiant, grâce au \ac{DNS}, la liste des serveurs de messagerie autorisés à envoyer du courrier pour ce domaine. Il existe plusieurs propositions techniques, qui sont apparemment toutes en train de converger. Le principe est simple (figure \ref{lmap}) : un serveur \ac{SMTP} est à peu près sûr de l'adresse IP de l'autre serveur \ac{SMTP} qui est en face. Elle est très difficile à falsifier. Il extrait donc le domaine de l'adresse d'expéditeur et regarde dans le \ac{DNS} les serveurs \ac{SMTP} de ce domaine. Si le serveur qui tente de lui envoyer un message est dans cette liste, le message est accepté sinon il est, au choix, refusé, détruit ou soumis à des tests plus approfondis. Ainsi, on authentifie le dernier canal de communication utilisé (entre les deux derniers serveurs), pas le message lui-même comme le faisait \ac{PGP}. Mais on espère que la facilité de déploiement compensera la réduction des fonctions. \begin{figure} \ifpdf \includegraphics[scale=0.70]{lmap-principle.pdf} \else \includegraphics[scale=0.80]{lmap-principle.eps} \fi \caption{Principe de l'authentification dans le DNS~; les numéros indiquent l'ordre des opérations\label{lmap}} \end{figure} Une fois posé ce principe très simple, d'innombrables détails viennent compliquer la tâche. Le principal est la question de l'identité à tester (exposée en section \ref{identite}). Que veut dire ``Je représente \url{smith@example.com}'' ? \subsection{SPF} Le plus connu de ces nouveaux protocoles, et de loin le plus répandu, est \ac{SPF}, développé par Pobox. \ac{SPF} teste uniquement le \computer{MAIL FROM} de l'enveloppe. \ac{SPF} brise notamment le suivi automatique du courrier (scénario de la section \ref{scenar-forward}). \ac{SPF} est largement déployé dans le monde. Le site Web de \ac{SPF} propose documentations et aide. \subsection{Sender-ID} Aujourd'hui, \ac{Sender-ID} est en discussion au groupe de travail \ac{MARID}, de l'\ac{IETF}, qui veille à ce que la normalisation couronne un standard neutre, qui ne soit pas sous la menace de brevets léonins et qui ne dépende pas pour son évolution d'une seule entreprise. Après de chaudes discussions, \ac{MARID} a adopté une stratégie qui ressemble beaucoup à celle de \ac{SPF}. \ac{Sender-ID} offrira le choix de l'identité à tester. Pour l'instant, il semble qu'il pourra tester le \computer{MAIL FROM} de l'envelope ou bien le \ac{PRA}, extrait des en-têtes\footnote{C'est l'algorithme -~absolument trivial~- d'extraction de l'adresse qui fait l'objet d'une demande de brevet de Microsoft. Une licence -~très restrictive~- est délivrée par Microsoft pour exploiter cet algorithme.} et qui sera en général le \computer{From} de l'en-tête. \section{Résultats et conséquences pratiques} \ac{SPF} (ou ses semblables) limite le \spam ? Indirectement, seulement : un \spammer peut mettre des enregistrements \ac{DNS} dans son domaine. Mais \ac{SPF} contribue à assécher le marécage : si tous les \spammers sont obligés d'agir à visage découvert, les vocations devraient se tarir. Dans la tradition du \ac{DNS}, outil décentralisé, les décisions seront prises par le gérant du domaine ainsi que par celui du serveur de messagerie, qui décide ou pas d'activer les tests \ac{SPF} ou \ac{Sender-ID}. Il ne faut pas se faire d'illusions sur la possibilité de solutions techniques invisibles et sans douleur. Toutes les méthodes anti-spam ont un coût, parfois très élevé. De même qu'il est agaçant de devoir fermer sa porte à clé et d'emporter ses clés, de même l'Internet de demain sera probablement moins pratique et plus contraignant. En outre, la transition sera douloureuse : lorsque l'usage de \ac{SPF} deviendra suffisamment important pour que des sites refusent tout message venant de domaines non-\ac{SPF}, beaucoup de messages seront perdus, victimes innocentes de la guerre mondiale contre le spam. Ainsi, dans un scénario comme celui de la section \ref{scenar-sendfriend}, des messages légitimes pourront être refusés car provenant d'un serveur non autorisé. De même, les travailleurs nomades comme celui de la section \ref{scenar-nomade} vont avoir des difficultés. Un gros travail de déploiement et de support est donc à prévoir. Quel est l'avenir de \ac{SPF} ? A l'origine, ce n'était qu'une proposition parmi d'autres, portée par une entreprise privée. Seule de ces propositions, \ac{SPF} a réussi à entrainer l'adhésion de beaucoup, par un gros effort de marketing mais aussi par la mise à la disposition de tous d'excellentes documentations et de logiciels libres mettant en \oe{}uvre \ac{SPF}. Aujourd'hui, deux propositions se font face, le \ac{SPF} traditionnel, limité mais déjà mis en \oe{}uvre et déployé et \ac{Sender-ID} qui, à l'heure où ces lignes sont écrites, n'a pas encore été finalisé. Le choix entre eux, ainsi que la décision de suivre cette voie de l'authentification ou pas, dépend désormais des acteurs de l'Internet. \section{Glossaire} \begin{acronym} \acro{AFNIC}{Association Française pour le Nommage Internet en Coopération}. Registre des \ac{ccTLD} \dns{fr} et \dns{re}. \url{http://www.afnic.fr/} \acro{ccTLD}{Country-Code Top Level Domain}. Un domaine national comme \dns{fr} en France ou bien \dns{de} en Allemagne. \acro{CERT}{Computer Emergency Response Team}. Un centre de compétences sur la sécurité informatique, dont une des tâches est de publier des alertes de sécurité avec les correctifs suggérés. Ces alertes doivent être authentifiées et les \ac{CERT} utilisent \ac{PGP}. \acro{DNS}{Domain Name System}. Le mécanisme d'annuaire distribué de l'Internet, qui permet, non seulement de traduire les noms en adresses IP, son utilisation la plus connue, mais aussi de récupérer diverses informations comme la liste des serveurs de courrier autorisés pour le domaine, ce que font \ac{SPF} et \ac{Sender-ID}. \acro{FAI}{Fournisseur d'Accès Internet}. Comme Free, No-Log ou Nerim en France. \acro{IETF}{Internet Engineering Task Force}. Organisme chargé de la normalisation des protocoles Internet. Le groupe \ac{MARID}, en fait partie. \url{http://www.ietf.org/}. \acro{MARID}{MTA Authorization Records in \ac{DNS}}. Le groupe de travail de l'\ac{IETF} qui tente de normaliser les protocoles d'authentification des serveurs de courrier via le \ac{DNS}. \url{http://www.ietf.org/html.charters/marid-charter.html} \acro{NIC}{Network Information Center}. À l'origine un organisme chargé d'assurer l'information sur l'Internet et d'attribuer des ressources uniques comme les adresses IP. Désigne désormais un organisme chargé de gérer un domaine comme l'\ac{AFNIC} gère \dns{fr} ou bien le DENIC gère \dns{de}. On dit aussi un registre. \acro{PGP}{Pretty Good Privacy}. Un système de signature électronique par la cryptographie très sûr et très utilisé, mais dans des communautés restreintes, typiquement dans le milieu de la haute technologie. \acro{PKI}{Public Key Infrastructure}. Infrastructure de gestion de clés publiques pour la cryptographie. Typiquement un logiciel et un ensemble de procédures pour créer des clés, les distribuer, les annuler, etc. \acro{PRA}{Purported Responsible Address}. Un algorithme trivial (mais apparemment breveté) pour extraire des en-têtes du message l'adresse du responsable de la dernière injection du message dans le système de courrier. Dans les cas simples comme celui en \ref{scenar-simple}, c'est seulement le \computer{From} de l'en-tête. Dans un cas comme celui en \ref{scenar-sendfriend}, cela serait le \computer{Sender} de l'en-tête. \acro{RFC}{Request For Comments}. Les ``textes sacrés'' de l'Internet. Certains ont un caractère normatif mais pas tous. On les identifie par un numéro par exemple 1034 et 1035 pour le \ac{DNS}. Ils sont tous accessibles publiquement et redistribuables librement. \acro{RIR}{Regional Internet Registries}. Organismes comme le RIPE-NCC en Europe chargés d'attribuer les adresses IP. \acro{Sender-ID}{Sender IDentification}. Un protocole en cours de normalisation à l'\ac{IETF} pour authentifier les serveurs de courrier via le \ac{DNS}. \acro{SMTP}{Simple Mail Transfer Protocol}. Le protocole de très loin le plus courant dans l'Internet pour la communication entre serveurs de messagerie. Normalisé dans le \rfc{2821}. \acro{SPF}{Sender Policy Framework}. La seule technique d'authentification des serveurs de courrier par le \ac{DNS} qui aie été largement déployée. Développé par Pobox. \url{http://spf.pobox.com} \end{acronym} \end{document}