Punycode et caractères similaires
Comment Punycode résout-il (ou envisage-t-il de résoudre) le problème avec des caractères identiques?
Dans la plupart des navigateurs, Punycode est désactivé à moins que vous ne l'activiez dans les préférences de langue.
Cela fonctionne très bien, sauf que de nombreux alphabets comme le cyrillique ont un a identique au a utilisé dans les scripts latins. Vous ne pouvez pas ignorer le script latin pour des raisons de compatibilité ascendante, ce qui m'amène à penser qu'ils doivent ignorer le cyrillique a.
Différents clients ont des atténuations différentes, mais le dénominateur commun est qu'ils empêchent généralement un attaquant de mélanger des homographes d'alphabets différents en retombant en punycode si plus d'un alphabet est utilisé:
Google Chrome versions 51 et supérieures utilisent un algorithme similaire à celui utilisé par Firefox. Les versions précédentes affichent un IDN uniquement si tous ses caractères appartiennent à une (et à une seule) des langues préférées de l'utilisateur.
L'approche de Safari consiste à rendre les jeux de caractères problématiques au format Punycode. Cela peut être modifié en modifiant les paramètres des fichiers système de Mac OS X.
Les versions 22 et ultérieures de Mozilla Firefox affichent les IDN si le TLD empêche les attaques par homographes en limitant le choix des caractères pouvant être utilisés dans les noms de domaine ou les libellés ne mélangeant pas les scripts de différentes langues. Sinon, les IDN sont affichés dans Punycode.
Pour parler de votre exemple spécifique de aa.com en script cyrillique, voici la règle de Google Chrome qui détecte cela et affiche punycode. Les autres navigateurs utilisent généralement des règles similaires:
- Si un nom d'hôte appartient à un TLD non-IDN (domaine de premier niveau) tel que "com", "net" ou "uk" et que toutes les lettres d'une étiquette donnée appartiennent à un ensemble de lettres cyrilliques ressemblant à du latin. lettres (par exemple, lettre cyrillique IE - е), affichez punycode.
Comment Punycode résout-il (ou envisage-t-il de résoudre) le problème avec des caractères identiques?
Il ne résout ni ne cherche à résoudre, puisqu'il n'a jamais été conçu pour cela (son seul but est de convertir une étiquette utilisant des caractères Unicode en une étiquette utilisant uniquement ASCII lettres minuscules, chiffres et tirets, et retour) et ce que vous sous-entendez est bien plus compliqué que vous ne le pensez.
Même problème purement en ASCII
Premièrement, ce n'est pas un problème à commencer par les IDN, vous avez exactement le même problème en ASCII! Dans certaines polices, 1 (le chiffre un), l (la lettre l) et i/I (la lettre i en minuscule ou en majuscule) peuvent apparaître très proches. et créer une ambiguïté.
L'ambiguïté est le plus souvent résolue par les humains immédiatement à cause du contexte qui les entoure, qui est plus difficile à comprendre pour les ordinateurs.
Il n'y a pas d'algorithme pour "résoudre" ce problème.
IDN
Les IDN sont à la croisée de différentes normes et réglementations:
- il existe le standard IETF: IDNA2003 (IDNA lui-même dans RFC3490 , Nameprep dans RFC3491 , Punycode in RFC3492 et Stringprep dans RFC3454 ), puis IDNA2008 (définitions dans RFC5890 , protocole in RFC5891 , points de code dans RFC5892 , scripts de droite à gauche dans RFC5893 et document générique pour background in RFC5894 ) fait en 2010, avec quelques différences majeures entre les deux, en résumé: IDNA2003 a été bloqué avec une version spécifique d'Unicode (d'où les caractères disponibles) où IDNA2008 est non, les deux utilisent Punycode pour passer de la forme internationalisée à celle de LDH mais IDNA2003 avait une étape préliminaire "StringPrep" qu'IDNA2008 n'a plus où certains caractères ont été remappés (ce qui crée des problèmes pour un caractère en allemand et un en grec, donc ils sont en grande partie des exceptions pour les registres ayant basculé vers IDNA2008 comme
.DE); cette FAQ à http: //www.unicode.org/faq/idn.html montre les différences, les similitudes et les problèmes entre eux - certaines recommandations Unicode, notamment UTS # 36 "Considérations sur la sécurité Unicode" avec sa section 2.8 consacrée à IDNA et aux "spoofs Punycode" et UTS # 46 "Unicode IDNA Traitement de compatibilité " qui concerne principalement le passage d'IDNA2003 à IDNA2008. Vous pouvez également consulter UTS # 39 "Mécanisme de sécurité Unicode" , il existe même une section complète sur "Détection de la confusion" et un fichier associé qui fournit une liste de "confusion". "Caractères (similaires similaires) (voir http: //www.unicode.org/Public/security/latest/confusables.txt )
- Les règles de l'ICANN, qui peuvent généralement être résumées comme suit:
- aucun TLD à caractère unique, 2 ASCII caractères sont des ccTLD, les autres gTLD
- Les TLD peuvent être des IDN, sous deux programmes différents: les ccTLD IDN ont une procédure accélérée, à la demande du gouvernement (et les célèbres attaques "homographiques" ou leur illusion ont eu un impact là-bas, par exemple, la Bulgarie a dû demander plusieurs fois ses TLD IDN qui c'est
bgen cyrillique qui devientБГ, jugé trop proche debrqui se tient devant le Brésil - et en fait, l'ICANN vient de publier des lignes directrices pour "l'atténuation des risques" de telles cases: https: //www.icann.org/en/system/files/files/guideline-risk-mitigation-measures-evaluation-28mar19-en.pdf ), et Les gTLD IDN ont été autorisés à faire une demande lors de l'ouverture de nouveaux TLD par l'ICANN 2010-2012. Il y en a donc quelques-uns, mais pas beaucoup (voir au bas de https: //www.iana.org/domains/root/db pour des exemples, pourquoi en bas? Parce qu'ils sont ordonnés par leur forme LDH, c'est-à-direxn--something, donc commençant évidemment parxils ne viennent pas en premier par ordre alphabétique) - la liste des caractères autorisés par TLD doit être un sous-ensemble des listes sur lesquelles travaille l'ICANN, en collaboration avec des experts linguistiques dans les langues appropriées: par exemple https: //www.icann.org/resources/pages/root-zone-lgr-2015-06-21-fr pour la zone racine (donc pour les TLD autorisés) ou autres par langue à https: //www.icann. org/resources/pages/second-level-lgr-2015-06-21-fr
- les registres sont censés publier leurs tables IDN (disponibles sur https: //www.iana.org/domains/idn-tables ) qui répertorient les caractères autorisés par "langage" ou script , autres règles et traitement des variantes
- et enfin l'une des règles les plus importantes et directement liées à votre problème: sauf cas particulier, car il est nécessaire dans certaines langues, vous n'êtes pas autorisé à mélanger, dans la même étiquette d'un nom de domaine, des caractères provenant de scripts Unicode différents
- et enfin, les règles propres du registre, qui peuvent être un sous-ensemble des points ci-dessus, ou non. Dans le passé, même pour les registres partageant les mêmes défis (comme
.cn,.tw,.kret.jppartageant certains caractères), tous n’ayant pas commencé à la même heure , les règles et la liste des caractères autorisés peuvent avoir été différentes (il existe des travaux pour converger sur des ensembles communs, à différents niveaux, mais cela prend du temps).
N'oubliez pas que tous les registres ne sont pas des gTLD et ne sont donc pas liés par les règles de l'ICANN, et que tous les registres ne suivent pas IDNA2008. C'est pourquoi, par exemple, vous pouvez enregistrer des noms de domaine avec des caractères emojis dans .ws car ce ccTLD vient de décider de l'accepter, car il s'agit de leur droit juridictionnel. Essayez http: // ???? .ws /! Mais voir ce document ICANN à l'adresse https: //www.icann.org/en/system/files/files/idn-emojis-domain-names-13feb19-en.pdf pour explications sur les problèmes liés aux émoticônes dans les noms de domaine (encore plus de cas de collisions graphiques possibles, ne prenant même pas en compte les nouveaux modificateurs FitzPatrick).
En pratique lors de l'enregistrement de domaine
Tous les bureaux d'enregistrement ne traitent pas les IDN et ne le font pas tous de la même manière. En règle générale, les registres attendent des bureaux d'enregistrement qu'ils envoient une "étiquette de langue" le long du nom de domaine à enregistrer. Cette balise de langue permet de sélectionner une liste spécifique de caractères autorisés car sinon, en l'absence de toute balise de langue, la seule règle qui prévaudra, outre les listes de caractères autorisées, est l'interdiction de mélanger deux caractères de scripts Unicode différents ( un script étant l'ensemble des caractères utilisés dans un système d'écriture donné).
L'étiquette de langue est nécessaire pour certaines langues qui doivent mélanger des caractères: si vous allez au Japon, vous verrez partout que des numéros tels que des numéros de téléphone ou des numéros d'étage sont écrits en caractères latins, pas avec les caractères japonais natifs. C'est un exemple parmi d'autres.
Pour faire écho à un point soulevé dans les commentaires ci-dessus, Verisign pour .COM publie différentes tables de caractères autorisés pour certaines balises de langue en cyrillique (comme le russe, l'ukrainien, le bulgare, le kurde, etc.). Consultez-les à l'adresse https: //www.verisign.com/en_US/channel-resources/domain-registry-products/idn/idn-policy/registration-rules/index.xhtml ). Si vous les regardez tous, vous verrez un sous-ensemble du script cyrillique Unicode plus ASCII chiffres de 0 à 9. Et si vous ne fournissez pas d'étiquette de langue, il vous suffit d'utiliser l'un des caractères autorisés par Verisign, à condition que tous figurent dans le même script, quel que soit le script utilisé.
Donc deux options:
- si vous essayez d'enregistrer
aа.comc'est-à-direxn--a-8sb.comen fournissant une balise de langue utilisant un caractère cyrillique, elle échouera car aucune table utilisant des caractères cyrilliques n'utilise également des caractères latins (en plus des chiffres) en même temps. - et si vous essayez de l'enregistrer sans spécifier de balises de langue, la règle de ne pas mélanger les caractères de plus d'un script s'applique et l'enregistrement sera refusé.
Donc, ce cas spécifique ne peut pas se produire de manière réelle, mais bien sûr, il y en a effectivement d'autres qui rendent le domaine "similaire à une confusion" à un autre.
Attaques homographiques IDN
C'est le problème spécifique sur lequel vous semblez vous concentrer, des ambiguïtés dans l'affichage car plusieurs personnages se ressemblent, car ils ont une représentation graphique similaire (homographique).
Tout d’abord un constat: cela est connu depuis longtemps, et pendant longtemps quiconque le découvre est sur le point de prédire le monde Doom à cause de toute la confusion qui sera créée. Dans la pratique, nous ne le voyons pas si peu ou si peu en réalité, il apparaît donc de temps en temps dans les journaux avec un cas spécifique, mais le reste du temps, il existe très peu de cas de cybersquattage de domaine basé sur des IDN, et très peu d'hameçonnage basé sur les IDN (pour cette dernière partie, car les attaquants n'ont pas besoin de l'illusion la plus parfaite pour réussir, ils ont juste besoin de l'illusion la plus basse qui soit suffisamment efficace pour leurs cibles; si vous regardez les emails de phishing et le type d'URL que vous trouvez vous y trouvez parfois des choses laides comme http://johndoe.tretre89.webhosting.somewhere.example.com/perso/misc/895f/bank.php?account=login et avec un texte créé autour et un bon lien, certaines personnes cliqueront encore sur cette pensée qui les mettra sur le site Web officiel de leur banque! Notez également que diverses sociétés fournissent services de surveillance de domaine aux marques, de sorte que l’enregistrement d’un domaine "semblable à une confusion" auprès d’une grande marque déclenche une alerte, tandis que les adresses URL ci-dessus, après avoir pénétré dans un hébergement Web, ne déclenchent aucune alerte avant le signaler comme phishing).
Donc, le problème/attaque existe sur le papier, mais dans la pratique, il reste pour le moment comme une affaire de curiosité et un cas Edge.
Les règles ci-dessus, et en particulier le non mélange de scripts, ont été spécifiquement mises en place pour limiter les problèmes de ce type. Comme décrit dans la réponse de Maximillian Laumeister, les navigateurs (mais rappelez-vous que nous traitons ici de noms de domaine qui apparaissent effectivement dans les URL, mais également dans de nombreux autres éléments, tels que les adresses électroniques ou les identifiants XMPP ... afin d'éviter tout problème d'interface utilisateur. contraint aux navigateurs Web) implémente généralement une règle pour revenir à la forme Punycode s’ils détectent un mélange de scripts ou pour certains TLD qu’ils jugent "dangereux".
Ils atténuent certains problèmes, mais pas tous.
Prenons раураӏ.com. Ceci est un nom de domaine valide et il peut être enregistré car tous les caractères (pour une étiquette donnée) sont dans un script. Mais en réalité, cela n’a rien à voir avec la version ASCII _ Paypal.com, car la première utilise uniquement des caractères cyrilliques et est traduite en LDH en xn--80aa0cbo65f.com. Comme expliqué au début, ce problème n'apparaît pas avec les IDN. Vous avez exactement le même problème si vous restez en ASCII pur.
Interdire de tels cas sera un problème très difficile avec de nombreux cas Edge et de faux positifs. Vous pouvez imaginer: prenons chaque caractère un par un et trouvons tous les autres caractères Unicode qui sont affichés graphiquement de la même manière pour une définition similaire, et une fois que nous avons cela, nous pouvons comparer les chaînes et déterminer que раураӏ (100 % Cyrillique) et Paypal (100% latin) sont "identiques" et s’il en existe un, l’autre devrait être interdit. Veuillez regarder UTS # 39 pour un algorithme permettant de le faire et toutes ses mises en garde.
Outre le problème de l'affichage graphique qui dépend de la police de caractères, une fois que vous avez pris en compte les caractères asiatiques ou arabes, les choses deviennent plus complexes (même si vous ne tenez pas compte du fait que toutes les langues ne sont pas écrites de gauche à droite, l'arabe n'est pas pour un), ce qui nous amène exactement au problème des variantes.
Les variations de variantes
Le chinois est un exemple célèbre et "simple". Il existe en effet un chinois "traditionnel" et un chinois "simplifié". Les deux existent toujours, en fonction du contexte ou de l'endroit, les noms de domaine doivent donc traiter avec les deux. Mais cela a-t-il du sens de permettre à deux déclarants distincts d'enregistrer l'un la version chinoise traditionnelle d'un nom et l'autre la version simplifiée? Probablement pas. Tant de registres définissent des variantes et une règle de blocage: une fois que vous définissez ce caractère, X est une variante du caractère Y, si X apparaît dans un nom, alors tout autre nom dans lequel X est remplacé par Y est interdit d’enregistrement ou ne l’est que par le même inscrit.
Parfois, les règles sont aussi éphémères: par exemple, .FR a introduit les IDN bien après le fait qu’il existait des millions de .FR noms de domaine existants, de sorte qu’ils ont mis en œuvre une approche de "droits acquis" qui, pour une période donnée, si vous aviez cafe.fr par exemple, vous étiez le seul déclarant éligible pour café.fr car il s'agissait de la "version" de fermeture IDN de celle-ci. Une fois cette période écoulée, tout nom de domaine ou toute variante de nom de domaine existant ne faisant que jouer avec des personnages était ouvert à l'enregistrement par quiconque. Mais encore une fois, rien qu'en lisant ceci, on peut penser que cela conduit à un chaos où, dans la pratique, comme observé dans ce cas ou dans un cas similaire, il n'y avait pas de réel problème (ce n'est pas un afflux massif de personnes qui essaient juste d'enregistrer des IDN pour confondre ASCII noms de domaine).
Cet extrait de Verisign FAQ à propos des IDN touche le sujet et livre la triste vérité:
Différents leaders d'opinion de la communauté technique ont suggéré différentes approches pour traiter le problème des variantes de personnage. Chaque approche comporte à la fois des aspects positifs et négatifs. Cependant, la communauté IDN est d’accord sur le fait que le problème des variantes de caractères peut ne jamais être complètement résolu car les langues sont toujours en mutation. De nouvelles variantes de caractères entre les langues continueront d'être introduites dans les langues.
Si vous examinez les tables IDN, vous verrez que les registres répertorient non seulement les caractères autorisés, par balise de langue, mais également les variantes de chaque caractère, le cas échéant. Cela crée un énorme problème de calcul lorsque les listes deviennent énormes.
Et ils n'encodent même pas tout ce qui est possible, car dans certaines langues, certains caractères ne peuvent pas apparaître à des endroits donnés ou après ou avant un autre caractère, etc. Pour gérer cela et l'avenir des tables IDN, l'IETF a créé une nouvelle norme appelée Règles de génération d'étiquettes, ou LGR, qui permet de coder toutes les règles relatives aux IDN et aux variantes dans une structure XML. N'espérez pas comprendre cette spécification sans une compréhension solide de l'Unicode, des expressions régulières et des noms de domaine.