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

La clave secreta que había detrás de uno de los certificados que avalan la identidad de una web resultó ser el número cuatro. No un número aleatorio largo que empezara por cuatro, sino simplemente cuatro. Otras siete claves de la misma autoridad de certificación india, eMudhra, eran casi igual de pequeñas, y cualquiera que las tuviera podía emitir un certificado para cualquier web —desde un banco hasta un proveedor de correo electrónico— que los programas que confían en eMudhra aceptarían como auténtica.

Esos certificados son lo que comprueba el candado del navegador. Con uno falsificado, un atacante situado entre tú e internet —en la wifi de una cafetería, un router pirateado o una red nacional hostil— puede hacerse pasar por la web real y leer o alterar lo que envías. Chrome, Firefox, Safari y las plataformas de Microsoft ya han dejado de confiar en los ocho certificados. Muchos otros programas de tus dispositivos, en cambio, siguen haciéndolo.

Una clave normal de este tipo es un número aleatorio de unos 384 bits, lo que deja aproximadamente 10 elevado a 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 publicada por Ars Technica. El investigador de seguridad Scott Helme escribió que recuperó las ocho a partir de los certificados públicos de su portátil, «y tardé menos de un segundo». Más tarde añadió que Claude, de Anthropic, hizo lo mismo con una sola instrucción.

No hubo que robar nada. En la explicación que dio a Mozilla, recogida por BleepingComputer, eMudhra atribuyó el problema a un error en el script utilizado durante el proceso de generación de claves: el script creó un segundo conjunto de claves débiles y el personal las eligió por equivocación porque sus etiquetas se parecían. La empresa, que afirma haber emitido más de 60 millones de certificados digitales, dijo a Mozilla que la mayoría de los certificados intermedios afectados nunca llegaron a utilizarse en producción y que no ha encontrado pruebas de que se usaran para firmar certificados destinados a usuarios finales. Ha revocado los ocho y ha dejado de emitir certificados bajo la raíz afectada.

Los navegadores son la parte fácil. Chrome, Firefox y Safari envían listas de revocación a los usuarios sin que estos tengan que hacer nada y, además, exigen que todos los certificados aparezcan en registros públicos de Certificate Transparency. Como nunca apareció allí ningún certificado de una web encadenado a estas claves, los navegadores actualizados no estuvieron expuestos por defecto. El problema está en todo lo demás. Las herramientas de línea de comandos, como curl; lenguajes como Python, Node y Go; los clientes VPN; los contenedores Docker y los dispositivos de domótica llevan sus propias listas de autoridades de confianza, rara vez comprueban las revocaciones e ignoran los registros de transparencia. Helme creó un certificado falso para la API de pagos de Stripe y comprobó que curl, Python y Node lo aceptaban en todos los equipos Linux y macOS que probó.

«Esto va a ser una tarea de limpieza enorme, mayor que Heartbleed», dijo a Ars Technica Filippo Valsorda, responsable del código criptográfico del lenguaje Go, en referencia al fallo de OpenSSL que tardó años en corregirse por completo. Valsorda espera «una cola muy, muy larga» de dispositivos del Internet de las cosas, contenedores Docker, máquinas Linux olvidadas y herramientas sin mantenimiento que incluyen su propia copia de las raíces de confianza. Para explotar las claves, el atacante aún tiene que estar en la ruta de la red, algo al alcance de gobiernos, de quien haya comprometido la red de una oficina o de quien gestione un punto de acceso público. Signal, WhatsApp y WireGuard, que no dependen de estos certificados para su cifrado, no se ven afectados, señala Ars.

Las claves podían recuperarse desde el día en que se crearon los certificados, en abril de 2025, durante un periodo de unos 17 meses, y no hay forma de saber si alguien las utilizó contra programas que se saltan la comprobación de transparencia. Además, todos los certificados fueron firmados de forma cruzada por la raíz AAA Certificate Services de Sectigo en mayo de 2025, lo que amplió el conjunto de sistemas que confiaban en ellos.

Para la mayoría de la gente, la solución consiste en instalar las actualizaciones. Un investigador comunicó el problema a los desarrolladores de los navegadores el 17 de octubre. Mozilla bloqueó los certificados en Firefox en menos de tres horas ese mismo día y, el 20 de octubre, publicó 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 la página del incidente gestionada por Dennis Jackson, ingeniero de Mozilla, aunque Ars comprobó que Edge en Windows 10 seguía conectándose a los servidores de prueba cuando publicó la noticia. 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 ha actualizado sus aplicaciones WARP y 1.1.1.1, y las distribuciones de Linux siguen publicando nuevos paquetes ca-certificates. El curl integrado en macOS seguirá confiando en las claves hasta que se modifique manualmente su archivo de certificados.

Chrome ha confirmado que eliminará la raíz de eMudhra de su Chrome Root Store en la versión 43. Hasta que todos los dispositivos estén actualizados, ocho bits separan a buena parte del software que usamos a diario de una falsificación convincente de cualquier web.

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