Compromiso de CA intermedia de eMudhra: listas de bloqueo de navegadores y la brecha de confianza en tiempo de ejecución
Se comprometieron ocho claves de firma intermedias de eMudhra, incluidas seis utilizadas para TLS y dos para firma de código.
Se comprometieron ocho claves de firma intermedias de eMudhra, incluidas seis utilizadas para TLS y dos para firma de código. El episodio sigue a la confirmación de Mozilla, el bloqueo del navegador y las actualizaciones posteriores para explicar por qué una aplicación implementada necesita que se verifique su propia configuración de confianza. Un informe separado de Tor muestra que una advertencia de identidad de host SSH está haciendo su trabajo.
Leer la edición escrita (inglés) ↗
Lo que cubre este video
- Las claves comprometidas pertenecen a firmantes intermedios. La desconfianza de la raíz puede mitigar una cadena sin probar que la clave privada de la raíz fue comprometida.
- La lista de bloqueo de emergencia de un navegador y el almacén de CA incluido en una aplicación pueden seguir rutas de actualización separadas. Verifique el proceso en ejecución y su configuración de confianza real.
- Mozilla confirmó de forma independiente las claves privadas recuperables. El informe no describe entradas CT para los intermedios afectados; el uso indebido real contra otros clientes sigue siendo desconocido.
- Las versiones principales verifican certifi 2026.10.19 y Node 24.22.1 para las ramas discutidas. Los paquetes de CA personalizados y otras ramas en tiempo de ejecución necesitan sus propias verificaciones.
- La cuenta de 333 relés del investigador de Tor se refiere a un incidente anterior de octubre publicado el 20 de octubre. Aproximadamente el diez por ciento es un recuento de relés, no una medida de tráfico interceptado.
- Un tiempo de espera de red por sí solo no establece que la validación del certificado rechazara una cadena comprometida. Conserve la verificación y distinga los errores de transporte de los fallos de autenticación.
Transcripción traducida
Traducido de la narración original en inglés. El audio y los subtítulos disponibles son controlados por YouTube.
¿Por qué un navegador corregido puede dejar una aplicación expuesta?
0:00 La solución del navegador eMudhra suena como una autorización general. Ocho claves de firma comprometidas aún dejan al software con decisiones de confianza obsoletas. En este video, ¿quién puede firmar? ¿Por qué los clientes no están de acuerdo? ¿Y qué actualización llega realmente a tu aplicación? Una pequeña dependencia mantiene su propia lista de confianza. Volveremos al proceso que decide si llegó tu solución. Es miércoles, veintiuno de octubre, y este es The Daily Diff.
0:22 eMudhra es una autoridad de certificación. Firma certificados digitales que ayudan al software a autenticar sitios web y servicios. Las claves comprometidas incluyen seis utilizadas para conexiones web y dos para firma de software. Un intermedio es un firmante delegado bajo una raíz de confianza. El viernes, un reportero llamado Wayne envió pruebas a los programas raíz. Para el martes, la página pública del incidente explicaba la limpieza. Hoy, los desarrolladores descubren cuántas copias de confianza ha recopilado su aplicación perfectamente normal.
¿Qué autoriza una clave intermedia?
0:49 Aquí está la cadena ordinaria. Un sitio presenta un certificado, un intermedio lo firma, y tu cliente sigue la cadena hasta una raíz en la que ya confía. La raíz es tu punto de partida local. Quien controle la clave privada del intermedio puede firmar bajo esa autoridad. Una firma matemáticamente válida puede tener un firmante completamente indigno de confianza. El validador necesita una forma de retirar la confianza después de un compromiso. Wayne firmó el mensaje, Tenemos un problema aquí, Wayne,
1:12 con cada clave. Mozilla verificó el control de la clave, luego recuperó de forma independiente las claves. La respuesta de emergencia comenzó con una frase que suena como si alguien hubiera notado que la impresora de la oficina estaba echando humo.
¿Qué se ha probado y qué sigue siendo desconocido?
1:22 El informe público dice que las claves se generaron incorrectamente y se pudieron recuperar de los certificados, creados en abril del año pasado. El uso indebido real contra otro software aún se desconoce. La autoridad de firma recuperable es lo suficientemente urgente sin una lista de víctimas inventada. Hay un límite importante aquí. El informe no encontró ninguna entrada de transparencia de certificados para esos intermedios durante ese período.
1:42 Dice que los navegadores que aplican la transparencia no podrían haber sido atacados a través de esta ruta. Esa verificación adicional del navegador ayuda a explicar por qué el titular por sí solo exagera la situación. eMudhra le dijo a Mozilla que unos treinta mil certificados necesitaban migrar a otra cadena. Son servicios en funcionamiento cuyos propietarios deben reemplazar los certificados durante la limpieza. En algún lugar, una invitación de calendario acaba de convertirse en una dependencia de producción.
¿Por qué el navegador y el tiempo de ejecución no están de acuerdo?
2:03 Los proveedores de navegadores distribuyen listas de bloqueo de emergencia. El informe registra la acción de Firefox y Chrome el viernes, seguida por Apple y Microsoft. Estos clientes pueden rechazar el intermedio comprometido mientras reconocen su raíz. Esa regla viaja por separado del paquete de tu aplicación. Algunos clientes verifican una cadena contra raíces de confianza sin consumir información de revocación de emergencia. La autoridad puede publicar una revocación, y ese cliente puede seguir aceptando la cadena.
2:27 Poner un cartel en la puerta funciona mejor cuando el visitante lee los carteles. Mozilla dice que algunos perfiles de Android no aplicaron la lista de bloqueo actualizada al inicio. Una solución se envió en Firefox 158.02. Así que mantén el navegador actualizado también. El anuncio no puede inventariar tu teléfono. Los mantenedores pueden eliminar un anclaje de confianza cuando los clientes carecen de un bloqueo más estricto. El hilo de Mozilla describe la desconfianza de emergencia de la raíz emSign ECC, generación tres. Eliminar una raíz de un almacén de confianza bloquea las cadenas que dependen de
2:54 ella, incluso cuando la clave privada de la raíz nunca fue comprometida. La última versión de certifi de Python es una actualización posterior.
¿Qué actualizaciones llegaron a Python y Node?
3:01 Su commit también restaura las raíces emSign no afectadas después de una eliminación anterior. Eliminar todo lo que lleva el nombre de la empresa es un sustituto deficiente para el paquete mantenido. Quieres que la cadena peligrosa sea rechazada y que los clientes legítimos sigan funcionando. El historial de versiones conserva ambas decisiones. La limpieza de seguridad tiene el trabajo glamoroso de ser urgente, precisa y de ser culpada por cualquier servicio que se caiga durante el almuerzo. La versión 24.22.1 de Node se lanzó hoy con raíces actualizadas.
3:26 Verifica el aviso de tu propia rama y la configuración de CA real. Un paquete personalizado puede cambiar qué almacén de confianza usa el proceso. En Tor, un investigador publicó ayer un informe de trescientas treinta
¿Qué detectó la advertencia de clave de host de Tor?
3:36 y tres relés de salida comprometidos. La interceptación comenzó a principios de este mes. Los relés fueron marcados y cerrados días después, antes de que llegara el informe. SSH advirtió al investigador que la identidad del servidor había cambiado. Lo informó al equipo de salud de la red de Tor. Su aviso del operador confirma los informes de interceptación. Esa advertencia estaba haciendo exactamente lo inconveniente que se supone que debe hacer la autenticación.
3:57 Aproximadamente el diez por ciento contó relés con diferentes capacidades, dejando la cuota de tráfico sin medir. El enrutamiento de Tor y la identidad del servidor SSH tienen trabajos separados. Verifica una clave de host cambiada a través de un canal de confianza antes de aceptarla e iniciar sesión. De vuelta en tu aplicación, comienza con el contenedor en ejecución o el entorno virtual.
¿Cómo se comprueba la corrección implementada?
4:12 Encuentra el paquete de CA que realmente usa y aplica la actualización mantenida relevante. Reconstruye y reinicia el proceso implementado para que pueda cargar el material de confianza modificado. Utiliza las cadenas de prueba públicas de los mantenedores en el entorno real del cliente. Mantén el error de certificado separado de un tiempo de espera de red. Una conexión fallida en el Wi-Fi del hotel es una excelente prueba del Wi-Fi del hotel. La pequeña dependencia es un almacén de confianza empaquetado por separado, como certifi. Tu navegador de escritorio nunca edita esa dependencia dentro de un contenedor antiguo. El proceso implementado y su configuración deciden si llegó la solución.
4:42 Ese es el lugar para verificar tu actualización. Si prefieres leer esto en lugar de oírme decirlo, el diff llega a tu bandeja de entrada todas las mañanas, gratis en the daily diff dot dev, enlace a continuación.
¿Qué obtiene el sello de NEEDS REVIEW?
4:51 Así que el veredicto de hoy es NEEDS REVIEW. Quiero que se verifique la confianza del cliente implementado antes de que alguien cierre este incidente. Suscríbete, dale a la campana y dime en los comentarios si lo habrías sellado de manera diferente. Y esa es la diferencia de hoy. Soy Niko de Axrisi. Fusiona responsablemente.
Fuentes
- eMudhra Intermediate CA CompromiseDennis Jackson
- Private key compromise of eMudhra Intermediate CertificatesMozilla Bugzilla
- certifi 2026.10.19 releasecertifi
- Restore unaffected emSign rootscertifi
- Node 24.22.1 security releaseNode.js
- Update root certificates to NSS 3.131.1Node.js
- How I got over 300 Tor exit nodes removedKABA
- Security incident affecting some relay operatorsTor Project network health



