Vérificateur d’homographes IDN

Les noms n’étaient qu’en ASCII pendant les deux premières décennies du DNS, c’est pourquoi tout ce qui les concerne se mesure en octets et en lettres : des étiquettes de lettres, de chiffres et de traits d’union, de 63 octets au maximum chacune, et 255 octets au total. Un nom de domaine internationalisé (IDN) est ce qui se produit lorsque les règles s’ouvrent au reste de l’Unicode, et le punycode (RFC 3492) est la règle d’orthographe qui permet à l’ancienne mécanique de continuer à fonctionner : une étiquette qui contient quoi que ce soit hors de l’ASCII s’écrit comme une étiquette xn--, une chaîne ASCII qui porte les mêmes caractères sous une forme repliée. 中文.com circule sous la forme xn--fiq228c.com, et les deux orthographes désignent le même hôte.

La partie qui compte ici, c’est ce que ne fait pas le punycode. Il convertit l’orthographe, et rien d’autre. Il n’a pas d’avis sur le fait qu’аpple.com devrait être autorisé à côtoyer apple.com, et on ne peut pas le lui demander, car cette question porte sur les yeux et les polices, non sur les octets. Le registre décide quels caractères il vend, le navigateur décide comment il affichera un nom qu’il juge sûr, et le lecteur décide s’il clique. Cette page répond à la question sous les trois : de quels caractères ce nom est-il réellement fait, et qu’est-ce que cela le fait écrire ?

Chaque ligne ci-dessous est exécutée par cette page au chargement, et de nouveau par le bouton Autotest ; la page doit signaler exactement ce que dit la ligne — les mêmes constats, le même niveau, la même forme DNS, le même nombre d’octets, ni plus ni moins. C’est ce qui donne de la valeur à une réponse propre ici : le chemin de code qui laisse passer un nom ordinaire est le même que celui qui attrape les astuces ci-dessous.

1. Extrayez le nom de ce que vous avez collé. Un nom nu est utilisé tel quel ; une URL voit son hôte extrait, le schéma, le port, le chemin et la requête sont supprimés, et la page indique lequel des deux cas elle a traité, plutôt que d’analyser discrètement une barre oblique comme si elle faisait partie d’un nom.
2. Nettoyez-le comme le ferait un client. Les caractères de contrôle, les caractères de largeur nulle et la marque d’ordre des octets sont retirés, un point pleine chasse ou idéographique compte comme un point, et un point final désigne la racine et non une erreur. Chaque caractère retiré ou réinterprété ainsi est signalé, car une espace de largeur nulle silencieusement supprimée est exactement ce dont vous devez être informé.
3. Découpez-le en étiquettes et mesurez chacune. Une étiquette ne peut pas être vide, commencer ou se terminer par un trait d’union, ni comporter deux traits d’union aux positions trois et quatre, sauf s’il s’agit d’une étiquette xn--. Chaque étiquette est mesurée en octets UTF-8 par rapport au plafond de 63 octets, et le nom entier par rapport à 255.
4. Décodez chaque étiquette xn-- vers ses caractères. L’étiquette décodée est ensuite réencodée une seconde fois et comparée à ce que vous avez saisi. Une étiquette qui ne survit pas à cet aller-retour n’est pas celle qu’elle prétend être, et une étiquette qui se décode en caractère de contrôle ou en rien du tout est signalée comme telle au lieu d’être discrètement supprimée.
5. Demandez ce qu’est chaque caractère. Son point de code, ses octets UTF-8, le script auquel il appartient, s’il fait partie d’un groupe de caractères dessinés de la même façon, et quels sont les autres membres de ce groupe. C’est ici qu’une a cyrillique cesse d’être « une lettre » pour devenir « une lettre dont la forme ressemble à une lettre latine ».
6. Repliez le nom sur la forme qu’il imite. Chaque caractère trompeur est remplacé par le caractère qu’il ressemble, ce qui transforme аpple.com en apple.com. Cette lecture repliée est la ligne la plus utile de la page, car apple.com est quelque chose sur quoi vous pouvez agir, alors que « une a cyrillique » ne l’est pas.
7. Rassemblez les constats et signalez le pire. Chaque constat n’est signalé qu’une fois, avec les étiquettes où il apparaît. Un nom qui n’a que l’air inhabituel produit des remarques plutôt que des constats : mélanger Han et kana, ou se terminer par le point racine, relève de l’écriture ordinaire et non d’un motif d’inquiétude.

aucun rien ici ne méritait d’être signalé — faible le même nom écrit d’une seconde façon — moyen un caractère que le DNS ne transportera pas, ou qui se replie sur une lettre ordinaire — élevé un nom construit pour être lu comme un autre nom, ou qui ne peut pas être envoyé du tout.

Un niveau est le pire sens que les constats peuvent avoir, et non une probabilité ni un jugement sur le site. Un nom parfaitement honnête peut être de niveau moyen parce qu’il contient un caractère hors de l’alphabet des noms d’hôte, et un nom malveillant peut être de niveau élevé avec rien de plus sophistiqué qu’une lettre cyrillique. La liste sous le niveau indique pourquoi, une ligne par constat, et c’est la partie qui vaut la peine d’être lue.

Le tableau ci-dessous est construit à partir de la même liste que celle dont la page rend compte, si bien qu’une ligne ici et un constat dans un résultat ne peuvent pas diverger. Un contrôle qui n’a rien trouvé est listé comme non : l’intérêt du tableau est de voir que la question a été posée et traitée, plutôt que de se demander si elle l’a été.

La même liste alimente les remarques, qui ne portent aucun niveau : une étiquette sans point, un point racine final, un domaine de premier niveau non ASCII, un séparateur autre qu’un point, un nom en majuscules, des caractères retirés pendant le nettoyage, et une URL réduite à son hôte.

Un nom est une liste d’étiquettes, et chacune est comptée en octets, non en caractères. Cette distinction est toute la raison d’être du punycode : 中文 compte deux caractères et six octets, et sa forme xn-- en compte quinze — c’est donc l’orthographe encodée qui doit tenir. La page applique les deux plafonds et indique lequel vous avez atteint.

Vous avez peut-être remarqué qu’un nom écrit en chinois, ou en cyrillique, apparaît parfois dans la barre d’adresse sous forme de charabia xn-- au lieu des caractères attendus. C’est le navigateur qui refuse d’afficher la forme agréable, et non le site qui n’aurait pas été enregistré. Un navigateur applique sa propre règle à un nom qu’il n’a encore jamais vu, et cette règle existe pour la raison même de toute cette page : afficher аpple.com comme аpple.com est exactement ce que veut un attaquant, si bien qu’un nom inconnu à scripts mélangés s’affiche dans son orthographe encodée jusqu’à ce qu’il ait été vu assez souvent pour être considéré comme fiable.

Le punycode est la RFC 3492, et l’autotest de cette page exécute en premier contrôle les onze étiquettes d’exemple imprimées dans ce document ; l’encodeur ici est donc vérifié par les exemples de la norme et non par lui-même. Les règles de traitement d’un IDN sont la RFC 5891 avec les tables de caractères de la RFC 5892, et la couche de compatibilité qu’appliquent réellement les navigateurs est l’UTS #46 avec l’indicateur non transitionnel ; cette page vous dit ce que font ces règles au lieu de prétendre les implémenter, et le repli qu’elle applique — NFC puis minuscules, puis RFC 3492 — est la même courte séquence qu’un client exécute avant d’envoyer un nom. Les groupes de formes, les plages de scripts et les tables de caractères invisibles de cette famille de pages ont été écrits à la main pour la famille : les normes sont nommées pour que vous puissiez les lire vous-même, et aucun de leurs textes n’est reproduit ici.

Un nom à scripts mélangés est-il toujours une attaque ?

Non, et le traiter ainsi serait faux d’une manière qui compte. Le japonais écrit les caractères han et les kana dans un même mot, et le coréen écrit des caractères han à l’intérieur de caractères hangul. Ce qui n’a aucune explication ordinaire, c’est le latin mélangé au cyrillique ou au grec dans une même étiquette, car ces écritures ne sont jamais utilisées ensemble dans une langue. La page trace cette ligne au lieu de signaler tout mélange, et c’est pourquoi les lignes japonaise et coréenne du tableau des cas ressortent propres.

Alors pourquoi mon propre nom ressort-il en moyen ?

Très probablement parce qu’il contient un caractère que l’alphabet des noms d’hôte n’inclut pas — un tiret bas, une espace, un accent écrit sous forme de caractère de compatibilité — et c’est un niveau moyen parce que le nom ne peut pas être envoyé tel quel. Moyen signifie « il faut y regarder », et non « c’est une contrefaçon ». Le constat sous le niveau nomme le caractère exact et sa position.

La page indique-t-elle si un nom est dangereux, enregistré ou joignable ?

Non, sur les trois points. Elle ne touche jamais le réseau et ne résout jamais rien, donc elle ne peut pas savoir si un nom existe ni qui le possède, et elle ne dit délibérément rien de ce que fait un site. Elle répond à une question plus étroite que vous pouvez vérifier vous-même : de quels caractères ce nom est-il fait, et si je replie les caractères trompeurs sur les lettres qu’ils imitent, qu’est-ce qu’il écrit ?

Mon nom est en chinois et la page indique que le domaine de premier niveau n’est pas ASCII. Y a-t-il un problème ?

Rien ne cloche. Un domaine de premier niveau chinois circule comme une étiquette xn-- à part entière ; la dernière étiquette du nom est donc écrite sous sa forme encodée, et la page le signale. Les remarques ne portent aucun niveau, car elles décrivent un fait et non un problème.

Pourquoi la ligne « se lit comme » affiche-t-elle parfois le même nom que celui saisi ?

Parce que la page n’affiche une lecture repliée que lorsque le repli change réellement quelque chose. Si chaque caractère du nom a déjà la forme qu’il imite, la lecture repliée et le nom sont la même chaîne, et il n’y a rien à vous signaler.

Qu’est-ce qu’une étiquette A et une étiquette U ?

Une étiquette A est l’orthographe ASCII qui circule : xn--fiq228c. Une étiquette U est la même étiquette écrite dans le script auquel elle appartient : 中文. Ce sont deux orthographes d’une même étiquette, et la page affiche les deux pour chaque étiquette qu’elle décode afin que vous voyiez ce que cache une étiquette encodée.