Me pasaban el otro día por Twitter un enlace al informe publicado por un grupo industrial patrocinado por ICANN, la organización responsable de salvaguardar los nombres de dominios en Internet, y que a su vez está formado por los representantes de varias de las grandes empresas de nuestra era.
En él hacían hincapié en que solo en EEUU se estaban perdiendo 9,800 millones de dólares anuales (EN) por “un error que hace que sus sistemas sean incompatibles con los dominios con caracteres no latinos”.
¿Cuál es ese pequeño error del que hablan?
Como bien sabe, los dominios en Internet están compuestos, como mínimo, por el nombre del dominio (el nombre que el administrador haya reservado para su uso) y su extensión (lo que aparece a la derecha del punto). De esta manera, pabloyglesias.com está formado por el nombre de dominio “pabloyglesias” y la extensión “com”, que en teoría proviene de company, pero que en la práctica se ha venido utilizando para cualquier página que no quiera estar asociada a ningún dominio territorial.
Hasta 2011, de hecho, existían muy pocas opciones de personalizar el dominio más allá de su nombre. Existían (y existen) las extensiones .com, .net, .org… es decir, extensiones genéricas (había unas 20) formadas por tres caracteres, las extensiones territoriales (248), formadas por dos carácteres (.es, .mx, .io) que en teoría (otra cosa es cómo a veces se utilizan) ayudan a saber que ese contenido está dirigido a un país o dependencias administrativas específico y algunas extraordinarias, como es el caso de .ic (Islas Canarias), .eu (Europa) o .ea (Ceuta y Melilla).
Cabe señalar, por curiosidad, que dentro de las genéricas se metieron en su momento algunas esponsorizadas como .cat (Catalunya), .mobi (para móviles) o .travel (para viajes).
¿Qué pasó a partir de 2011? Que ICANN decidió abrir la veda a la creación de extensiones de dominio de forma masiva (EN), hasta las más de 1.200 que hay en la actualidad. Y esto incluye dominios escritos en alfabetos no latinos o con caracteres latinos y signos diacríticos.
Es decir, se calcula que hay unos 2,6 millones de dominios con caracteres o símbolos no recogidos en ASCII, que es el Código Estándar Estadounidense para el Intercambio de Información. Puesto que la mayoría de formularios (y páginas webs y aplicaciones) únicamente aceptan caracteres ASCII, todos aquellos usuarios que utilicen por ejemplo un correo de uno de estos dominios no podrían crearse una cuenta en estos sistemas, ya que la validación de correo no valida como correcto el formato del email (entenderá que hay caracteres erróneos), y por ende, se está discriminando con ello a un porcentaje de la sociedad relativamente alto.
¿Tiene solución? Claro. Bastaría con que los sistemas de verificación de los formularios utilizados tanto en web como en aplicaciones aceptasen Unicode, el estándar para codificar texto que es compatible con muchísimos más caracteres. Algo que, sinceramente, no es muy complicado de hacer (para la mayoría de webs bastaría con cambiar la codificación de ASCII a Unicode, y para formularios de terceros bastaría con que el desarrollador de turno hiciera lo propio en su código).
Google ya lo permite desde 2014 en GMail. Outlook, hasta donde tengo constancia, “está trabajando en ello”. El verdadero campo de batalla, no obstante, no es solo únicamente el de las grandes empresas, sino en definitiva el de todos y cada uno de los pequeños negocios que existen en Internet: comercios electrónicos, aplicaciones, servicios de membresía… Proyectos que en la mayoría de casos desconocen este problema, y que en teoría podrían estar perdiendo con ello clientes.
Descontando la parte puramente ética del asunto. Si queremos que Internet llegue a esos 1.000 millones de personas que aún no disfrutan de sus ventajas, lo suyo es que por nuestra parte establezcamos un ecosistema lo más democrático posible para facilitarles la entrada. Y entre las medidas estaría la inclusión de caracteres no latinos que presumiblemente son los que utilizan en su lengua natal.
La otra cara de la moneda de la internacionalización de dominios con caracteres no latinos
Ahora bien, toca el turno de hablar de aquello que el estudio no hace mención por ninguna parte, y que a un servidor le preocupa sobremanera.
Como ocurre hoy en día con la proliferación de conexiones mediante HTTPs, es innegable que la adopción de Unicode como estándar de codificación de texto por defecto es algo que tarde o temprano debería llegar. Pero como ocurría con el HTTPs, algo que de facto tiene muchos puntos positivos, también tiene su lado oscuro.
Con el SSL ya hemos hablado que existen dos riesgos exponenciales:
- La marginación de la web verdaderamente independiente: al forzar que todo dominio se pase a HTTPs, estamos forzando a que todo proyecto digital pase por el aro de una muy limitada lista de entidades certificadoras. Ergo más centralización de la red, justo a lo contrario que deberíamos aspirar.
- Privacidad vs legitimidad: Hasta el momento el SSL servía tanto para definir la privacidad de las comunicaciones, como para asegurar la legitimidad de ese contenido, habida cuenta de que los controles de seguridad y verificación llevados a cabo por estas entidades certificadoras excluían de la ecuación casi cualquier intento de la industria del cibercrimen. Con la apertura actual, una campaña de phishing puede ir perfectamente firmada con un SSL, ya que el protocolo realmente lo único que confirma es que la conexión entre cliente servidor se hace de forma cifrada. Ni más, ni menos.
Con la universalización de dominios con caracteres no latinos ocurre exactamente lo mismo.
Al abrir el saco para incluir millones de nuevos dominios, también aumentamos exponencialmente las opciones que tiene un ciberatacante para aplicar mecánicas de homografía en sus campañas de phishing.
Sin ir más lejos estos días se hizo muy viral una campaña (EN) que utilizaba el enlace шһатѕарр.com para instar a las víctimas a instalar malware. Hablé de ello, de hecho, en la intranet de mecenas (ES), explicando que esa “ш” no era una uve doble, sino un carácter no latino homográfico a la “w” nuestra. Es decir, un carácter que se le parece mucho, pero que por supuesto enlaza a una página totalmente distinta.
Ya estamos sufriendo ataques de este tipo cada semana, imagínese cuando además del nombre de dominio se estandaricen las extensiones de dominio con caracteres no latinos…
Porque la ventaja de la situación actual es que según el navegador que utilicemos, шһатѕарр.com se vería como шһатѕарр.com o con algún formato del tipo “\u0448” que sin lugar a duda nos llamaría más la atención. Y que para los sistemas de verificación del navegador y/o antivirus puede resultar ya un síntoma de alerta temprana, lo que de nuevo minimizaría el impacto de la campaña al ser más rápido localizarla y marcarla como potencialmente maliciosa.
En fin, que entiendo que habrá que buscar, como siempre, un punto medio. Tarde o temprano acabaremos por aceptar caracteres no latinos como estándar de la comunicación en la Red. Solo espero que para entonces hayamos también tenido en cuenta y actualizado los procesos de verificación de seguridad asociados a este tipo de ataques.
