Cloudflare: 22.000 intentos con claves débiles de eMudhra

Las claves eran tan débiles que una era el número 4

Cloudflare registró cerca de 22.000 intentos de handshake con las claves débiles de la autoridad certificadora india eMudhra en la semana posterior al incidente, y más de la mitad de los dispositivos que pasan por sus páginas de verificación todavía aceptan la cadena comprometida. El dato importa porque no hablamos de un fallo teórico: cualquiera puede reconstruir esas claves privadas a partir de los certificados públicos en segundos.

El origen es casi absurdo. Donde eMudhra debía elegir un número de 115 dígitos para proteger la conexión, eligió el número 4. Las otras siete claves seguían la misma lógica: 56, 66, 115, 155, 156, 230 y 237. Todas por debajo de 256, según el reporte de Mozilla recogido por BleepingComputer, lo que reduce el espacio de búsqueda a probar 256 posibilidades.

Qué encontró Cloudflare dentro de su propia red

La compañía empezó a parchear sus sistemas críticos el 19 de octubre, cuando supo del problema. Los proxies que enfrentan los orígenes de los clientes, construidos sobre Pingora, se corrigieron en horas para rechazar las claves vulnerables. En paralelo lanzó un análisis asistido por IA de su código fuente y en cuatro horas tenía el mapa completo de qué sistemas confiaban en esas claves.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Después instrumentó Pingora con logging para detectar cualquier handshake firmado por las claves débiles. El despliegue terminó el 21 de octubre y una semana más tarde el resultado era este:

Unos 22.000 intentos de handshake con las claves débiles.
Dos tercios eran consultas a sitios de prueba como emudhra.we-have-a-problem.com, el endpoint que la propia Cloudflare publicó en su guía para desarrolladores.
Casi todo el tercio restante iba a orígenes que se habían emitido un certificado a sí mismos con el intermedio débil.

Todos los handshakes configurados para verificar el certificado fueron rechazados, porque Cloudflare ya había parcheado. Pero 160 casos llamaron la atención: los nombres alternativos (SAN) de esos certificados apuntaban a dominios de otras organizaciones, algunos vinculados a dispositivos IoT de consumo. Eran certificados forjados después de que las claves se filtraran, y algunos tenían validez superior a dos años, más de lo que cualquier CA pública puede emitir.

El detalle más incómodo: uno de esos certificados forjados estaba fechado el 20 de octubre a las 18:19 UTC, menos de una hora después de que se hiciera público el reporte de Mozilla. La ventana entre la divulgación y el abuso fue prácticamente nula.

Cuántos visitantes siguen sin parchear

Cloudflare no puede probar directamente si un visitante confía en las claves débiles sin romper la conexión, así que usó sus páginas de verificación. Envió dos conexiones de prueba desde una fracción de esas páginas: una a ca1.cloudflarecaptcha.com, con certificado firmado por eMudhra, y otra a ca2.cloudflarecaptcha.com, como control.

Con 50 millones de pruebas en una semana, el diagnóstico es desigual. Los navegadores modernos y actualizados están mayormente parcheados, pero los bots y los navegadores antiguos no. Los navegadores embebidos, como Android WebView, van rezagados: entre un 30% y un 40% todavía acepta la cadena comprometida. Y en las redes grandes, más de la mitad de las pruebas sigue aceptando la cadena, tanto en tráfico con señales de bot como sin ellas.

Cloudflare advierte que la muestra está sesgada por bots no confirmados. Pero su conclusión es dura: si esos bots son representativos de cómo se actualiza el software en general, el panorama es preocupante.

Por qué esto es distinto a otros incidentes de CA

Hubo CAs comprometidas antes, como DigiNotar, TÜRKTRUST o TrustWave, pero en esos casos el acceso a las claves estaba contenido: solo un conjunto limitado de atacantes podía emitir certificados fraudulentos. Aquí el modelo de amenaza es otro. Las claves privadas de los intermedios afectados se pueden recuperar casi al instante desde los propios certificados públicos, sin necesidad de vulnerar la infraestructura de la empresa.

eMudhra sostiene que su infraestructura no fue comprometida y que no hubo filtración de datos. En un comunicado del 21 de octubre atribuyó el fallo a un error en el script de generación de claves durante la ceremonia del 30 de abril de 2025, donde un paso de envoltura y desenvuelta produjo un segundo juego de claves débiles que terminó publicado en los almacenes de confianza de los navegadores. La empresa anunció además que se retira del negocio global de certificados SSL/TLS, que representa alrededor del 1% de sus ingresos, según recogió Computerworld.

El impacto operativo es concreto: según el conteo de Chrome sobre los logs públicos de Certificate Transparency, había unos 30.800 certificados vigentes encadenados a la raíz afectada al 21 de octubre, y la gran mayoría pertenecía a la comunidad académica a través de InCommon. Chrome dejó de confiar en esa raíz, lo que obliga a esos operadores a migrar a otra jerarquía.

Qué significa esto para tu startup

La lección no es sobre eMudhra, es sobre dónde vive la confianza en tu stack. La mayoría de los equipos sabe qué proveedor les vende el certificado, pero no sabe qué raíz lo respalda ni qué sistemas fuera del navegador toman decisiones de confianza.

Audita tus almacenes de confianza fuera del navegador. Como señaló Sakshi Grover, directora de investigación de IDC, en declaraciones a Computerworld, la exposición residual está en los keystores de Java, los runtimes de lenguaje, las imágenes de contenedor, las configuraciones de mutual TLS, los proxies, los balanceadores y los dispositivos embebidos. Esos no se actualizan al ritmo de Chrome o Firefox.
Revisa tus dependencias de certificados antes de la próxima renovación. Si usas clientes ACME, ten en cuenta que no reemplazan certificados fuera de su ventana de renovación salvo que soporten ACME Renewal Information o alguien intervenga a mano. Planifica la migración con calendario, no cuando expire el certificado.
No asumas que cambiar de raíz dentro del mismo proveedor resuelve el problema. La analista de Gartner Niyati Daftary recomendó tratar la raíz G1 de eMudhra como "un puente posible, no automáticamente como el destino final", y fijar una fecha límite firme para migrar a una CA independiente.
Si corres infraestructura propia, actualiza tus bundles. Los parches de Go, NSS, Node.js, Python certifi, Rust webpki-roots y los paquetes ca-certificates de Ubuntu, Debian y Alpine ya están disponibles. En Go, el filtro vive en la librería estándar y solo se aplica si recompilas tu binario con la versión nueva.

Conclusión

El caso eMudhra deja tres aprendizajes para cualquier founder técnico. Primero, la generación de claves es un punto de fallo silencioso: un error en un script puede anular toda la criptografía que construiste encima. Segundo, la divulgación y el abuso ocurren casi en simultáneo, así que la velocidad de parcheo es parte del producto, no una tarea de mantenimiento. Y tercero, la confianza en certificados es un inventario que casi nadie tiene completo.

Cloudflare apuesta por mecanismos de revocación rápida y proyectos como upki, que tratan el almacén de confianza como algo que debe actualizarse al vuelo en lugar de ser una lista estática de raíces. Para una startup, la versión práctica de esa idea es simple: saber hoy qué sistemas de tu arquitectura aceptan un certificado, y poder cambiarlos mañana sin desplegar a mano.