Cómo transformar un protocolo de redes en un viaje a la dimensión desconocida

Información introductoria: IDN es el estándar de nombres de dominio internacionalizados (con eñes, acentos, otros diacríticos, otros alfabetos, etc.) desarrollado en el IETF. El antiguo estándar (IDN versión 2003) va a ser sustituido por uno nuevo (IDN versión 2008) que desgraciadamente no es completamente compatible hacia atrás. Es decir, hay IDNs que son válidos según IDN2003 que dejarán de serlo cuando se despliegue IDN2008. La ventaja de IDN2008 es que no está limitado a Unicode 3.2. Con el uso de Unicode 5.1 IDN2008 permitirá nuevos nombres de dominios en muchos lenguajes que antes no eran posibles.

Este documento del consorcio Unicode (un borrador del Unicode Technical Standard 46) propone una solución para aliviar el problema de la falta de compatibilidad hacia atrás entre IDN2008 y IDN2003: un mapeado de ciertos caracteres en otros a modo de puente entre los estándares. En principio buena idea, hasta que el documento sugiere por razones de “seguridad” que una aplicación compare en DNS si hay una “divergencia en el registro” entre el dominio mapeado y el no mapeado. Trataré de ilustrar esta idea con un caso concreto.

El carácter ZWJ (zero-width joiner o "conector de anchura cero") es un carácter permitido en IDN2008 y que en IDN2003 realmente no lo era. ZWJ es necesario, por ejemplo, para expresar en Unicode el nombre de Sri Lanka usando el lenguaje local cingalés (ver línea A, primera columna):


Si no se usa el ZWJ, el conglomerado "Sri" se desmorona (como se puede apreciar en la línea C). ZWJ es, pues, como una especie de pegamento entre caracteres que interaccionan entre sí. Desgraciadamente por sí solo ZWJ es un carácter invisible, así que el nombre de dominio www.ejemplo[ZWJ].de es visualmente indiferenciable de www.ejemplo.de. Ya os imagináis ahora por dónde van los tiros del problema, ¿verdad?

UTS46 propone que si una aplicación encuentra el nombre de dominio banco-perico-de-los-palotes[ZWJ].de, haga dos consultas de DNS para averiguar primero la dirección IP de banco-perico-de-los-palotes[ZWJ].de y luego la de banco-perico-de-los-palotes.de, y que a continuación compare los resultados. En caso de que los resultados no fueran iguales ("divergencia en el registro") nos encontraríamos, según el documento, ante un compromiso de seguridad. Y es aquí cuando empezamos a jugar con fuego y a adentrarnos en la Twilight Zone.


Pregunta 1: Si banco-perico-de-los-palotes.de y banco-perico-de-los-palotes[ZWJ].de tienen la misma dirección IP, ¿he descartado de verdad que tras el segundo se esconde una página web fraudulenta?

No, no está descartado. El malvado estafador podría registrar intencionadamente banco-perico-de-los-palotes[ZWJ].de por medio del mismo agente registrador que su víctima. Si se trata de un agente registrador grande, hay bastantes posibilidades de que las páginas web de muchos dominios sean servidos por un solo servidor web (es decir, una sola dirección IP). Y es que la página web solicitada por un navegador no se determina por la dirección IP del servidor web al que se dirige, sino que es una información contenida en la petición HTTP.

Pregunta 2: ¿Está garantizado que dos consultas idénticas y consecutivas en el DNS (por ejemplo sobre la dirección IP de banco-muy-legal.de) vayan a recibir dos respuestas idénticas?

No, no está garantizado. Hay muchas situaciones operacionales en las que dos peticiones consecutivas de la dirección de IP de banco-muy-legal.de pueden devolver dos direcciones IP distintas:
* Si las respuestas se obtienen de una caché. Las cachés son volubles por naturaleza y pueden devolver resultados distintos a medida que sus contenidos expiran.
* Sin entrar cachés en juego, si las dos peticiones de DNS se envían a dos servidores DNS distintos, los dos responsables de devolver la dirección de banco-muy-legal.de, pero uno tiene una zona (así se llama en la jerga a su listado de contenidos) menos actual (p.ej. con una dirección IP vieja) y otro una una zona más actual (con una dirección IP nueva).
* Si las dos peticiones de DNS se envían incluso al mismo servidor de DNS, pero por puntazos que le dan a veces a Internet, son enrutadas a dos servidores distintos (por ejemplo, dos nodos distintos de una nube anycast) e, igual que antes, cada uno de ellos tiene zonas distintas.
* Si las dos peticiones de DNS llegan al mismo servidor, pero una es respondida antes de un cambio en la dirección IP (la dirección vieja) y la otra después de un cambio en la dirección IP (la dirección nueva).
* Si las dos peticiones de DNS llegan al mismo servidor, las direcciones IP tampoco están siendo cambiadas, pero existen varias de ellas a la vez y el servidor DNS las devuelve alternativamente para emular así una especie de "reparto de carga" entre distintos servidores web.


De estas dos preguntas se desprende que la medida descrita en el documento no proporciona una condición ni suficiente ni necesaria para detectar un problema de "seguridad". Además de complicar la arquitectura y generar tráfico innecesario, esta medida produce un número no despreciable tanto de falsos positivos como de falsos negativos, todos ellos muy complicados de analizar y diagnosticar a posteriori. Ésta es una idea muy mala para solucionar un problema que a mi parecer no tiene ninguna relevancia práctica.

Full disclosure: Soy miembro plenario del Unicode Technical Committee (UTC) en el consorcio Unicode. La posición aquí expuesta es sólo personal y no necesariamente representa la del UTC ni la de mi empresa.