Ce que signifient les constats
Chaque vérification que fait cet outil, ce qu'elle examine réellement, et ce qu'un constat vous dit et ne vous dit pas.
Chaque constat sur un écran de résultat porte une explication d'une ligne et l'élément dont il est tiré. Cette page en est la version longue : quel est le mécanisme sous-jacent, pourquoi les attaquants s'y intéressent comme ils le font, et quel poids un constat mérite.
Une chose à garder à l'esprit tout du long : ces vérifications se corroborent les unes les autres. Aucune n'est un verdict à elle seule. Plusieurs sont banales dans le courrier légitime et ne deviennent intéressantes qu'en compagnie des autres.
Comment un message est constitué
Un courriel a deux parties : un bloc d'en-têtes en haut, puis le corps. Les en-têtes sont l'endroit où l'expéditeur est déclaré, où chaque serveur ayant traité le message a inscrit son propre enregistrement, et où les résultats d'authentification sont consignés. Votre logiciel de messagerie en masque la quasi-totalité et vous montre un nom, un objet et le corps.
Presque tout ce que fait cet outil consiste à lire les en-têtes. C'est pourquoi il demande la source brute plutôt qu'une capture d'écran ou un transfert : un transfert perd les en-têtes d'origine et les remplace par les vôtres.
L'authentification — et pourquoi une réussite n'est pas rassurante
Ce que les trois mécanismes vérifient réellement
SPF répond à : le serveur qui a remis ce message figure-t-il sur la liste des serveurs autorisés à émettre pour ce domaine ? C'est le propriétaire du domaine qui publie cette liste.
DKIM répond à : ce message a-t-il été signé cryptographiquement par quelqu'un détenant une clé que le domaine publie, et a-t-il été modifié depuis ? La signature nomme le domaine signataire — c'est la valeur d= que vous verrez dans les éléments affichés.
DMARC relie ces réponses à l'adresse que vous voyez réellement. Pris isolément, un résultat SPF ou DKIM positif peut appartenir à un domaine entièrement différent de celui de la ligne From — ce qui ne signifierait rien pour un lecteur. DMARC exige l'alignement : le domaine qui a réussi doit correspondre au domaine qui vous est montré.
Ce que l'alignement signifie, concrètement
Supposons qu'un message affiche notice@bank.example.jp dans la ligne From et porte une signature DKIM de mailer.example.net. La signature est valide. Mais le domaine qui s'est porté garant du message n'est pas le domaine que le lecteur voit : il n'est donc pas aligné, et DMARC ne traite pas le message comme authentifié pour bank.example.jp.
L'alignement peut être strict (correspondance exacte du domaine) ou souple (le domaine enregistré doit correspondre, de sorte que mail.bank.example.jp s'aligne avec bank.example.jp). Déterminer le domaine enregistré est la partie qui comporte une réserve — voyez la mention en bas de cette page.
Pourquoi une réussite est la chose la moins intéressante de la page
C'est l'idée la plus importante de cet outil, et elle est à l'opposé de ce que la plupart des gens supposent.
L'authentification prouve à qui appartient un domaine. Elle ne prouve pas qu'un message est ce qu'il prétend être. Un attaquant qui enregistre bank-example-support.com possède ce domaine entièrement. Il peut y publier des enregistrements SPF, signer en DKIM pour lui, et y publier une politique DMARC — en quelques minutes, pour le prix du domaine. Tous les messages qu'il envoie s'authentifient alors parfaitement, parce que chaque affirmation qu'ils font sur eux-mêmes est vraie. Ce n'est simplement pas la banque.
Dans l'hameçonnage observé, c'est le cas majoritaire, non un cas limite. Environ la moitié provient de domaines enregistrés par l'attaquant, et l'immense majorité de ceux-là passe DMARC. C'est pourquoi cet outil rend une réussite par « Ce domaine appartient bien à qui il prétend » et rien de plus chaleureux, et pourquoi l'analyse des domaines sosies et des liens pèse ici davantage que l'authentification.
Un échec vaut malgré tout la peine d'être connu : c'est la forme que produit un expéditeur falsifié. Mais les listes de diffusion et les services de réacheminement cassent l'authentification de façon courante et innocente : un échec seul n'est donc pas non plus un verdict.
ARC, pour les messages qui ont été réacheminés
Quand une liste de diffusion réécrit un message, elle casse la signature d'origine. ARC permet à chaque étape de consigner ce qu'elle a vu avant de transmettre le message, afin qu'un serveur ultérieur puisse constater que l'authentification était positive plus tôt même si elle échoue maintenant. Lorsque cet outil signale une chaîne ARC ayant échoué à sa vérification, cela signifie que cet enregistrement n'a pas pu être considéré comme fiable — ce qui est arrivé au message avant qu'il ne vous parvienne ne peut donc pas être confirmé.
Le trajet de remise
Ce qu'est une chaîne Received
Chaque serveur qui traite un message ajoute une ligne Received en tête des en-têtes : qui s'est connecté, qui l'a reçu, et quand. Lues de bas en haut, elles forment le voyage du message. L'outil les affiche de la plus récente à la plus ancienne, avec l'écart entre chaque paire sur la ligne qui les relie.
Seules les dernières étapes sont dignes de confiance. Chaque serveur ne peut se porter garant que de la connexion qu'il a personnellement acceptée. Tout ce qui se trouve sous le premier serveur contrôlé par votre propre fournisseur a été écrit par des machines auxquelles vous n'avez aucune raison de faire confiance, et un attaquant peut inventer autant de lignes qu'il veut. C'est pourquoi une première étape à l'allure étrange est un signal plutôt qu'une preuve.
Des horodatages qui remontent le temps
Chaque étape inscrit sa propre horloge : de petits désaccords sont donc normaux, les horloges dérivent. Lorsqu'un serveur ultérieur enregistre une heure antérieure à celle du précédent, au-delà de ce que la dérive explique, soit une horloge est très fausse, soit une partie du trajet a été écrite à la main. Les en-têtes falsifiés sont en général rédigés d'un seul jet par quelqu'un qui ne prête pas attention à l'arithmétique.
Un long intervalle inexpliqué
Plus d'une journée entre deux étapes. Les files d'attente et les nouvelles tentatives en sont réellement la cause : c'est donc rapporté comme quelque chose à remarquer plutôt que comme quelque chose sur quoi agir. Cela mérite un regard, car cela peut aussi signifier qu'un message a été composé plus tôt et injecté plus tard, ou qu'un bloc d'en-têtes a été copié depuis un message réel.
Une adresse privée dans un voyage public
Certaines plages d'adresses ne fonctionnent qu'à l'intérieur d'un réseau privé et ne sont pas joignables depuis Internet. En voir une apparaître au milieu d'un voyage public signifie généralement que la ligne a été copiée ou inventée, car la connexion qu'elle décrit n'aurait pas pu avoir lieu.
Envoyé depuis un serveur cloud sans nom
Les organisations qui envoient leur propre courrier donnent normalement à leurs serveurs de messagerie des noms qu'elles ont choisis. Une première étape dont le nom a été généré automatiquement par un hébergeur signifie que l'expéditeur utilise de la capacité louée sans la configurer — ce qui est ordinaire pour certains petits expéditeurs, et qui est aussi le moyen le moins coûteux d'émettre depuis une adresse que personne ne reconnaît. Rapporté comme un détail, jamais comme un verdict, et jamais au seul motif de l'identité de l'hébergeur.
Une note laissée par un serveur destinataire
Il arrive qu'un serveur ayant traité le message ait consigné son propre doute sur celui qui s'y connectait — le plus souvent que l'adresse connectée n'a pas de nom inverse, ce qui est disproportionnellement vrai des expéditeurs en masse. Lorsque vous voyez cela, il s'agit de la note de ce serveur, citée telle qu'écrite. Cet outil n'effectue aucune interrogation de son côté ; il rapporte ce qui est déjà dans le message.
Ce que le message déclare comme expéditeur
Le nom et l'adresse se définissent séparément
Un expéditeur est un nom affiché plus une adresse, et ce sont des champs indépendants — l'expéditeur écrit les deux. La plupart des logiciels de messagerie, en particulier sur téléphone, n'affichent que le nom. Un message peut donc afficher Équipe sécurité du compte alors que l'adresse en dessous est tout autre chose, sans que rien ne soit falsifié. C'est pourquoi l'outil vous montre la paire sur chaque message, et pas seulement sur les messages suspects.
Une seconde adresse cachée dans le nom
Une variante du même procédé : une adresse électronique écrite à l'intérieur du nom affiché. Votre logiciel de messagerie affiche le nom, vous lisez donc une adresse alors que le message venait d'une autre.
Des caractères qui inversent le sens de lecture
Unicode comprend des caractères de contrôle qui existent pour que l'arabe et l'hébreu s'affichent correctement dans du texte mêlé. Placés dans un nom ou un nom de fichier, ils font lire le texte à l'envers à l'écran alors que les caractères sous-jacents sont inchangés — c'est ainsi qu'un fichier nommé .exe peut sembler se terminer par .jpg. Cet outil ne les applique jamais : il les affiche comme des étiquettes visibles, telles que <U+202E>, pour que vous voyiez où ils sont.
Des caractères invisibles
Des caractères qui n'occupent aucune place, placés dans un nom ou une adresse. Ils font qu'un nom identique en apparence à un nom familier cesse de lui correspondre, ce qui déjoue les filtres et les règles de messagerie qui comparent sur le texte brut.
Domaines sosies
Cette vérification et celle de la structure des liens sont celles qui pèsent le plus ici, parce que, contrairement à l'authentification, elles sont difficiles à satisfaire honnêtement pour un attaquant.
Mêler des alphabets à l'intérieur d'un même nom
Les noms de domaine peuvent contenir des caractères de la plupart des écritures du monde, et plusieurs lettres s'y dessinent à l'identique — le a latin et le а cyrillique, le o latin et l'omicron grec. En substituer une dans un nom par ailleurs ordinaire produit un domaine visuellement identique et techniquement différent, disponible à l'enregistrement parce que personne d'autre ne le possède.
Mêler des écritures n'est pas suspect en soi, et cet outil ne le traite pas comme tel. Le japonais mêle trois écritures dans des mots ordinaires ; les domaines japonais, coréens et chinois sont normaux. La vérification s'appuie sur les règles Unicode indiquant quelles combinaisons se rencontrent réellement, et signale celles qui ne se rencontrent pas — le latin avec le cyrillique ou le grec à l'intérieur d'un même libellé.
Le Punycode n'est pas un signe d'alerte
Les domaines non ASCII sont transmis sous une forme encodée commençant par xn--. C'est ainsi que tout domaine japonais, coréen, chinois ou russe légitime s'écrit sur le réseau. Le voir ne signifie rien en soi, et cet outil ne le signale jamais comme suspect. Ce qu'il fait, c'est afficher la forme décodée et la forme encodée côte à côte, afin que si des caractères ont été substitués, la différence soit visible plutôt que simplement présente.
À un ou deux caractères d'un vrai domaine
Une lettre échangée, ajoutée ou retirée. rn à la place de m ; un zéro à la place de la lettre o. Ces différences sont difficiles à distinguer à taille de lecture et le domaine est trivial à enregistrer. Cette comparaison a besoin d'une liste de véritables domaines de marques, et ne couvre donc que les marques qui y figurent — voyez la page des limites.
Des terminaisons de domaine surreprésentées dans les abus
Certaines terminaisons sont peu coûteuses et peu contrôlées, et apparaissent dans l'hameçonnage bien plus souvent que dans le courrier ordinaire. Quantité de sites légitimes les utilisent aussi : cela contribue à un ensemble et ne tranche rien à soi seul.
La liste est délibérément courte, et l'absence d'une terminaison n'y signifie rien. Elle ne contient que les terminaisons pour lesquelles nous pouvons désigner une source publiée, mesurées sur plus d'une source et plus d'une période. Cela fait un petit nombre — 3 actuellement. Bien plus de terminaisons sont utilisées dans l'hameçonnage qu'il n'y en a sur la liste, et l'essentiel de l'hameçonnage passe de toute façon par des terminaisons ordinaires comme .com. Lisez un résultat qui ne dit rien de la terminaison comme un outil qui n'a pas d'avis, non comme une approbation.
Liens
Le texte dit une chose et le lien mène ailleurs
Dans un message HTML, le texte que vous voyez et l'adresse où vous iriez sont deux choses distinctes. Les faire diverger est le signe d'hameçonnage le plus fiable qui existe, et il est invisible tant que l'on ne survole pas le lien ou que l'on ne lit pas la source. L'outil affiche les deux, l'un au-dessus de l'autre, pour que la comparaison tienne en un regard vers le bas.
Aucun lien dans cet outil n'est jamais cliquable. Les adresses sont affichées comme du texte inerte que vous pouvez copier. Placer un lien d'hameçonnage actif à l'intérieur d'un analyseur d'hameçonnage serait indéfendable.
Un @ avant la véritable destination
Tout ce qui précède un @ dans une adresse web est ignoré par le navigateur. https://www.bank.example.jp@evil.example/ mène à evil.example. La partie familière est là pour que le lien commence de façon convaincante.
Des liens qui transportent des instructions plutôt qu'une adresse
Certains schémas de liens ne mènent pas à une page du tout : ils transportent du code que le navigateur doit exécuter, ou un document entier encodé à l'intérieur du lien. Le courrier ordinaire n'en contient pas.
Une adresse numérique au lieu d'un nom
Une destination sans nom de domaine derrière elle. Les organisations mettent leur nom sur leurs sites, et une adresse nue ne peut être comparée à rien.
Renvois et paramètres encodés
Un lien qui transporte une seconde adresse à l'intérieur et vous fait suivre : la partie que vous liriez appartient à un site, l'endroit où vous arrivez est choisi par celui qui a écrit le lien. Les fragments encodés dans la chaîne de requête sont courants dans les liens de suivi ordinaires et sont aussi le moyen de dissimuler une adresse ou une instruction à un coup d'œil rapide — rapporté, non accusé.
Des liens réécrits par un produit de sécurité
Les fournisseurs de messagerie et les services de filtrage remplacent les liens par les leurs afin que les clics passent par eux. Lorsque l'adresse d'origine est encodée dans la nouvelle, cet outil la décode et vous montre la véritable destination — jugez celle-là, pas l'enveloppe. Lorsque le service conserve l'original sur ses propres serveurs et ne laisse qu'une référence, il n'y a rien à décoder, et l'outil le dit au lieu de deviner.
Une charge hébergée sur un service auquel tout le monde fait confiance
N'importe qui peut déposer une page sur un service de documents ou de stockage connu et emprunter sa réputation. L'hébergeur n'est jamais un signal à lui seul — un lien vers un service légitime dans un message légitime est un lien vers un service légitime. Cela n'est soulevé que lorsque le message paraît par ailleurs usurper l'identité de quelqu'un, et même alors, c'est un signal modéré.
C'est limité aux marques de la liste. Juger qu'un message usurpe une marque suppose cette liste : cette vérification ne peut donc être soulevée que pour une marque que la liste porte — 52 d'entre elles. Un message usurpant une marque absente de la liste, hébergé sur ce même service, n'est pas signalé ici du tout. Voyez ce que cet outil ne peut pas détecter.
Encodage du texte
L'encodage déclaré contredit le contenu
Un message indique comment son texte doit être lu. Lorsque l'étiquette contredit les octets réels, tout s'affiche malgré tout — et c'est le but. Un filtre qui lit le message comme l'étiquette le dit voit un texte différent de celui que vous voyez, et un message peut être construit pour que la version lue par le filtre soit anodine.
Un encodage obsolète
Un encodage en particulier a été retiré des standards du web et n'est plus décodé par les navigateurs. Il survit presque uniquement comme moyen d'écrire du texte que les filtres de sécurité ne décodent pas.
Des caractères qui imitent des lettres ordinaires
Les formes mathématiques, cerclées et décorées se lisent comme des mots normaux pour une personne et sont d'autres caractères en dessous — c'est ainsi qu'un mot passe un filtre qui compare sur l'orthographe brute.
Les niveaux de gravité, et pourquoi il n'y a pas de score
Les constats portent l'un de quatre niveaux — Malveillant, Suspect, Informatif ou Aucun problème — et chacun est attribué par la règle qui l'a produit, non calculé. Le titre reprend le constat le plus grave présent.
Il n'y a pas de score numérique, et aucun n'est retenu. Il n'en existe pas. Un nombre suggérerait une précision que cette analyse n'a pas et appellerait un seuil — « en dessous de 30, c'est bon » — ce qui est exactement le raisonnement par lequel on se fait hameçonner par le message qui a obtenu 28. Quatre niveaux nommés et une phrase que vous pouvez répéter à un collègue sont plus honnêtes sur ce qui est réellement su.
Rien n'est jamais vert, et aucun résultat n'affirme qu'un message est sûr. Un résultat sans constat signifie que les vérifications qui se sont exécutées n'ont rien trouvé de risqué ; la mention de couverture présente sur chaque résultat vous dit lesquelles se sont exécutées.
Une approximation assumée : le domaine enregistré
L'alignement dépend de savoir où se termine un domaine enregistré — example.co.jp en est un, co.jp non. La norme DMARC actuelle le détermine par une séquence d'interrogations DNS en direct.
Cet outil n'émet aucune requête réseau d'aucune sorte, il ne peut donc pas faire ces interrogations. Il utilise à la place la Public Suffix List — une liste maintenue des terminaisons de domaine sous lesquelles on enregistre des noms — et en déduit le domaine enregistré.
Les deux approches concordent le plus souvent. Lorsqu'elles diffèrent, le résultat d'alignement affiché ici peut être plus strict ou plus permissif que ce qu'un serveur de messagerie destinataire calculerait. C'est une approximation, et elle est signalée sur chaque résultat qui s'en sert plutôt que laissée à votre découverte. C'est un arbitrage délibéré : l'autre solution serait un outil qui envoie les domaines de votre message à un résolveur DNS, et « votre message ne quitte jamais votre machine » cesserait alors d'être vrai.