eMudhra saldrá del negocio global de certificados SSL/TLS

Artículo original ↗ Discusión en Hacker News ↗

Una autoridad certificadora india, eMudhra, está abandonando el negocio global SSL/TLS después de que investigadores descubrieran que algunas de sus claves privadas de CA eran valores trivialmente débiles, como el número 4, lo que hacía posible que cualquiera falsificara certificados. Los comentaristas argumentan que se trata de un fallo imperdonable para una empresa cuyo producto central es la “confianza digital”, y señalan el enorme esfuerzo global de ingeniería ahora necesario para revocar y reemplazar las cadenas afectadas en navegadores, sistemas operativos y sistemas embebidos. El incidente también provoca críticas más amplias sobre la validación de CA, el modelo de confianza de la PKI web y los factores regulatorios y culturales en torno a las prácticas de seguridad en India y en otros lugares.

Incidente y salida del negocio SSL/TLS

  • eMudhra anunció que abandonará el mercado global de CA SSL/TLS, presentándolo como un cambio estratégico porque esa línea representa solo ~1% de los ingresos.
  • Muchos comentaristas lo ven como un “no me puedes echar, renuncio”: salen porque ningún navegador ni sistema operativo volvería a confiar en ellos, no como un pivote voluntario.
  • Algunos sostienen que los reguladores en India han abierto una investigación, pero otros dudan de que haya consecuencias locales serias.

Fallo técnico: “4” como clave privada

  • El problema central: varias claves privadas de CA EC eran enteros ridículamente pequeños (por ejemplo, 4, 56, 115), recuperables en milisegundos a partir de certificados públicos.
  • Los comentaristas explican que esto es astronómicamente improbable con una generación de claves adecuada; el consenso es que un script de generación/encapsulado de claves estaba gravemente roto (por ejemplo, usando solo un byte o confundiendo claves de prueba con reales).
  • La explicación de eMudhra (un fallo de script durante el encapsulado de claves en HSM, error humano al elegir el archivo equivocado) se interpreta ampliamente como evidencia de fallos profundos de proceso e ingeniería, no como un desliz aislado.

Reacción al comunicado de prensa y credibilidad

  • El comunicado es muy criticado por evasivo y defensivo: culpa a la “amplificación en redes sociales”, recalca que “la infraestructura no se vio comprometida” y enfatiza que otras líneas de negocio están “sin afectar”.
  • Muchos ven eso como minimizar un fallo sistémico en una empresa cuya marca entera es la “confianza digital”.
  • Varios comentaristas dicen que no confiarían en ninguno de los productos PKI, de identidad o OTP restantes de eMudhra después de esto; uno señala que su implementación de OTP también parece débil.

Ecosistema de CA, gobernanza y responsabilidad

  • La crítica se extiende con fuerza al ecosistema CA/navegadores:
    • Se reprocha a los programas raíz (Mozilla, Google, Apple, Microsoft) y a los procesos del CAB Forum por admitir y firmar cruzadamente una CA claramente inmadura.
    • Se cuestiona la firma cruzada de eMudhra por parte de Sectigo; algunos sostienen que los firmantes cruzados comparten responsabilidad.
    • Otros señalan que la aprobación depende en gran medida de auditorías de terceros más que de una verdadera supervisión operativa.

Revocación, mitigación y comportamiento de las plataformas

  • Se elogia a Chrome y Firefox por una revocación rápida; la reacción más lenta y algo opaca de Apple en iOS/macOS genera preocupación, y la gente prueba dispositivos contra sitios públicos de verificación y a veces ve resultados inconsistentes.
  • Muchos descubren lo fragmentado que es el manejo de la confianza: lenguajes y runtimes (Python, Node, Java, Go), almacenes del sistema operativo y aplicaciones suelen incluir sus propios paquetes de CA, obligando a muchas actualizaciones separadas.
  • Algunos argumentan que cualquier pila que no pueda dejar de confiar rápidamente en una CA es en sí negligente; otros destacan el enorme coste de ingeniería global que implican las revocaciones masivas de CA.

Alternativas y propuestas de reforma

  • Sugerencias recurrentes:
    • Restringir las CA por geografía o espacio de nombres (por ejemplo, que las CA de un país solo se usen para sus ccTLD).
    • Usar DNSSEC/DANE o mecanismos similares para vincular claves directamente en DNS, reduciendo el poder de las CA.
    • Hacer más común el pinning de certificados o restricciones más fuertes basadas en CAA/DNS.
  • Algunos abogan por un conjunto mucho más pequeño de CA sin fines de lucro o fuertemente escrutadas (por ejemplo, tipo “Let’s Encrypt”), mientras que otros señalan que incluso CA bien gestionadas han tenido problemas; no hay un reemplazo claro que gane consenso.

Temas culturales, nacionales y organizativos

  • Muchos comentarios culpan a la cultura corporativa y regulatoria india (por ejemplo, “salvar las apariencias”, “izzat”, amiguismo, bajos salarios y cumplimiento de casillas).
  • Otros replican que la negación corporativa y el fracaso regulatorio similares ocurren en todo el mundo, y que el verdadero problema son instituciones débiles, auditorías e incentivos, no solo la nacionalidad.
  • Varios señalan que el liderazgo de eMudhra parece no técnico, y citan los bajos salarios de desarrolladores como sintomáticos de una infrainversión en competencia.

Conclusiones más amplias

  • Hay una sensación generalizada de que:
    • El negocio de CA de eMudhra está efectivamente muerto, independientemente del relato.
    • Este incidente es un fallo de PKI digno del “salón de la fama” que impulsará requisitos más estrictos (por ejemplo, generación de claves HSM atestada, mejor automatización de ceremonias y monitorización más agresiva).
    • El modelo de la PKI web sigue siendo frágil: cualquier error catastrófico o compromiso de una CA confiable impone enormes costes globales, y este episodio ha reavivado los llamados a replantear o al menos endurecer significativamente ese modelo de confianza.