Kontroll av IDN-homografer

Namn var bara ASCII under de första två decennierna av DNS, och därför mäts allt kring dem i byte och bokstäver: etiketter av bokstäver, siffror och bindestreck, högst 63 byte var, högst 255 byte totalt. Ett internationaliserat domännamn (IDN) är vad som händer när reglerna öppnas för resten av Unicode, och punycode (RFC 3492) är stavningsregeln som håller den gamla mekaniken igång: en etikett som innehåller något utanför ASCII skrivs som en xn---etikett, en ASCII-sträng som bär samma tecken i vikt form. 中文.com färdas som xn--fiq228c.com, och båda stavningarna anger samma värd.

Det som spelar roll här är vad punycode inte gör. Den omvandlar stavning och ingenting annat. Den har ingen åsikt om huruvida аpple.com bör tillåtas stå bredvid apple.com, och den kunde inte tillfrågas, eftersom den frågan gäller ögon och teckensnitt snarare än byte. Registret bestämmer vilka tecken det säljer, webbläsaren bestämmer hur den visar ett namn den anser vara säkert, och läsaren avgör om den klickar. Den här sidan svarar på frågan under alla tre: vilka tecken består det här namnet faktiskt av, och vad gör det att det stavar?

Varje rad nedan körs av sidan när den laddas och igen av knappen Självtest, och sidan måste rapportera exakt vad raden säger — samma fynd, samma nivå, samma DNS-form, samma byteantal, varken mer eller mindre. Det är det som gör ett rent svar här värdefullt: kodvägen som släpper igenom ett vanligt namn är samma som fångar fuskerierna nedan.

1. Plocka ut namnet ur det som klistrats in. Ett rent namn används som det är; en URL får sin värd utplockad och schema, port, sökväg och frågesträng tas bort, och sidan anger vilket av de två den gjorde i stället för att tyst analysera ett snedstreck som om det var en del av ett namn.
2. Rensa det så som en klient gör. Styrtecken, teckenlösa tecken och byteordningsmarkeringen tas bort, ett fullbreddspunkt eller ideografisk punkt räknas som en punkt, och en avslutande punkt är roten och inte ett misstag. Varje tecken som tas bort eller tolkas om på det här sättet rapporteras, eftersom ett teckenlöst mellanslag som i tysthet tagits bort är precis det man behöver få veta.
3. Dela upp det i etiketter och mät varje. En etikett får inte vara tom, börja eller sluta med bindestreck, eller ha två bindestreck i position tre och fyra om den inte är en xn---etikett. Varje etikett mäts i UTF-8-byte mot taket på 63 byte, och hela namnet mot 255.
4. Avkoda varje xn---etikett tillbaka till dess tecken. Den avkodade etiketten kodas sedan en andra gång och jämförs med det som skrevs in. En etikett som inte klarar den rundresan är inte den etikett den påstår sig vara, och en som avkodas till ett styrtecken eller till ingenting alls rapporteras som sådan i stället för att tyst tas bort.
5. Fråga vad varje tecken är. Dess kodpunkt, dess UTF-8-byte, skriften den tillhör, om det ligger i en grupp av tecken som ritas likadant, och vilka de andra medlemmarna i gruppen är. Det är här ett kyrilliskt a slutar vara ”en bokstav” och blir ”en bokstav som formas som en latinsk”.
6. Vik namnet till den form det härmar. Varje likande tecken ersätts med det tecken det liknar, vilket gör аpple.com till apple.com. Den vikta läsningen är den enskilt mest användbara raden på sidan, eftersom apple.com är något man kan agera på medan ”ett kyrilliskt a” inte är det.
7. Samla fynden och rapportera det värsta. Fynden rapporteras en gång var, med de etiketter där de förekommer. Ett namn som bara ser ovanligt ut ger anmärkningar i stället för fynd: att blanda Han och Kana, eller att sluta med rotpunkten, är vanlig skrift och ingen anledning till oro.

ingen inget här var värt att nämna — låg samma namn skrivet på ett andra sätt — medium ett tecken som DNS inte bär, eller ett som viks till en vanlig bokstav — hög ett namn byggt för att läsas som ett annat namn, eller ett som inte alls kan skickas.

En nivå är det värsta som fynden kan betyda, inte en sannolikhet och inte ett omdöme om webbplatsen. Ett helt ärligt namn kan vara medium eftersom det innehåller ett tecken utanför alfabetet för värdnamn, och ett fientligt namn kan vara hög med inget mer sofistikerat än en kyrillisk bokstav. Listan under nivån anger varför, en rad per fynd, och den listan är den del som är värd att läsa.

Tabellen nedan byggs av samma lista som sidan rapporterar från, så en rad här och ett fynd i ett resultat kan inte motsäga varandra. En kontroll som inte hittade något listas som nej: poängen med tabellen är att man kan se att frågan ställdes och besvarades, i stället för att undra om den över huvud taget ställdes.

Samma lista driver anmärkningarna, som inte har någon nivå alls: en etikett utan punkt i, en avslutande rotpunkt, en toppdomän som inte är ASCII, en avgränsare som inte är en punkt, ett namn med versaler, tecken som togs bort vid rensning, och en URL som reducerades till sin värd.

Ett namn är en lista med etiketter och var och en räknas i byte, inte i tecken. Den skillnaden är hela anledningen till att punycode finns: 中文 är två tecken och sex byte, och dess xn---form är femton tecken, så det är den kodade stavningen som måste rymmas. Sidan tillämpar båda taken och anger vilket av dem som träffades.

Det kan ha märkts att ett namn skrivet på kinesiska eller kyrilliska ibland visas i adressfältet som xn---kladd i stället för de tecken som förväntas. Det är webbläsaren som avstår från att visa den fina formen, inte att webbplatsen misslyckas med att registrera den. En webbläsare tillämpar en egen regel på ett namn den aldrig sett förut, och regeln finns av samma skäl som hela den här sidan finns: att visa аpple.com som аpple.com är exakt vad en angripare vill, så ett okänt namn med blandad skrift visas i sin kodade stavning tills det har sett tillräckligt ofta för att litas på.

Punycode är RFC 3492, och självtestet på den här sidan kör de elva exempeletiketterna som står i dokumentet som sin första kontroll, så kodaren här hålls till exemplen i standarden snarare än till sig själv. Bearbetningsreglerna en IDN går igenom är RFC 5891 med teckentabellerna i RFC 5892, och kompatibilitetslagret som webbläsare faktiskt tillämpar är UTS #46 med den icke-övergångsflaggan; den här sidan säger vad reglerna gör i stället för att låtsas implementera dem, och vikningen den tillämpar — NFC och sedan gemener, sedan RFC 3492 — är samma korta sekvens som en klient utför innan ett namn skickas. Teckengrupperna, skriftområdena och tabellerna över osynliga tecken i den här familjen av sidor skrevs för hand för familjen: standarderna anges så att man kan läsa dem själv, och ingen text från dem återges här.

Är ett namn med blandad skrift alltid en attack?

Nej, och att behandla det så vore fel på ett sätt som spelar roll. Japanska skriver kanji och kana i samma ord, och koreanska skriver hanja inuti hangul. Det som inte har någon vanlig förklaring är latin blandat med kyrilliska eller grekiska i en och samma etikett, eftersom de skrifterna inte används tillsammans i något språk, och sidan drar gränsen där i stället för att flagga varje blandning. Det är därför de japanska och koreanska raderna i fallstabellen ovan kommer tillbaka rena.

Varför visas mitt eget namn som medium, då?

Troligen, eftersom det innehåller ett tecken som alfabetet för värdnamn inte omfattar — ett understreck, ett blanksteg, en accent skriven som ett kompatibilitetstecken — och det är medium eftersom namnet inte kan skickas som det är. Medium betyder ”det här behöver en titt”, inte ”det här är en förfalskning”. Fyndet under nivån anger det exakta tecknet och dess position.

Berättar sidan om ett namn är farligt, registrerat eller nåbart?

Nej, i alla tre fallen. Den rör aldrig nätverket och slår aldrig upp något, så den kan inte veta om ett namn finns eller vem som äger det, och den säger medvetet ingenting om vad en webbplats gör. Den svarar på en smalare fråga som man själv kan kontrollera: vilka tecken består det här namnet av, och om jag viker de likande tecknen till de bokstäver de härmar, vad stavar det?

Mitt namn är på kinesiska och sidan säger att toppdomänen inte är ASCII. Är något fel?

Inget är fel. En kinesisk toppdomän färdas som en xn---etikett för sig själv, så den sista etiketten i namnet skrivs i sin kodade form och sidan noterar det. Anmärkningar får ingen nivå eftersom de beskriver ett faktum snarare än ett problem.

Varför visar raden läses-som ibland samma namn som jag skrev?

Eftersom sidan bara visar en vikt läsning när vikningen faktiskt ändrar något. Om varje tecken i namnet redan har den form det härmar, är den vikta läsningen och namnet samma sträng och det finns ingenting att berätta.

Vad är en A-etikett och en U-etikett?

En A-etikett är den ASCII-stavning som färdas: xn--fiq228c. En U-etikett är samma etikett skriven i den skrift den tillhör: 中文. De är två stavningar av samma etikett, och sidan visar båda för varje etikett den avkodar så att man kan se vad en kodad etikett döljer.