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

Published: 2026-10-21

Comprometéronse oito claves de sinatura intermedias de eMudhra, incluíndo seis usadas para TLS e dúas para a sinatura de código. O episodio segue á confirmación de Mozilla, o bloqueo do navegador e as actualizacións posteriores para explicar por que unha aplicación despregada necesita que se revise a súa propia configuración de confianza. Un informe separado de Tor mostra que unha advertencia de identidade de host SSH está a facer o seu traballo.

Canonical: https://thedailydiff.dev/gl/video/2026-10-21-emudhra-trust-gap/

## 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.

## Capítulos

- 0:00 Por que un navegador fixo pode deixar unha aplicación exposta?
- 0:49 Que autoriza unha clave intermedia?
- 1:22 Que está probado e que segue sendo descoñecido?
- 2:03 Por que o navegador e o tempo de execución non están de acordo?
- 2:58 Que actualizacións chegaron a Python e Node?
- 3:33 Que capturou a advertencia de clave de host de Tor?
- 4:10 Como se comproba a corrección despregada?
- 4:51 Que recibe o selo NEEDS REVIEW?

## 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

- [eMudhra Intermediate CA Compromise](https://emudhra.we-have-a-problem.com/) — Dennis Jackson
- [Private key compromise of eMudhra Intermediate Certificates](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) — Mozilla Bugzilla
- [certifi 2026.10.19 release](https://github.com/certifi/python-certifi/releases/tag/2026.10.19) — certifi
- [Restore unaffected emSign roots](https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914) — certifi
- [Node 24.22.1 security release](https://github.com/nodejs/node/releases/tag/v24.22.1) — Node.js
- [Update root certificates to NSS 3.131.1](https://github.com/nodejs/node/pull/66877) — Node.js
- [How I got over 300 Tor exit nodes removed](https://kaba.cx/posts/20261020_Tor/) — KABA
- [Security incident affecting some relay operators](https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/thread/WOHPLKCSHYXFTBRZXDENDKJZMBMPLMG5/) — Tor Project network health