Un nombre que solo su propietario puede avalar

Texto preparado el 7 de octubre de 2026.

En pocas palabras

El 6 de octubre, Google informó de que unos atacantes habían tomado el control de los registros de tres dominios territoriales —Ghana (.gh), Sierra Leona (.sl) y Samoa Americana (.as)— y habían utilizado ese acceso para obtener certificados auténticos, aceptados por los navegadores, para varios dominios de Google y otros grandes servicios. No se comprometió ninguna autoridad de certificación y, según Google, las autoridades que emitieron los certificados siguieron las reglas. Eso es lo preocupante: las comprobaciones se realizaron correctamente y, aun así, el ataque tuvo éxito. La debilidad está en las propias comprobaciones. 1 2

Este artículo explica cómo es posible, por qué las contramedidas habituales solo limitan el daño y cómo lopux.net —un proyecto de Reliable Communications s.r.o., operador de red registrado en Chequia— elimina el paso que se atacó. En el modelo de lopux.net, los nombres se guardan en una cadena de bloques y los propietarios de los sitios publican sus propias claves; no hay una autoridad de certificación ni un registro de dominios como intermediarios.

Qué ocurrió

Un sitio web demuestra su identidad mediante un certificado: un documento firmado por una autoridad de certificación que indica que una clave determinada pertenece a un nombre concreto. Antes de firmarlo, la autoridad comprueba que el solicitante controla ese nombre, normalmente pidiéndole que coloque un código en los registros DNS del dominio o en el servidor al que apunta.

Los atacantes no tuvieron que engañar a la autoridad. Entraron en los registros que gestionan los tres dominios territoriales y modificaron las entradas de ciertos nombres: adónde apuntan y qué servidores responden por ellos. Desde ese momento, cualquier comprobación en internet reconocía a los atacantes como propietarios. Solo quedaba solicitar certificados; superaron las comprobaciones siguiendo las reglas. Con uno de esos certificados y el control sobre la dirección a la que se resuelve el nombre, un atacante puede suplantar el servicio auténtico mientras el navegador muestra el candado habitual.

Google bloqueó en Chrome los certificados que encontró, pidió a las autoridades emisoras que los revocaran y buscó otros en los registros públicos de Certificate Transparency. También declaró expresamente que no podía garantizar haber encontrado todos los dominios afectados y que los usuarios no debían confiar en el bloqueo del navegador como medida de protección. 1

Ya había ocurrido antes

2011, DigiNotar. Se comprometió una autoridad de certificación neerlandesa y se emitieron más de 500 certificados fraudulentos, entre ellos uno comodín para google.com. Se utilizó para interceptar el correo electrónico de unas 300.000 personas en Irán. El ataque salió a la luz porque el navegador de un usuario, Chrome, llevaba incorporadas las claves auténticas de Google. Pocas semanas después, la empresa había quebrado. 5
2017, Togo (.tg). El registro del dominio territorial de Togo estuvo una semana bajo el control de atacantes, que obtuvieron un certificado para google.tg de una autoridad de certificación gratuita muy utilizada. Chrome lo rechazó únicamente porque las claves de Google están incorporadas en el navegador: una protección que casi ningún otro sitio tiene. 3
2017–2019, «Sea Turtle». Cisco Talos documentó una campaña patrocinada por un Estado que atacó a registradores, registros y proveedores de DNS para redirigir el tráfico de organizaciones gubernamentales de aproximadamente una docena de países. Talos la describió como el primer caso conocido de un registro comprometido con fines de espionaje. 4

En los tres casos, los atacantes fueron contra un intermediario, no contra el propietario del nombre: un registro, un operador de DNS o una autoridad de certificación. Comprometer a cualquiera de ellos basta para hacerse pasar por el propietario.

Por qué las contramedidas habituales solo limitan el daño

Las recomendaciones difundidas tras conocerse el incidente son sensatas y conviene seguirlas. Pero todas reaccionan a un certificado fraudulento ya emitido o dependen de la misma capa DNS que los atacantes tomaron.

La vigilancia de los registros de Certificate Transparency revela un certificado fraudulento solo después de su emisión, y únicamente si alguien está vigilando y responde a tiempo.
Los registros CAA, que enumeran las autoridades autorizadas a emitir certificados para un dominio, se publican en DNS: precisamente la capa que controla un atacante después de comprometer el registro.
La revocación tarda en llegar a los navegadores; muchos programas que no son navegadores ni siquiera la comprueban.
La fijación de claves —key pinning— permitió descubrir DigiNotar en 2011 y protegió a Google en 2017, pero el mecanismo general se retiró de los navegadores hace años. Hoy solo protege a unas pocas empresas muy grandes cuyas claves los fabricantes de navegadores incorporan a mano.

DNSSEC y DANE merecen una mención aparte, porque sobre el papel son los que más se acercan al planteamiento de lopux.net: el propietario firma sus propios registros y puede publicar las huellas de sus claves en DNS. Sin embargo, la cadena de confianza pasa por el registro. Quien lo controla puede sustituir las claves de firma de un dominio junto con sus entradas; en este incidente, eso era exactamente lo que controlaban los atacantes. Además, ningún navegador de uso generalizado comprueba DANE.

Junto con Certificate Transparency y la fijación de claves, son parches sobre una base defectuosa: cada uno cierra una brecha, deja intacto el modelo de confianza que las produce y a menudo abre otra. DNSSEC multiplica el tamaño de las respuestas DNS; las zonas firmadas se convirtieron en reflectores habituales de ataques de amplificación. Hicieron falta parches para el parche: limitar la frecuencia de las respuestas y ofrecer respuestas mínimas a consultas ANY. En 2024, la vulnerabilidad KeyTrap demostró que una única respuesta preparada podía detener durante minutos u horas cualquiera de los principales resolutores con validación. El fallo no estaba en una implementación concreta, sino en el procedimiento de validación que prescribe el propio estándar. 6 7 8

Internet ya ha pasado por esto. Cuando IPv4 se quedó sin direcciones, se mantuvo en funcionamiento mediante NAT y un conjunto de soluciones provisionales. IPv6 pretendía ser un sustituto limpio, con seguridad incorporada. La compatibilidad con IPsec era obligatoria en todos los nodos hasta que el requisito se suavizó en 2011; IPsec de extremo a extremo nunca llegó a generalizarse. Neighbor Discovery sustituyó a ARP y heredó su vulnerabilidad a la suplantación. La solución criptográfica, SEND, apenas se desplegó, por lo que las redes dependen de RA Guard en los conmutadores, que luego se eludió mediante cabeceras de extensión y volvió a parchearse. Los túneles de transición pensados para facilitar la migración dejaban pasar tráfico por fuera de los cortafuegos IPv4. Cada nueva capa de seguridad trajo su propia capa de agujeros y parches: extensiones de privacidad para direcciones que incorporan la MAC del equipo, un RFC entero sobre qué mensajes ICMPv6 puede descartar un cortafuegos, equipos de doble pila comprometidos mediante anuncios de router falsos en redes exclusivamente IPv4, la recomendación de reducir a cero las iteraciones de NSEC3, un despliegue de DNSSEC que dejó sin servicio a parte de los usuarios de Slack durante horas… 9 10 11 12 13 14 15 16 17 18

El problema de fondo sigue siendo el mismo: la autenticidad de un nombre la avalan organizaciones que no son sus propietarias.

El enfoque de lopux.net: eliminar los intermediarios

lopux.net reúne dos servicios en una aplicación. Lopux-VPN es una VPN: conduce el tráfico del usuario a través de los servidores del proyecto por un túnel cifrado diseñado para parecer tráfico web habitual. Lopux-Internet es un espacio de nombres independiente, deliberadamente fuera del sistema de dominios de ICANN, cuyas entradas se guardan en una cadena de bloques pública, no en un registro. Actualmente cuenta con dos zonas de nivel superior: .lopux y .ipvx.

Los dos servicios pueden utilizarse por separado. Como cualquier VPN, Lopux-VPN oculta la dirección IP del usuario a los sitios que visita; además, el servicio no vincula las direcciones IP a las cuentas de usuario.

Lopux-Internet se basa en otro principio: solo el propietario de un dominio puede avalarlo, y la comprobación se realiza en el dispositivo del propio usuario.

Las entradas están en una cadena de bloques, no en una base de datos del registro. Un nombre y sus entradas se guardan en una cadena de bloques pública y solo pueden modificarse con la firma de su propietario; la cadena rechaza cualquier otra. Todos los cambios son públicos y llevan una marca de tiempo.

Sin autoridad de certificación. El propietario del sitio emite su propio certificado y publica la huella de su clave junto a las entradas del nombre. La aplicación del usuario compara esa huella con la clave que el sitio presenta realmente: si coinciden, se establece la conexión; si no, se rechaza. No existe un paso de validación del dominio en el que alguien que controle el nombre durante una hora pueda obtener un documento que lo acredite como propietario.

Varias fuentes independientes. La aplicación consulta la cadena de bloques a través de varios nodos RPC públicos a la vez, o mediante un nodo que el propio usuario haya instalado, y compara las respuestas. Si difieren, no establece la conexión.

Cambio de claves. Para sustituir la clave de un sitio, el propietario actualiza la huella publicada y, en cuestión de minutos, todos los clientes ven la nueva. No es necesario bloquear nada en los navegadores ni distribuir listas de certificados revocados. La contrapartida es que la clave de firma del propietario —la que autoriza cambios en la cadena de bloques— se convierte en lo único que no se puede perder ni filtrar. Si ocurre, no hay un registrador al que recurrir.

El ataque de 2026 dependía de dos pasos: modificar entradas en un registro y superar la comprobación de una autoridad de certificación. En el modelo de lopux.net, el primero es imposible sin la clave del propietario, y el segundo no existe.

Hoy limitado de forma deliberada, pero abierto a ampliarse

Por ahora, esta tecnología sirve únicamente a lopux.net: a los nombres de .lopux y .ipvx y a los sitios que hay detrás. La limitación es deliberada; no hay obstáculos técnicos para extenderla.

El diseño no está ligado a esos nombres. Los resolutores de cadena de bloques que sirven a Lopux-Internet podrían abrirse a todo internet, y las entradas de dominios habituales —.com, .org o territoriales— podrían guardarse de la misma manera, con las mismas huellas de claves publicadas por sus propietarios. Los propietarios de dominios existentes los conservarían con su registrador actual y simplemente optarían por alojar las entradas en la cadena de bloques a través de lopux.net.

Lo que lopux.net no prevé hacer en esta fase es registrar nombres nuevos en el espacio de dominios habitual. Allí, la asignación corresponde a ICANN y sus registros. Un nombre emitido al margen de ese sistema podría ser registrado más adelante por otra persona mediante el sistema oficial; dos propietarios para un mismo nombre es precisamente la situación que este diseño pretende evitar. Alojar las entradas de un dominio que ya tiene propietario no crea ese conflicto.

El usuario podría llegar entonces a un sitio de ese tipo de dos maneras:

Mediante el DNS habitual, con plena compatibilidad con los navegadores, sistemas operativos y redes actuales: las entradas del dominio se sirven desde la cadena de bloques a cualquiera que las solicite de la forma convencional.
Mediante la aplicación Lopux, directamente desde la cadena de bloques. Esta vía ofrece toda la protección descrita, porque la respuesta viene de la propia cadena y no pasa por una sucesión de registros, servidores DNS y autoridades de certificación.

Por qué hace falta una aplicación

Los navegadores y los sistemas operativos todavía no admiten nombres guardados en una cadena de bloques ni claves que los propietarios de los sitios publiquen allí; solo conocen el DNS habitual y las autoridades de certificación que llevan incorporadas. Hasta que esto cambie, la aplicación Lopux realiza ese trabajo en el dispositivo del usuario: lee la cadena, compara la clave del sitio con la huella del propietario y entrega al navegador una conexión ya verificada.

Por qué importa más allá de lopux.net

El ataque a los registros volvió a mostrar que ser propietario de un dominio y poder demostrarlo son cosas distintas, y que la segunda depende hoy de intermediarios. Para la mayor parte de internet eso no va a cambiar rápidamente. Pero para los servicios cuyos usuarios viven bajo presión estatal, un certificado falsificado significa correspondencia interceptada; para ellos merece la pena construir nombres cuya autenticidad solo pueda confirmar su propietario. Eso es lo que hace lopux.net, empezando por sus propios sitios.

Una última advertencia. Todo lo descrito funciona actualmente en la red de pruebas Sepolia de Ethereum, no en una red de producción, y el proyecto necesita las opiniones de quienes lo utilizan. Cualquiera puede probar el servicio gratis, y lopux.net quiere saber qué funciona, qué falla y qué no se entiende.