Verificador de homógrafos IDN

Os nomes eram apenas ASCII durante as primeiras duas décadas do DNS, razão pela qual tudo o que lhes diz respeito se mede em bytes e letras: etiquetas de letras, algarismos e hífenes, no máximo 63 bytes cada uma, no máximo 255 bytes no total. Um nome de domínio internacionalizado (IDN) é o que acontece quando as regras são abertas ao resto do Unicode, e o punycode (RFC 3492) é a regra de grafia que mantém a velha maquinaria a funcionar: uma etiqueta que contenha algo fora do ASCII é escrita como uma etiqueta xn--, uma cadeia ASCII que transporta os mesmos caracteres numa forma reduzida. 中文.com viaja como xn--fiq228c.com, e ambas as grafias nomeiam o mesmo servidor.

A parte que importa aqui é o que o punycode não faz. Converte a grafia e mais nada. Não tem opinião sobre se аpple.com deve ser permitido ao lado de apple.com, e não poderia ser questionado sobre isso, porque essa questão diz respeito a olhos e tipos de letra, e não a bytes. O registo decide que caracteres vende, o navegador decide como mostrará um nome que considera seguro, e o leitor decide se clica. Esta página responde à questão por baixo das três: de que caracteres é feito realmente este nome, e o que é que isso faz soletrar?

Cada linha abaixo é executada por esta página quando carrega e novamente pelo botão Autoteste, e a página tem de relatar exatamente o que a linha diz — as mesmas conclusões, o mesmo nível, a mesma forma DNS, a mesma contagem de bytes, nem mais nem menos. É isso que faz de uma resposta limpa aqui algo que vale alguma coisa: o caminho de código que deixa passar um nome comum é o mesmo que apanha os truques abaixo.

1. Retire o nome do que colou. Um nome simples é usado tal como está; um URL tem o seu servidor extraído, sendo retirados o esquema, a porta, o caminho e a query, e a página indica qual das duas coisas fez, em vez de analisar em silêncio uma barra como se fizesse parte de um nome.
2. Limpe-o como um cliente faria. Os caracteres de controlo, os de largura zero e a marca de ordem de bytes são removidos, um ponto final de largura total ou ideográfico conta como um ponto, e um ponto final é a raiz e não um erro. Cada carácter removido ou reinterpretado desta forma é relatado, porque um espaço de largura zero removido em silêncio é exatamente o que precisa de saber.
3. Divida-o em etiquetas e meça cada uma. Uma etiqueta não pode estar vazia, nem começar ou terminar com hífen, nem ter dois hífenes nas posições três e quatro, a menos que seja uma etiqueta xn--. Cada etiqueta é medida em bytes UTF-8 face ao limite de 63 bytes, e o nome inteiro face a 255.
4. Descodifique cada etiqueta xn-- nos seus caracteres. A etiqueta descodificada é depois codificada uma segunda vez e comparada com o que escreveu. Uma etiqueta que não sobrevive a esta ida e volta não é a etiqueta que afirma ser, e uma que se descodifica num carácter de controlo ou em nada é relatada como tal, em vez de ser descartada em silêncio.
5. Pergunte o que é cada carácter. O seu ponto de código, os seus bytes UTF-8, o alfabeto a que pertence, se está num grupo de caracteres que são desenhados de forma semelhante, e quais são os outros membros desse grupo. É aqui que um a cirílico deixa de ser « uma letra » e passa a ser « uma letra com a forma de uma latina ».
6. Reduza o nome à forma que imita. Cada carácter parecido é substituído pelo carácter a que se assemelha, o que transforma аpple.com em apple.com. Essa leitura reduzida é a linha mais útil da página, porque apple.com é algo em que pode atuar, ao passo que « um a cirílico » não é.
7. Reúna as conclusões e relate a pior. As conclusões são relatadas uma vez cada, com as etiquetas em que ocorrem. Um nome que apenas parece invulgar produz notas em vez de conclusões: misturar Han e Kana, ou terminar no ponto da raiz, é escrita normal e não motivo de preocupação.

nenhum nada aqui merecia ser mencionado — baixo o mesmo nome escrito uma segunda vez — médio um carácter que o DNS não transporta, ou um que se reduz a uma letra simples — alto um nome construído para ser lido como outro nome, ou um que não pode ser enviado de todo.

Um nível é o pior que as conclusões podem significar, não uma probabilidade e não um juízo sobre o site. Um nome perfeitamente honesto pode ser médio por conter um carácter fora do alfabeto de nomes de servidor, e um nome hostil pode ser alto sem nada mais sofisticado do que uma letra cirílica. A lista sob o nível diz porquê, uma linha por conclusão, e essa lista é a parte que vale a pena ler.

A tabela abaixo é construída a partir da mesma lista que a página relata, pelo que uma linha aqui e uma conclusão num resultado não podem discordar. Uma verificação que não encontrou nada aparece como não: o objetivo da tabela é que possa ver que a pergunta foi feita e respondida, em vez de se perguntar se alguma vez foi feita.

A mesma lista alimenta as notas, que não têm nível algum: uma etiqueta sem ponto, um ponto final da raiz, um domínio de topo que não é ASCII, um separador que não é ponto, um nome em maiúsculas, caracteres removidos durante a limpeza, e um URL reduzido ao seu servidor.

Um nome é uma lista de etiquetas, e cada uma é contada em bytes, não em caracteres. Essa distinção é a razão de ser do punycode: 中文 são dois caracteres e seis bytes, e a sua forma xn-- tem quinze caracteres, pelo que é a grafia codificada que tem de caber. A página aplica os dois limites e indica qual deles atingiu.

Pode ter reparado que um nome escrito em chinês, ou em cirílico, por vezes aparece na sua barra de endereços como lixo xn-- em vez dos caracteres que espera. É o navegador a recusar-se a mostrar a forma bonita, e não o site a falhar no registo. Um navegador aplica uma regra própria a um nome que nunca viu antes, e a regra existe pela razão que justifica esta página inteira: mostrar аpple.com como аpple.com é exatamente o que um atacante quer, pelo que um nome de escrita mista desconhecido é mostrado na sua grafia codificada até ter sido visto com frequência suficiente para ser considerado fiável.

O punycode é a RFC 3492, e a autoverificação desta página executa as onze etiquetas de exemplo impressas nesse documento como primeira verificação, pelo que o codificador aqui é avaliado pelos exemplos da norma e não por si próprio. As regras de processamento por que passa um IDN são a RFC 5891 com as tabelas de caracteres da RFC 5892, e a camada de compatibilidade que os navegadores realmente aplicam é a UTS #46 com a marca não transitória; esta página diz-lhe o que essas regras fazem em vez de fingir que as implementa, e a redução que aplica — NFC, depois minúsculas, depois RFC 3492 — é a mesma sequência curta que um cliente executa antes de enviar um nome. Os grupos de forma, os intervalos de alfabeto e as tabelas de caracteres invisíveis desta família de páginas foram escritos à mão para a família: as normas estão nomeadas para que as possa ler por si, e nenhum texto delas é reproduzido aqui.

Um nome de escrita mista é sempre um ataque?

Não, e tratá-lo assim seria errado de uma forma que importa. O japonês escreve caracteres Han e Kana na mesma palavra, e o coreano escreve caracteres Han dentro de caracteres Hangul. O que não tem explicação comum é o latim misturado com cirílico ou grego numa só etiqueta, porque esses alfabetos não são usados em conjunto em nenhuma língua, e a página traça essa linha em vez de assinalar toda e qualquer mistura. É por isso que as linhas japonesa e coreana da tabela de casos acima voltam limpas.

Então porque é que o meu próprio nome aparece como médio?

Muito provavelmente porque contém um carácter que o alfabeto de nomes de servidor não inclui — um sublinhado, um espaço, um acento escrito como carácter de compatibilidade — e isso é médio porque o nome não pode ser enviado tal como está. Médio significa « isto merece um olhar », não « isto é uma falsificação ». A conclusão sob o nível indica o carácter exato e a sua posição.

A página diz-me se um nome é perigoso, registado ou acessível?

Não, nas três. Nunca toca na rede e nunca resolve nada, pelo que não pode saber se um nome existe nem quem o possui, e diz deliberadamente nada sobre o que um site faz. Responde a uma pergunta mais estreita que pode verificar por si: de que caracteres é feito este nome, e se eu reduzir os parecidos às letras que imitam, o que é que ele soletra?

O meu nome está em chinês e a página diz que o domínio de topo não é ASCII. Há algum problema?

Nada está errado. Um domínio de topo chinês viaja como uma etiqueta xn-- própria, pelo que a última etiqueta do nome é escrita na sua forma codificada, e a página assinala-o. As notas não têm nível porque descrevem um facto e não um problema.

Porque é que a linha « lê-se como » por vezes mostra o mesmo nome que escrevi?

Porque a página só mostra uma leitura reduzida quando a redução altera de facto alguma coisa. Se cada carácter do nome já tiver a forma que imita, a leitura reduzida e o nome são a mesma cadeia, e não há nada a dizer.

O que é uma etiqueta A e uma etiqueta U?

Uma etiqueta A é a grafia ASCII que viaja: xn--fiq228c. Uma etiqueta U é a mesma etiqueta escrita no alfabeto a que pertence: 中文. São duas grafias de uma mesma etiqueta, e a página mostra ambas para cada etiqueta que descodifica, para que possa ver o que uma etiqueta codificada esconde.