Compromiso da CA intermedia de eMudhra: listas de bloqueo do navegador e a fenda de confianza en tempo de execución

Que abrangue este vídeo

• As chaves comprometidas pertencen a asinantes intermedios. A desconfianza da raíz pode mitigar unha cadea sen probar que a clave privada da raíz foi comprometida.
• A lista de bloqueo de emerxencia dun navegador e o almacén de CA incluído nunha aplicación poden seguir rutas de actualización separadas. Comprobe o proceso en execución e a súa configuración de confianza real.
• Mozilla confirmou de forma independente claves privadas recuperables. O informe non describe entradas de CT para os intermediarios afectados; o uso indebido real contra outros clientes segue sendo descoñecido.
• As versións principais verifican certifi 2026.10.19 e Node 24.22.1 para as ramas discutidas. Os paquetes de CA personalizados e outras ramas en tempo de execución necesitan as súas propias verificacións.
• A conta de 333 relés do investigador de Tor refírese a un incidente de principios de outubro publicado o 20 de outubro. Aproximadamente un dez por cento é unha conta de relés, non unha medida de tráfico interceptado.
• Un tempo de espera de rede por si só non establece que a validación de certificados rexeitase unha cadea comprometida. Preserve a verificación e distinga os erros de transporte das fallas de autenticación.

Transcrición traducida

Traducido da narración orixinal en inglés. O audio e os subtítulos dispoñibles son controlados por YouTube.

Por que un navegador fixo pode deixar unha aplicación exposta?

0:00 A solución do navegador eMudhra soa como un sinal de todo despexado. Oito claves de sinatura comprometidas aínda deixan o software con decisións de confianza obsoletas. Neste vídeo, quen pode asinar? Por que os clientes non están de acordo? E que actualización chega realmente á túa aplicación? Unha pequena dependencia mantén a súa propia lista de confianza. Volveremos ao proceso que decide se chegou a túa solución. É mércores, vinte e un de outubro, e este é The Daily Diff.

0:22 eMudhra é unha autoridade de certificación. Asina certificados dixitais que axudan ao software a autenticar sitios web e servizos. As claves comprometidas inclúen seis usadas para conexións web e dúas para a sinatura de software. Un intermedio é un asinante delegado baixo unha raíz de confianza. O venres, un xornalista chamado Wayne enviou probas aos programas raíz. Para o martes, a páxina pública do incidente estaba a explicar a limpeza. Hoxe, os desenvolvedores descobren cantas copias de confianza a súa aplicación perfectamente normal recolleu.

Que autoriza unha clave intermedia?

0:49 Aquí está a cadea ordinaria. Un sitio presenta un certificado, un intermedio asínao, e o teu cliente segue a cadea ata unha raíz na que xa confía. A raíz é o teu punto de partida local. Quen controla a clave privada do intermedio pode asinar baixo esa autoridade. Unha sinatura matematicamente válida pode ter un asinante completamente indigno de confianza. O validador necesita un xeito de retirar a confianza despois dun compromiso. Wayne asinou a mensaxe, Temos un problema aquí, Wayne,

1:12 con cada clave. Mozilla verificou o control das claves, e despois recuperou as claves de forma independente. A resposta de emerxencia comezou cunha frase que soa a que alguén notou que a impresora da oficina estaba botando fume.

Que está probado e que segue sendo descoñecido?

1:22 O informe público di que as claves foron xeradas incorrectamente e recuperables dos certificados, creados en abril do ano pasado. O uso indebido real contra outro software aínda é descoñecido. A autoridade de sinatura recuperable é o suficientemente urxente sen unha lista de vítimas inventada. Aquí hai un límite importante. O informe non atopou entradas de transparencia de certificados para eses intermediarios durante ese período.

1:42 Di que os navegadores que aplican a transparencia non puideron ser atacados a través desta ruta. Esa verificación adicional do navegador axuda a explicar por que o titular só esaxera a imaxe. eMudhra díxolle a Mozilla que uns trinta mil certificados necesitaban migración a outra cadea. Trátase de servizos en funcionamento cuxos propietarios deben substituír os certificados durante a limpeza. Nalgún lugar, unha invitación de calendario acaba de converterse nunha dependencia de produción.

Por que o navegador e o tempo de execución non están de acordo?

2:03 Os provedores de navegadores distribúen listas de bloqueo de emerxencia. O informe rexistra a acción de Firefox e Chrome o venres, seguida por Apple e Microsoft. Estes clientes poden rexeitar o intermedio comprometido mentres recoñecen a súa raíz. Esa regra viaxa por separado do paquete da túa aplicación. Algúns clientes verifican unha cadea contra raíces de confianza sen consumir información de revocación de emerxencia. A autoridade pode publicar unha revogación, e ese cliente pode seguir aceptando a cadea.

2:27 Poñer un cartel na porta funciona mellor cando o visitante le os carteis. Mozilla di que algúns perfís de Android non aplicaron a lista de bloqueo actualizada ao inicio. Unha corrección enviouse en Firefox un cento cincuenta e oito punto cero dous. Así que mantén o navegador actualizado tamén. O anuncio non pode inventariar o teu teléfono. Os mantedores poden eliminar un áncora de confianza cando os clientes carecen dun bloqueo máis estrito. O fío de Mozilla describe a desconfianza de emerxencia da raíz ECC de emSign, xeración tres. Eliminar unha raíz dun almacén de confianza bloquea as cadeas que dependen

2:54 dela, mesmo cando a clave privada da raíz nunca foi comprometida. A última versión de certifi de Python é unha actualización posterior.

Que actualizacións chegaron a Python e Node?

3:01 O seu commit tamén restaura as raíces emSign non afectadas despois dunha eliminación anterior. Eliminar todo o que leva o nome da empresa é un pésimo substituto do paquete mantido. Queres que a cadea perigosa sexa rexeitada e que os clientes lexítimos sigan funcionando. O historial de lanzamentos conserva ambas decisións. A limpeza de seguridade ten o traballo glamouroso de ser urxente, precisa e culpada de calquera servizo que se rompa durante o xantar. A versión vinte e catro punto vinte e dous punto un de Node enviouse hoxe con raíces

3:26 actualizadas. Comprobe o aviso da súa propia rama e a configuración real da CA. Un paquete personalizado pode cambiar o almacén de confianza que usa o proceso. En Tor, un investigador publicou onte un informe de trescentos trinta e

Que capturou a advertencia de clave de host de Tor?

3:36 tres relés de saída comprometidos. A interceptación comezou a principios deste mes. Os relés foron marcados e pechados días despois, antes de que chegase o informe. SSH advertiu ao investigador de que a identidade do servidor cambiara. El reportouno ao equipo de saúde da rede de Tor. O seu aviso de operador confirma os informes de interceptación. Esa advertencia estaba a facer exactamente o inconveniente que se supón que debe facer a autenticación.

3:57 Aproximadamente un dez por cento contou relés con diferentes capacidades, deixando a cota de tráfico sen medir. O enrutamento de Tor e a identidade do servidor SSH teñen traballos separados. Verifique unha clave de host cambiada a través dun canle de confianza antes de aceptala e iniciar sesión. Volve á túa aplicación, comeza co contedor en execución ou o ambiente virtual.

Como se comproba a corrección despregada?

4:12 Busca o paquete de CA que realmente usa e aplica a actualización mantida relevante. Reconstrúe e reinicia o proceso despregado para que poida cargar o material de confianza cambiado. Usa as cadeas de proba públicas dos mantedores no ambiente real do cliente. Mantén o erro do certificado separado dun tempo de espera de rede. Unha conexión fallida na rede Wi-Fi do hotel é unha excelente proba da rede Wi-Fi do hotel. A pequena dependencia é un almacén de confianza empaquetado por separado, como certifi. O teu navegador de escritorio nunca edita esa dependencia dentro dun contedor antigo. O proceso despregado e a súa configuración deciden se chegou a corrección.

4:42 Ese é o lugar para verificar a túa actualización. Se prefires ler isto que escoitarme dicilo, o "diff" chega á túa caixa de entrada todas as mañás, de balde en "thedailydiff dot dev", ligazón a continuación.

Que recibe o selo NEEDS REVIEW?

4:51 Así que o veredicto de hoxe é NEEDS REVIEW. Quero que se verifique a confianza do cliente despregado antes de que alguén peche este incidente. Subscríbete, preme na campá e dime nos comentarios se o terías selado de forma diferente. E ese é o "diff" de hoxe. Son Niko de Axrisi. Fusionar con responsabilidade.

Fontes

1. eMudhra Intermediate CA CompromiseDennis Jackson
2. Private key compromise of eMudhra Intermediate CertificatesMozilla Bugzilla
3. certifi 2026.10.19 releasecertifi
4. Restore unaffected emSign rootscertifi
5. Node 24.22.1 security releaseNode.js
6. Update root certificates to NSS 3.131.1Node.js
7. How I got over 300 Tor exit nodes removedKABA
8. Security incident affecting some relay operatorsTor Project network health