Compromiso de la CA intermedia de eMudhra: listas de bloqueo del navegador y la brecha de confianza en tiempo de ejecución
Ocho claves de firma intermedias de eMudhra fueron comprometidas, incluyendo seis usadas para TLS y dos para la firma de código.
Ocho claves de firma intermedias de eMudhra fueron comprometidas, incluyendo seis usadas para TLS y dos para la 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 una advertencia de identidad de host SSH haciendo su trabajo.
Leer la edición escrita (inglés) ↗
Qué cubre este vídeo
- 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 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 primarias 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 comprobaciones.
- La cuenta del investigador de Tor de 333 relés se refiere a un incidente de principios 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. Preserve 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 están controlados por YouTube.
¿Por qué un navegador fijo puede dejar una aplicación expuesta?
0:00 La solución de eMudhra para el navegador suena como un 'todo despejado'. Ocho claves de firma comprometidas aún dejan al software con decisiones de confianza obsoletas. En este vídeo, ¿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 tu solución llegó. 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 acumulado 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 controla 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 y luego recuperó las claves de forma independiente. 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 eran recuperables 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ó entradas de transparencia de certificados para esos intermedios durante ese período.
1:42 Dice que los navegadores que aplican la transparencia no pudieron haber sido atacados por esta ruta. Esa comprobació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 migración a otra cadena. Esos 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 entorno 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 comprueban 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 pudieron aplicar la lista de bloqueo actualizada al inicio. Una solución se envió en Firefox ciento cincuenta y ocho punto cero dos. Así que mantén el navegador actualizado también. El anuncio no puede inventariar tu teléfono. Los mantenedores pueden eliminar un ancla 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 ECC de emSign, 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 de emSign no afectadas después de una eliminación anterior. Eliminar todo lo que lleva el nombre de la empresa es un pésimo sustituto del 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 glamuroso trabajo de ser urgente, precisa y de ser culpada por cualquier servicio que se caiga durante el almuerzo. La versión veinticuatro punto veintidós punto uno de Node se envió hoy con raíces
3:26 actualizadas. Comprueba el aviso de tu propia rama y la configuración real de CA. Un paquete personalizado puede cambiar qué almacén de confianza usa el proceso. En Tor, un investigador publicó ayer un informe de trescientos treinta y
¿Qué detectó la advertencia de clave de host de Tor?
3:36 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. Él lo reportó al equipo de salud de la red de Tor. Su aviso al operador confirma 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 contaron 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 solució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 cambiado. 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 la solución
4:42 llegó. 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 cada mañana, gratis en the daily diff dot dev, enlace abajo.
¿Qué recibe 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 eso es todo por hoy. Soy Niko de Axrisi. Fusiona con responsabilidad.
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



