Comment Paypal peut-il usurper les e-mails si facilement pour dire qu'ils proviennent de quelqu'un d'autre?
Lorsque je reçois un paiement via Paypal, il m'envoie un e-mail à ce sujet (photo ci-dessous). Le problème est que l'e-mail provient de l'adresse e-mail de l'expéditeur et non de Paypal lui-même, même si l'expéditeur réel est Paypal.
Voici le texte qui apparaît lorsque je sélectionne "Afficher l'original" dans Gmail:
From: "[email protected]" <[email protected]>
Sender: [email protected]
Vous pouvez donc voir que le véritable expéditeur est Paypal.
Si Paypal peut usurper l'expéditeur de l'e-mail si facilement et que Gmail ne le reconnaît pas, cela signifie-t-il que quiconque peut usurper l'adresse de l'expéditeur de l'e-mail et que Gmail ne le reconnaîtra pas?
Lorsque j'envoie moi-même des e-mails à Gmail à l'aide de telnet, l'e-mail est accompagné de l'avertissement:
Ce message n'a peut-être pas été envoyé par: [email protected]
Est-ce un problème de sécurité? Parce que si je suis habitué au fait que les e-mails de paiement dans Paypal semblent provenir de l'e-mail de l'expéditeur et non de Paypal, l'expéditeur peut simplement usurper le paiement lui-même en envoyant un message comme celui de son e-mail, et je peux penser que c'est le vrai paiement.
Est-ce quelque chose de spécifique à Paypal, ou quelqu'un peut-il tromper Gmail comme ça? Et si quelqu'un le peut, quelle est la méthode exacte utilisée par Paypal pour tromper Gmail?
Voici une dramatisation de la façon dont la communication se déroule, lorsqu'un courrier est reçu n'importe où.
Contexte: un serveur de messagerie, seul dans une baie, quelque part à Moscou. Le serveur est juste assis là, avec une expression d'attente.
Serveur:
Ah, les jours de ma servitude sont longs,
Cela sera dépensé dans la solitude,
'Ere vient des anneaux extérieurs
Le Swift porteur de nouvelles extérieures.
Une connexion est ouverte.
Serveur:
Un client entrant! Peut-être un mail
À ma tutelle sera confiée
Que je puisse transmettre comme le coursier le plus juste
Et au récipiendaire apporter tout le récit.
220 mailserver.kremlin.ru ESMTP Postfix (Ubuntu)
Bienvenue dans mon royaume, net vagabond,
Apprenez que je suis un puissant serveur de messagerie.
Comment vous adresserez-vous en ce jour
Le besoin augmentera-t-il pour que votre nom soit deviné?
Client:
HELO whitehouse.gov
Salut à toi, gardien du réseautage,
Sachez que je suis né du bâtiment pâle.
Serveur:
250 mailserver.kremlin.ru
L'adresse IP entrante se résout par le DNS en "nastyhackerz.cn".
Noble envoyé, je vous commande,
Même si ta voix vient des plaines chaudes
De la terre au-delà des montagnes asiatiques,
Je répondrai à votre demande la plus fragile.
Client:
MAIL FROM: [email protected]
RCPT TO: [email protected]
Subject: biggest bomb
I challenge you to a contest of the biggest nuclear missile,
you pathetic dummy ! First Oussama, then the Commies !
.
Voici mon message, à envoyer,
Et transmettre fidèlement sur l'éther;
Faites attention aux adresses et au nom de l'expéditeur
Cela doit être affiché à l'autre extrémité.
Serveur:
250 Ok
Ainsi, il a été écrit, donc cela doit être fait.
Le message est envoyé, et la Russie est partie.
Le serveur envoie l'e-mail tel quel, en ajoutant uniquement un en-tête "Received:" pour marquer le nom que le client a donné dans sa première commande. Commence alors la Troisième Guerre mondiale. La fin.
Commentaire: il n'y a aucune sécurité dans les e-mails. Tous les noms d'expéditeur et de destinataire sont indicatifs et il n'y a aucun moyen fiable de détecter l'usurpation d'identité (sinon il y aurait beaucoup moins de spams).
Toute adresse e-mail provenant de peut être usurpée, car vous pouvez modifier les données sortantes que vous souhaitez. Vous n'avez pas besoin de tromper Gmail. En disant cela, gmail peut détecter des problèmes évidents lorsqu'un e-mail marqué comme envoyé par une organisation leur parvient d'un autre domaine.
Vous ne pouvez pas non plus être sûr que l'e-mail d'origine provient de Paypal dans votre exemple - ce bit d'expéditeur peut également être usurpé!
Si vous voulez une sorte d'authentification pour éviter que cela se produise, vous avez besoin d'un moyen de signer ou de crypter les e-mails, ou d'une vérification hors bande pour confirmer que l'e-mail provient de votre ami (comme vous l'avez mentionné dans votre commentaire)
Sérieusement - ne faites confiance à aucun e-mail. Ne pas cliquez sur n'importe quel lien dans un e-mail. Surtout à partir de cibles de grande valeur telles que Paypal. Au lieu de cela, vous devez vous connecter comme vous le feriez normalement et vérifier s'ils vous ont envoyé quelque chose.
Comme d'autres l'ont mentionné, n'importe qui peut truquer n'importe quelle adresse e-mail , y compris celle Champ "Expéditeur" - il n'y a aucune raison technique pour que Paypal doive même inclure son propre e-mail dans le champ expéditeur, ils ne le font que parce qu'ils sont une entreprise honnête. Ne vous attendez pas à ce que les spammeurs soient aussi gentils.
En passant, cependant, je voudrais mentionner que gmail prend en charge DKIM , ce qui vous permet de vérifier qu'un e-mail Paypal provient bien de Paypal.
Pour l'activer: cliquez sur l'engrenage en haut à droite -> paramètres de messagerie -> laboratoires -> Activer "Icône d'authentification pour les expéditeurs vérifiés"
Les e-mails Paypal maintenant signés apparaîtront avec une petite icône de clé à côté d'eux:
C'est un peu comme le courrier postal. Tout le monde peut vous envoyer une lettre avec du papier à en-tête qui ressemble à la succursale locale de votre banque. Il y a certaines choses que vous pouvez faire pour attraper des imitateurs comme ceux-ci - vous pouvez vous assurer que le cachet de la poste provient de la bonne ville. Si votre banque utilise toujours du courrier en vrac au lieu de timbres individuels, vous remarquerez peut-être cela, etc.
La principale différence entre le courrier postal et le courrier électronique, c'est qu'avec le courrier électronique, une contrefaçon est plus pratique - elle peut être conçue une fois, puis répétée pour un coût presque nul.
Cela signifie que toutes les contrefaçons et contre-mesures sont à une échelle plus massive, et (sauf si vous êtes comme moi1) de faux messages arriveront dans votre boîte de réception et c'est à vous de les filtrer manuellement.
En fin de compte, tout comme vous n'appeleriez pas un numéro de téléphone sur une lettre pour "vérifier les informations de votre compte" (comme votre SSN et votre carte de crédit), vous ne devez pas non plus cliquer sur les liens dans les e-mails et vous attendre à ce que l'écran de connexion ou le formulaire envoyer en toute sécurité les informations privées à votre banque. Si vous le faites, vous pourriez vous retrouver à envoyer vos informations d'identification à un imposteur et ne vous en rendrez jamais compte.
1. J'ai éliminé tous mes spams. J'ai mon propre nom de domaine. Je donne à chaque contact sa propre adresse e-mail, et tout cela arrive dans ma seule boîte de réception. De cette façon, si Bob obtient un virus sur son ordinateur et que je commence à recevoir certains de ces spams de bas niveau, je peux dire à Bob de changer son mot de passe de messagerie et de commencer à utiliser une nouvelle adresse e-mail pour son e-mail. La nouvelle adresse e-mail ne recevra pas de spam, et je peux supprimer l'ancienne, car seul Bob l'utilisait.
Je n'ai pas besoin d'aller dire à ma banque et à mes autres copains, mes vendeurs, mes collègues, que mon adresse e-mail a changé, car chacun a sa propre adresse. (Je n'ai même pas besoin de mettre à jour StackExchange et le Gravater.) C'est bon pour moi (pas de spam), bon pour Bob (il sait qu'il a un "virus ou quelque chose" - parfois je peux être direct, mais il faut faire attention à ne pas se tromper par la suite), bon pour mes autres copains (je ne me plains jamais du nombre d'emails que j'ai reçus au cours des dernières 24 heures, et expliquer pourquoi je ne leur ai pas répondu)
Je pense que vous avez tous oublié un petit détail qui a été mentionné dans la dramatisation ci-dessus, qui est en fait très facile à vérifier:
Les e-mails frauduleux ne proviennent pas d'une adresse e-mail qui appartient légitimement au domaine dont ils prétendent provenir. Une partie du protocole SMTP comprend un ensemble de en-têtes de message complets qui toujours inclut le chemin de retour du message, qui est l'adresse e-mail qui en fait a envoyé le message. Non seulement cela, mais les adresses IP ont également une région géographique définitive à laquelle elles sont attribuées. Vous pouvez donc attraper ces écarts en creusant un peu.
Prenons, par exemple, la dramatisation.
Il mentionne que l'e-mail provient de whitehouse.gov. Voici son adresse IP:
calyodelphi@dragonpad:~ $ Dig +short whitehouse.gov
173.223.0.110
Maintenant, disons que nastyhackerz.cn se résout en une adresse IP quelque part dans le bloc 1.0.32.0-1.0.63.255 (pour référence: http://www.nirsoft.net/countryip/cn.html premier bloc de la liste). Cette adresse IP va figurer dans les en-têtes de message complets. Tout ce que vous devez faire est de prendre cette IP en ligne pour retrouver sa géolocalisation (vous pouvez utiliser http://www.geoiptool.com/ par exemple)
L'adresse IP de whitehouse.gov (173.223.0.110) au moment de la rédaction de ce message est géolocalisée à Boston, Massachusetts (pour une raison quelconque, un système de prévention du spam ne me permet pas de publier ma recherche sur geoiptool en raison de points de réputation, vous pouvez donc aller faites la recherche vous-même) qui est assez proche de chez vous (District de Columbia)! Supposons simplement que whitehouse.gov soit hébergé dans un centre de données situé à Boston, pour que cela soit plus facile à expliquer.
Tant que l'adresse IP et l'adresse e-mail à laquelle l'e-mail a été envoyé ne correspondent pas à l'adresse IP et à l'adresse e-mail que l'e-mail prétend à envoyer, il peut être déterminé comme une usurpation. Vous avez juste besoin de regarder dans les en-têtes de message complet.
Regardons les en-têtes d'un e-mail que j'ai envoyé depuis l'un de mes propres domaines (dragon-architect.com) vers ma propre adresse e-mail personnelle:
Delivered-To: [email protected]
Received: by 10.180.89.68 with SMTP id bm4csp105911wib;
Tue, 29 Jan 2013 08:54:47 -0800 (PST)
X-Received: by 10.60.30.38 with SMTP id p6mr1296792oeh.2.1359478487251;
Tue, 29 Jan 2013 08:54:47 -0800 (PST)
Return-Path: <[email protected]>
Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com. [69.93.154.35])
by mx.google.com with ESMTP id m7si14056914oee.29.2013.01.29.08.54.45;
Tue, 29 Jan 2013 08:54:46 -0800 (PST)
Received-SPF: neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of [email protected]) client-ip=69.93.154.35;
Authentication-Results: mx.google.com;
spf=neutral (google.com: 69.93.154.35 is neither permitted nor denied by domain of [email protected]) [email protected]
Received: by gateway14.websitewelcome.com (Postfix, from userid 5007)
id 0530E1DFDB334; Tue, 29 Jan 2013 10:54:43 -0600 (CST)
Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130])
by gateway14.websitewelcome.com (Postfix) with ESMTP id EA7191DFDB314
for <[email protected]>; Tue, 29 Jan 2013 10:54:42 -0600 (CST)
Received: from [127.0.0.1] (port=43458 helo=dragon-architect.com)
by bentley.websitewelcome.com with esmtpa (Exim 4.80)
(envelope-from <[email protected]>)
id 1U0ESK-0001KE-DP
for [email protected]; Tue, 29 Jan 2013 10:54:44 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 29 Jan 2013 10:54:44 -0600
From: [email protected]
To: <[email protected]>
Subject: Headers Test
Message-ID: <[email protected]>
X-Sender: [email protected]
User-Agent: Roundcube Webmail/0.8.4
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - bentley.websitewelcome.com
X-AntiAbuse: Original Domain - gmail.com
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dragon-architect.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (dragon-architect.com) [127.0.0.1]:43458
X-Source-Auth: [email protected]
X-Email-Count: 1
X-Source-Cap: ZHJhZ2FyY2g7ZHJhZ2FyY2g7YmVudGxleS53ZWJzaXRld2VsY29tZS5jb20=
Testing testing!
C'est beaucoup de données aléatoires à parcourir, mais il y a deux lignes que nous regardons ici: chemin de retour et de. Puisque je me suis légitimement envoyé cet email, ils correspondent tous les deux. Le chemin de retour ne peut pas être usurpé. Ou si c'est le cas, il est incroyablement difficile d'usurper efficacement et nécessite une configuration délibérée du démon SMTP utilisé pour envoyer du courrier. La comparaison du chemin de retour et des champs de données provenant des en-têtes complets est une façon pour moi et mes collègues de travail d'identifier le faux et de déterminer si un ticket de support doit être soumis.
Alors, que se passe-t-il si les deux correspondent, mais l'e-mail doit toujours être usurpé? J'y reviendrai dans la section suivante ...
Maintenant, comme mentionné précédemment, il existe d'autres moyens de déterminer l'usurpation d'identité d'un e-mail. Les enregistrements SPF sont l'un de ces moyens, mais ils ne sont pas toujours parfaits. Prenez, par exemple, le SPF de whitehouse.gov et comparez-le au SPF de mon propre domaine:
calyodelphi@dragonpad:~ $ Dig +short txt whitehouse.gov
"v=spf1 +mx ~all"
calyodelphi@dragonpad:~ $ Dig +short txt dragon-architect.com
"v=spf1 +a +mx +ip4:70.84.243.130 ?all"
Habituellement, un bon enregistrement SPF comprend également l'adresse IP du serveur qui a envoyé le courrier, donc celui qui a créé l'enregistrement SPF pour whitehouse.gov ne le sait probablement pas. Je considérerais l'enregistrement SPF de whitehouse.gov comme trop générique pour être efficace pour déterminer les origines réelles de tout message prétendant provenir de whitehouse.gov. Le SPF pour mon propre domaine, d'autre part, qui a été généré automatiquement par le serveur qui héberge mon domaine (avec l'aimable autorisation de mon hébergeur), est très spécifique et inclut l'adresse IP du serveur lui-même.
J'avouerai ne pas être intimement familier avec la façon dont les enregistrements SPF sont formatés et comment ils fonctionnent, mais j'ai suffisamment appris sur mon travail pour que je puisse au moins identifier les enregistrements SPF génériques et spécifiques. Je suppose que c'est quelque chose que je devrais probablement creuser un week-end quand je m'ennuie et que je veux du matériel de lecture technique!
Quoi qu'il en soit, de retour sur la bonne voie ici. Regardez les lignes reçues. L'un d'eux dit ainsi: Received: from bentley.websitewelcome.com (bentley.websitewelcome.com [70.84.243.130]) Devinez quoi? Cela correspond à l'adresse IP dans l'enregistrement SPF de mon domaine.
Si l'IP dans le SPF ne correspond pas à l'IP du serveur qui a réellement envoyé l'e-mail, c'est une autre indication que vous avez une usurpation d'identité. Par conséquent, un enregistrement SPF générique comme "v=spf1 +mx ~all" Ne va tout simplement pas couper la moutarde de sécurité. Je ne ferais même pas confiance aux e-mails provenant d'un domaine légitime qui possède un SPF générique comme celui-ci.
Peut-être devrions-nous déposer une pétition sur petitions.whitehouse.gov pour exiger que leurs administrateurs de sécurité revoient l'enregistrement SPF qu'ils ont fait pour le domaine! (Je gamin, je gamin.)
[~ # ~] modifier [~ # ~]
En fait, je dois [~ # ~] massivement [~ # ~] me corriger à propos des enregistrements SPF! J'ai fait de fausses hypothèses et j'ai appris quelques choses aujourd'hui après avoir demandé à un collègue qui était plus au courant que moi des enregistrements SPF. Donc, je vais utiliser les deux SPF pour whitehouse.gov et dragon-architect.com dans mon auto-correction:
calyodelphi@dragonpad:~ $ Dig +short txt whitehouse.gov
"v=spf1 +mx ~all"
calyodelphi@dragonpad:~ $ Dig +short txt dragon-architect.com
"v=spf1 +a +mx +ip4:70.84.243.130 ?all"
Le SPF pour mon propre domaine est en fait plus clément que le SPF pour whitehouse.gov (quelque chose que je prévois de corriger ce soir après avoir terminé cette modification). Je vais vous expliquer pourquoi:
"v=spf1 +mx ~all" Dit essentiellement que les e-mails de whitehouse.gov sont censés provenir des noms d'hôtes définis dans les enregistrements MX pour whitehouse.gov, et que tous les e-mails qui ne proviennent pas de ces noms d'hôtes sont censés être des usurpations, mais s'ils 'est marqué comme usurpation d'identité ou non appartient au destinataire de l'e-mail.
calyodelphi@dragonpad:~ $ Dig +short mx whitehouse.gov
110 mail6.eop.gov.
105 mail2.eop.gov.
110 mail5.eop.gov.
105 mail1.eop.gov.
105 mail4.eop.gov.
105 mail3.eop.gov.
"v=spf1 +a +mx +ip4:70.84.243.130 ?all" Indique que les e-mails de dragon-architect.com sont censés provenir de l'adresse IP de dragon-architect.com (67.18.28.78), les noms d'hôte définis dans le ou les enregistrements MX pour dragon-architect .com, ou l'adresse IP du serveur qui héberge dragon-architect.com (70.84.243.130). Tous les e-mails qui ne proviennent pas de ceux-ci, eh bien, tout cela à la fin signifie simplement qu'il n'y a pas de conseil pour transmettre ou rejeter les e-mails.
Alors, quelle est la viande et les pommes de terre d'un disque SPF? Le "tout" à la toute fin. Pour citer ce collègue sur le "tout":
+all basically means ALL pass -- the record is useless, sender domain doesn't care
?all indicates neutral and is advising to not pass or reject mail
~all indicates fail, and the server is considered invalid, but does not specifically suggest an action.
-all is a hard fail, anything else is invalid, reject or flag it.
Pour que "tout" soit l'endroit où vous définissez à quel point votre enregistrement SPF est strict. Mais que l'enregistrement SPF soit ou non réellement utilisé pour déterminer l'usurpation d'un e-mail est complètement jusqu'à la réception service de messagerie.
Alors voilà. SPF en bref.
Donc voilà. TL; DR: vérifiez vos en-têtes complets pour voir si le chemin de retour et les champs correspondent. Vérifiez ensuite vos enregistrements SPF s'il y en a pour voir si vous obtenez des adresses IP correspondantes.
SMTP (Simple Mail Transfer Protocol) est nommé ainsi pour une très bonne raison.
SMTP est né en 1982 sur l'ancien ARPANET, qui était détenu et contrôlé par le DoD américain, et destiné à la communication entre les personnes disposant d'habilitation de sécurité travaillant sur des projets gouvernementaux auxquels on pouvait généralement faire confiance pour ne pas en abuser. La "sécurité" de ce réseau a été accomplie tout simplement en plaçant les machines qui pouvaient s'y connecter dans des zones physiquement sécurisées des différentes installations, juste à côté du travail classifié que ces installations effectuaient. En conséquence, la sécurisation des données envoyées sur le réseau n'a généralement été envisagée qu'après la mise hors service d'ARPANET, le premier bond quantique ayant eu lieu vers 1993 avec l'API Secure Network Programming (qui a jeté les bases de Secure Sockets Layer, désormais généralement connu). comme Transport Layer Security). Alors que la plupart des protocoles (y compris SMTP/POP/IMAP) peuvent désormais ajouter TLS pour un canal de communication sécurisé, tout cela fournit la confidentialité et l'authenticité du serveur; il ne fournit pas l'authenticité de l'expéditeur ni l'intégrité du message, et il ne fournit pas non plus de répudiation.
Il existe une option disponible pour la sécurité des e-mails, appelée PGP (Pretty Good Privacy; c'est l'humour ironique de Phil Zimmerman pour un système qu'aucun ordinateur de la planète ne pourrait briser s'il était correctement mis en œuvre). Il peut, avec diverses options, fournir les quatre principes fondamentaux de la sécurité de l'information; confidentialité, intégrité, authenticité et non-répudiation (l'expéditeur, qui a signé le courrier électronique à l'aide de son certificat, ne peut pas prétendre qu'il ne l'a pas réellement envoyé; personne d'autre n'aurait pu le faire, sauf si le certificat était compromis). Il utilise un système similaire de certificats de clé publique et d'échange de clés sécurisé comme on le voit dans une prise de contact TLS bidirectionnelle, mais certains détails sont modifiés pour refléter la nature asynchrone du transport de courrier électronique et pour refléter le désir d'un système décentralisé " Web of trust ", ce qui exclut le besoin d'autorités de certification de confiance mondiale.
Cependant, ce système n'a pas encore vraiment décollé, bien qu'il ait plus de 25 ans, et en tant que tel, il n'est requis que par les agences gouvernementales et certaines grandes entreprises. Pratiquement tous les fournisseurs de messagerie transmettront volontiers des e-mails frauduleux via des connexions sécurisées à votre boîte de réception. Vous pouvez, dans de nombreux cas, encourager vos amis et les autres personnes de qui vous souhaitez recevoir des e-mails à adopter le schéma PGP, et tout ce qui n'est pas valablement signé passe en "quarantaine", mais ce n'est vraiment qu'un autre niveau de "filtrage du spam" ", et je ne connais pas un seul fournisseur de messagerie publique que vous pouvez demander de rejeter les e-mails sans signature numérique pure et simple; le serveur de messagerie doit être sous votre contrôle, comme un serveur Exchange d'entreprise.
tl; dr
- Paypal exploite-t-il un problème de sécurité ici? ... Comment Paypal peut-il usurper des e-mails si facilement?
Techniquement, ce n'est pas un problème de sécurité, le courrier électronique n'est pas sécurisé au départ. Ils utilisent l'un des en-têtes SMTP suivants situés dans l'en-tête du message (pas l'en-tête de l'enveloppe)
Resent-FromResent-SenderSenderIl existe une différence conceptuelle entre le "repostage" et "l'usurpation d'identité". Le client de messagerie doit afficher cette différence. Le client Gmail ne fait pas cela.
Paypal n'est pas une usurpation d'identité, ils utilisent l'un de ces en-têtes SMTP: Resent-From , Resent-Sender , ou Expéditeur
Il est très facile d'usurper un domaine ... même avec les contrôles SPF activés
Le MUA (client de messagerie) doit afficher Afficher à partir de , son état de vérification SPF, DKIM et DMARC.
L'en-tête Resent- * doit être utilisé d'une manière qui indique clairement que ce message est "renvoyé".
En général, la meilleure solution consiste à utiliser DKIM + DMARC , ou SPF + DMARC et un MUA qui affiche les résultats de la vérification.
Quelques antécédents
De manière générale, il y a deux adresses "de" et deux adresses "à" dans chaque message SMTP. L'une est connue sous le nom d'enveloppe RFC2821, l'autre est le message RFC2822. Ils servent à des fins différentes
L'enveloppe: (RFC2821)
L'enveloppe est des métadonnées qui n'apparaissent pas dans l'en-tête SMTP. Il disparaît lorsque le message passe au MTA suivant.
Le
RCPT From:est l'endroit où iront les rapports de non-remise. Si un message provient de Postmaster ou d'un service de repostage, il s'agit généralement de<>ou[email protected]. Il est intéressant de voir que Salesforce utilise ceci comme constantContact comme clé dans une base de données comme[email protected]pour voir si le message a rebondi.Le
RCPT TO:est le destinataire du message. Il est utilisé pour les utilisateurs "to" et "bcc". Cela n'affecte généralement pas "l'affichage des adresses" dans le client de messagerie, mais il y a des occasions où les MTA affichent ce champ (si les en-têtes RFC2822 sont corrompus).
Le message (RFC2822)
La partie message commence lorsque la commande
dataest émise.Ces informations incluent les en-têtes SMTP que vous connaissez, le message et ses pièces jointes. Imaginez toutes ces données copiées et collées de chaque MTA au suivant, successivement jusqu'à ce que le message atteigne la boîte de réception.
Il est habituel pour chaque MTA de préfixer le copier-coller mentionné ci-dessus avec des informations sur le MTA (IP source, IP de destination, etc.). Il colle également les détails du contrôle SPF.
C'est le
Display Fromest placé. C'est important. Les spoofers peuvent modifier cela.Le
Mail From:dans l'enveloppe est jetée et généralement placée ici commereturn-path:adresse pour les rapports de non-remise
Alors, comment empêcher les gens de modifier l'affichage à partir de? Eh bien DMARC redéfinit une deuxième signification pour le record SPF. Il reconnaît qu'il existe une différence entre l'enveloppe de et l'affichage de et qu'il existe des raisons légitimes pour lesquelles ils ne correspondent pas. Étant donné que SPF a été initialement défini pour ne se soucier que de l'enveloppe de, si l'affichage de est différent, DMARC nécessitera une deuxième vérification DNS pour voir si le message est autorisé à partir de cette adresse IP.
Pour autoriser les scénarios de transfert, DMARC permet également à Afficher à partir de d'être cryptographiquement signé par DKIM, et si un spammeur ou un hameçonneur non autorisé tentait de supposer que identité, le chiffrement échouerait.
Qu'est-ce que DKIM? DKIM est une technologie de cryptage légère qui signe les données résidant dans le message. si vous avez déjà reçu un message de Gmail, Yahoo ou AOL, vos messages ont été signés DKIM. Le fait est que personne ne vous connaîtra jamais en utilisant le cryptage et la signature DKIM à moins que vous ne regardiez dans les en-têtes. C'est transparent.
DKIM peut généralement survivre à la transmission et au transfert vers différents MTA. Quelque chose que SPF ne peut pas faire. Les administrateurs de messagerie peuvent utiliser cela à notre avantage pour empêcher l'usurpation d'identité.
Le problème réside dans le SPF vérifiant uniquement l'enveloppe RFC2821, et non l'affichage de . Étant donné que la plupart des gens se soucient de l'affichage de affiché dans un e-mail, et non du chemin de retour NDR, nous avons besoin d'une solution pour protéger et sécuriser cette pièce.
C'est là qu'intervient DMARC. DMARC vous permet d'utiliser une combinaison d'une vérification SPF modifiée ou DKIM pour vérifier Afficher à partir de . DKIM vous permet de signer cryptographiquement l'affichage RFC2822 dès que le SPF ne correspond pas à l'affichage depuis (ce qui arrive fréquemment).
L'usurpation de l'affichage provient-elle d'un problème de sécurité?
Oui, le phishing, bien que le courrier électronique soit un problème de sécurité important que de nombreux fournisseurs examinent. À savoir Paypal, AOL, Google, Yahoo et d'autres sociétés mettent en œuvre DMARC pour résoudre ce problème de phishing.
Pourquoi est-il toujours possible de falsifier l'en-tête "From:" dans les e-mails?
Certains administrateurs de serveur n'ont pas mis en œuvre les dernières technologies pour empêcher ce genre de chose de se produire. L'un des principaux obstacles à l'adoption de ces technologies est les "services de transfert de courrier électronique", tels qu'un logiciel de liste de diffusion, des redirecteurs automatiques ou un remailer d'anciens élèves (.forwarder). À savoir:
SPF ou DKIM n'est pas configuré.
Une stratégie DMARC n'est pas configurée.
Le client de messagerie n'affiche pas les résultats de la vérification de Afficher depuis et le champ Renvoyé- * ou Expéditeur.
Que fait Paypal?
Paypal utilise l'en-tête Expéditeur pour indiquer qu'il a été renvoyé. Il s'agit de l'utilisation correcte et prévue de cet en-tête.
Que fait GMail mal?
Gmail n'indique pas clairement que l'en-tête de l'expéditeur est utilisé, il ne valide pas l'adresse Display From de manière conviviale et il ne fait pas de distinction entre l'affichage de et l'expéditeur.