Una clave de certificado de eMudhra era el número 4 y permitía falsificar cualquier sitio web

La clave secreta detrás de uno de los certificados que garantizan la identidad de un sitio web resultó ser el número cuatro. No era un número aleatorio largo que empezara con cuatro: era simplemente cuatro. Otras siete claves de la misma autoridad certificadora india, eMudhra, eran casi igual de pequeñas. Cualquiera que las tuviera podía emitir un certificado para cualquier sitio web —desde un banco hasta un proveedor de correo electrónico— y los programas que confían en eMudhra lo aceptarían como legítimo.

Esos son los certificados que verifica el candado del navegador. Con uno falsificado, un atacante que se interponga entre tú e internet —en la red Wi-Fi de una cafetería, mediante un router intervenido o desde una red nacional hostil— puede hacerse pasar por el sitio real y leer o alterar lo que envías. Chrome, Firefox, Safari y las plataformas de Microsoft ya dejaron de confiar en los ocho certificados. Muchos otros programas de tus dispositivos todavía no lo han hecho.

Una clave normal de este tipo es un número aleatorio de unos 384 bits, lo que deja aproximadamente 10 elevado a la potencia de 115 posibilidades. Las claves de eMudhra tenían entre 3 y 8 bits: 4, 56, 66, 115, 155, 156, 230 y 237, según la lista de Ars Technica. El investigador de seguridad Scott Helme escribió que recuperó las ocho de los certificados públicos de su laptop, «y tardé menos de un segundo». Después agregó que Claude, de Anthropic, hizo lo mismo con una sola instrucción.

No hubo que robar nada. En su informe a Mozilla, según BleepingComputer, eMudhra atribuyó el problema a un error en el script usado durante el proceso de generación de claves: el script creó un segundo conjunto de claves débiles y el personal eligió esas por error porque sus etiquetas se parecían. La empresa, que afirma haber emitido más de 60 millones de certificados digitales, le dijo a Mozilla que la mayoría de los certificados intermedios afectados nunca llegaron a producción y que no encontró pruebas de que se hubieran usado para firmar certificados de usuarios finales. Revocó los ocho y dejó de emitir certificados bajo la raíz afectada.

Los navegadores son la parte fácil. Chrome, Firefox y Safari distribuyen listas de revocación a los usuarios de forma silenciosa y también exigen que todos los certificados aparezcan en registros públicos de Certificate Transparency. Como ningún certificado de sitio web encadenado a estas claves apareció allí, los navegadores actualizados nunca estuvieron expuestos de manera predeterminada. El problema está en todo lo demás. Las herramientas de línea de comandos como curl, los lenguajes como Python, Node y Go, los clientes de VPN, los contenedores de Docker y los dispositivos de domótica llevan sus propias listas de autoridades confiables, rara vez verifican la revocación e ignoran los registros de transparencia. Helme creó un certificado falso para la API de pagos de Stripe y descubrió que curl, Python y Node lo aceptaron en todas las máquinas con Linux y macOS que probó.

«Esto será una limpieza enorme, más grande que Heartbleed», le dijo a Ars Technica Filippo Valsorda, responsable del código criptográfico del lenguaje Go, en referencia a la falla de OpenSSL que tomó años corregir. Valsorda espera que quede «una cola muy, muy larga» de dispositivos de internet de las cosas, contenedores de Docker, máquinas Linux olvidadas y herramientas sin mantenimiento que incluyen su propia copia de las raíces confiables. Para explotar las claves, el atacante todavía debe estar en la ruta de la conexión, algo que está al alcance de gobiernos, de quien comprometa la red de una oficina o de quien administre un punto de acceso público. Signal, WhatsApp y WireGuard, que no dependen de estos certificados para su cifrado, no se vieron afectados, señala Ars.

Las claves podían recuperarse desde el día en que se crearon los certificados, en abril de 2025: una ventana de unos 17 meses. No hay forma de saber si alguien las usó contra programas que omiten la verificación de transparencia. Además, en mayo de 2025 Sectigo firmó de forma cruzada todos los certificados con su certificado raíz AAA Certificate Services, lo que amplió el conjunto de sistemas que confiaban en ellos.

Para la mayoría de las personas, la solución es instalar las actualizaciones. Un investigador informó del problema a los fabricantes de navegadores el 17 de octubre. Ese mismo día, Mozilla bloqueó los certificados en Firefox en menos de tres horas y, el 20 de octubre, lanzó Firefox 158.0.1, nuevas versiones ESR y NSS 3.131.1, que elimina la raíz de eMudhra. Apple añadió protección el 19 de octubre y Microsoft el 20, según el sitio del incidente a cargo de Dennis Jackson, ingeniero de Mozilla. Sin embargo, cuando Ars publicó su artículo, Edge en Windows 10 todavía se conectaba a los servidores de prueba. Ya están disponibles Go 1.27.3 y 1.26.10, pip 26.2.2, uv 0.13.4 y certifi 2026.10.19; Cloudflare actualizó sus aplicaciones WARP y 1.1.1.1, y las distribuciones de Linux todavía están publicando nuevos paquetes de ca-certificates. El curl integrado en macOS seguirá confiando en las claves hasta que alguien edite manualmente su archivo de certificados.

Chrome confirmó que la raíz de eMudhra se eliminará de su Chrome Root Store en la versión 43. Hasta que todos los dispositivos se pongan al día, ocho bits separan a muchos programas de uso cotidiano de una imitación convincente de cualquier sitio.

Etiquetas: ciberseguridad, Mozilla, Firefox, certificados TLS, cifrado, eMudhra