Séparer l’internationalisation de l’usurpation d’identité
Les noms de domaine internationalisés permettent aux utilisateurs d'utiliser des étiquettes de domaine au-delà des lettres, chiffres et traits d'union ASCII traditionnels. Cette capacité est légitime et importante. Le problème de sécurité n'est pas la présence d'un script particulier ; il s'agit de savoir si un identifiant affiché peut être confondu avec une autre identité dans un contexte conséquent. Une enquête sur un homographe ou un domaine pouvant être confondu doit donc préserver le nom réel, sa représentation DNS validée et la présentation du destinataire sans déclarer malveillant chaque nom non-ASCII.
RFC 5890 définit la terminologie pour les noms de domaine internationalisés dans les applications, y compris les labels A et U. Norme technique Unicode 39 décrit les mécanismes d'identification des chaînes pouvant prêter à confusion. Ce sont des tâches liées mais différentes. La représentation et la validité de l'IDNA ne constituent pas un verdict sur l'affiliation ; une comparaison de confusion ne constitue pas une preuve de fraude. Cet article propose une méthode d'examen défensif sans enregistrer de noms, sans envoyer de messages ni visiter des domaines suspects.
Conserver les formulaires au lieu de les réduire
La section 2.3.2.1 RFC 5890 définit une étiquette A comme la forme compatible ASCII d'une étiquette valide IDNA et une étiquette U comme sa forme Unicode selon les exigences spécifiées. Toutes les chaînes commençant par le préfixe familier xn-- ne sont pas des étiquettes A valides. Un analyseur doit valider la relation plutôt que de traiter le préfixe seul comme preuve. De même, une chaîne Unicode arbitraire n'est pas automatiquement une étiquette U valide simplement parce qu'elle ressemble à une étiquette de domaine.
Conserver la valeur brute observée avant la transformation. Enregistrez ensuite l'analyseur et la version utilisée, les formulaires d'étiquettes validés qu'il a produits et toutes les erreurs. Conservez la valeur affichée du client de messagerie comme observation distincte. Une capture d'écran peut documenter l'apparence, mais elle ne peut pas remplacer les points de code sous-jacents ou l'adresse analysée. Ce manuscrit n'a pas exécuté d'outil de normalisation et ne fournit pas de conversions prétendument mesurées. Des exemples réels doivent être générés et conservés dans le cadre d’un exercice de preuves autorisé.
Un squelette confus n'est pas un nom DNS
Unicode TR39 décrit la détection de confusion à l'aide de transformations et de données définies. Le document actuel retenu inclut un traitement de squelette sensible à la direction et note que les comparaisons peuvent être trop inclusives. Un squelette est un artefact de comparaison. Il ne doit pas être utilisé comme adresse à interroger, comme domaine à autoriser ou comme valeur à publier dans DNS . Deux chaînes correspondant selon une méthode de comparaison ne deviennent pas le même domaine ni n'acquièrent le même propriétaire.
Enregistrez la version des données Unicode, l'algorithme et les hypothèses de direction pertinentes lorsque vous utilisez une telle méthode. Ne simplifiez pas la spécification actuelle en une instruction non documentée consistant à mettre en minuscules et à remplacer des caractères visuellement similaires. Ce serait un algorithme différent avec un comportement inconnu. Si un produit offre un score de similarité, conservez la méthode et les limites du produit séparément de la norme. Un score peut donner la priorité à l'examen humain sans établir d'intention malveillante ou le comportement d'affichage réel d'un destinataire.
La présentation dépend de l'application consommatrice
Le même domaine sous-jacent peut être présenté différemment selon les applications et les contextes. Ne promettez pas que chaque client de messagerie affiche Unicode, expose toujours un formulaire ASCII ou avertit systématiquement des scripts mixtes. Un résultat de récepteur actuel nécessite une observation réelle du client, de la version, de la plate-forme et du contexte du message pertinents. Cet article n'a pas effectué ces observations et ne prétend donc pas qu'un fournisseur particulier afficherait ou bloquerait un nom de test spécifique.
Lors de la collecte ultérieure de preuves autorisées, préservez à la fois l’identité brute et ce que l’utilisateur a vu. Indiquez si l'adresse a été développée ou réduite, si le nom d'affichage a été affiché séparément et quelle interface a fourni un avertissement. Évitez de généraliser une capture d'écran à tous les destinataires. L'évaluation de l'accessibilité est également importante : une ressemblance visuelle et un rendu oral peuvent créer différents problèmes de compréhension, mais ni l'un ni l'autre ne doivent être affirmés sans un exemple observé approprié.
L'authentification suit les domaines, pas la ressemblance perçue
RFC 9989, section 2.2, indique que DMARC ne traite pas des noms de domaine visuellement similaires ni des abus de noms d'affichage. Un domaine distinct peut authentifier le courrier lui-même même lorsqu'un destinataire le prend pour une organisation de confiance. Ce n'est pas une raison pour arrêter de vérifier alignement. C'est une raison pour préserver la distinction entre le domaine réel et l'identité que le destinataire a déduite de son apparence.
Utilisez des preuves d'authentification du destinataire digne de confiance, en respectant les préoccupations relatives aux limites de confiance décrites dans RFC 8601. Enregistrez quel domaine authentifié et quel domaine visible From a été évalué. Ne remplacez pas ces domaines par un squelette confus avant d’évaluer leur relation. La normalisation d’un affichage à des fins de comparaison ne doit pas modifier silencieusement l’identité du protocole étudié. Conservez le résultat de l’authentification et le problème de reconnaissance humaine comme des observations liées mais distinctes.
Une feuille de travail identité-représentation
Créez une feuille de calcul avec le champ de message d'origine, le domaine brut extrait, la représentation de points de code si nécessaire, les formulaires A-label et U-label validés, la version de l'analyseur, le résultat de la validation et le formulaire client affiché. Ajoutez la cible de comparaison à partir d'un enregistrement commercial fiable, la méthode et la version de détection de confusion, le résultat de la comparaison, la provenance de l'authentification du destinataire et l'action demandée. Incluez des colonnes distinctes pour les faits observés et l’interprétation des analystes.
Pour des raisons de confidentialité, supprimez le contenu des messages et les identifiants personnels sans rapport tout en préservant les distinctions de domaine exactes nécessaires pour le cas. Ne publiez pas un véritable domaine suspect sous forme de lien cliquable simplement pour illustrer la feuille de travail. Utilisez une présentation de preuves non interactive approuvée. Si des chaînes fictives sont utilisées à des fins pédagogiques, étiquetez-les comme étant illustratives et ne prétendez pas qu'elles ont été enregistrées, acceptées par un fournisseur ou affichées par un destinataire. Un résultat fabriqué de toutes pièces irait à l’encontre de l’objectif de l’exigence de preuve.
Diagnostic fictif : un nom qui semble familier
Un analyste des achats fictif remarque qu'un message fournisseur semble utiliser un nom familier, mais qu'une vue d'adresse étendue révèle un domaine sous-jacent différent. L'équipe de sécurité propose de conserver l'adresse brute et de comparer les représentations validées à l'aide d'un outil documenté. À ce stade, l’équipe s’inquiète de la confusion et non de la preuve d’une intention malveillante ou d’une propriété. La modification demandée de l'enregistrement fournisseur reste suspendue dans le cadre du processus commercial normal.
L'équipe vérifierait l'affiliation via un contact fournisseur déjà enregistré de manière indépendante. Il conserverait également les preuves réelles du récepteur si une enquête autorisée se poursuit. Le cas hypothétique n'inclut délibérément aucune conversion Unicode inventée, aucune sortie squelette ou aucune affirmation selon laquelle un client de messagerie nommé affiche une chaîne particulière. Ce sont des observations qui doivent être recueillies, et non des détails à compléter pour des raisons de commodité narrative. Aucun domaine n'a été interrogé, enregistré ou utilisé pour envoyer du courrier lors de ce travail.
Libérez uniquement avec les exemples requis
Une conclusion défendable distingue la représentation valable, la similarité, l’affiliation, l’authentification et le préjudice observé. Il peut affirmer qu'une méthode de comparaison a révélé une confusion sans prétendre à un crime. Il peut indiquer qu'un domaine différent s'est authentifié sans certifier la demande commerciale. Il peut documenter la présentation d'un destinataire sans prétendre que chaque récepteur se comporte de la même manière. Ces distinctions rendent les conseils qui en résultent utiles dans le cadre d’enquêtes légitimes de dénomination internationalisée ainsi que d’usurpation d’identité.
Le catalogue nécessite des exemples d'identité bruts et affichés avec des formulaires DNS normalisés et des résultats de récepteur. Ces observations originales restent ouvertes. Ce manuscrit contient une feuille de travail et un processus de diagnostic fictif, et non des preuves. L'examen par un spécialiste humain, l'applicabilité des sources, les itinéraires de production, l'accessibilité visuelle et la libération du propriétaire restent également ouverts. La publication nécessite des exemples conservés et autorisés avec des versions exactes des outils et des résultats observés, examinés sans exposer de données personnelles inutiles ni faire d'allégations non étayées sur un opérateur de domaine.