Una empresa india de certificados generó ocho claves privadas; una de ellas tenía el valor 4.
El viernes pasado, a las ocho y seis de la noche, un investigador llamado Wayne informó del problema a Firefox y Chrome. A las nueve y cuarenta y ocho, el equipo de Mozilla ya había averiguado las ocho claves por su cuenta. Ni siquiera preguntaron qué método había usado la otra parte. A las diez y cincuenta y nueve, la lista de bloqueo ya se había enviado a Firefox como configuración predeterminada. En menos de tres horas.
Estas claves deberían haber sido claves privadas de la curva P-384, cuyo espacio de búsqueda normal equivale a un número decimal de 116 dígitos.
Los valores encontrados fueron 4, 56 y 115; el mayor de todos apenas llegaba a 237. Todos eran inferiores a 256. El investigador Scott Helme dijo que había extraído las ocho de certificados públicos en menos de un segundo. Extraído. Así de rápido.
Mucha gente cree que, si hay un problema con un certificado, es porque alguien lo hackeó. Esta vez no fue así. Nadie entró en el centro de datos, no se perdieron datos y todos los controles físicos y lógicos seguían intactos. Eso es lo que decía el comunicado que eMudhra emitió para la Bolsa de Bombay y la Bolsa Nacional de Valores de India. Entonces, ¿cómo se debilitó la clave? El script de generación tenía un error. En la ceremonia de generación de claves del 30 de abril del año pasado —una ceremonia que siguió al pie de la letra todos los pasos del módulo de hardware de nivel 3 FIPS 140-2—, el paso de wrap y unwrap generó además otro conjunto de claves débiles. Y, para colmo, las etiquetas eran parecidas. Más tarde, al preparar una solicitud de firma, eligieron el conjunto equivocado y enviaron el débil.
Había superado auditorías durante dos años y, a mediados de 2025, ya estaba en las listas de confianza de los navegadores. Pasaron dieciocho meses sin que nadie se diera cuenta. Las auditorías comprueban si el proceso se siguió según la documentación; no comprueban si la clave tiene suficiente aleatoriedad.
El problema también está en la forma de la cadena de confianza. Todos los certificados emitidos por una CA intermedia se aceptan en los niveles inferiores. De las ocho claves intermedias, seis se usaban para TLS y dos para firmar código. Yash Kadakia, de Security Brigade, estima que habrá que migrar unas 30.000 certificados legítimos que todavía están en uso. También dijo que, en la cadena de confianza de Internet, un error de una empresa puede arrastrar a organizaciones que nunca han tenido relación con ella.
Vale la pena comparar la rapidez con la que reaccionaron los cuatro navegadores. Chrome y Firefox bloquearon los certificados ese mismo día, el 17. Apple lo hizo el 19. Microsoft, el 20. Cloudflare recibió el aviso el 19 y publicó un informe el 20. Google bloqueó los hashes de las claves públicas, así que también quedaron bloqueados los certificados de firma cruzada que usaban las mismas claves, sin siquiera tener que reiniciar. Esa parte se resolvió de manera contundente.
Lo que de verdad quedó sin cubrir fue todo lo que está fuera de los navegadores. Servicios escritos en Go, programas de Python que usan certifi, webpki-roots de Rust, un montón de aplicaciones Android que incluyen su propio almacén de certificados, sistemas Java antiguos en centros de datos, pasarelas empresariales, cámaras, routers... Sus listas de confianza no son las mismas que las de Chrome. Los navegadores lo solucionaron en tres horas; estos componentes tienen que esperar a que se actualice su propia versión. Y la rapidez de la solución depende de cada cuánto se actualice el componente, no tanto de la gravedad del incidente. ¿Sabes cada cuánto se actualiza tu router? Nadie lo ha contabilizado y, hasta ahora, no hay una respuesta clara.
Dennis Jackson, de Mozilla, publicó una página de prueba para comprobar si tu cliente todavía confía en estos certificados. Solo toma unos segundos. Ve y pruébala.
Lo que queda es lo que de verdad merece reflexión. Todo HTTPS se basa en una lista: te doy una lista de las empresas en las que confío; no confío en las que no están en ella. Cuando ocurre un incidente, la medida más contundente que se puede tomar es tachar un nombre. Se puede tachar. La lista está en manos de los navegadores, no de la empresa que tuvo el problema.
En la cadena de bloques funciona al revés. En Bitcoin no hay una empresa que pueda firmar algo y hacer que todos lo acepten. Cada nodo verifica por sí mismo todo el historial, desde la primera transacción. Es lento. Torpe. Consume electricidad. Pero, cuando algo sale mal, no hay que esperar a que los cuatro navegadores publiquen sus listas por separado. El precio también es real: en la cadena de bloques no existe la revocación; si algo se publica por error, queda para siempre en el libro de contabilidad.
Las firmas múltiples de los puentes entre cadenas, los precios que suministran los oráculos y las pruebas de reservas de las stablecoins hacen exactamente lo mismo que una CA intermedia. El nivel superior firma y los niveles inferiores confían. Si hay un problema, la situación no será muy distinta de esta.
La diferencia está únicamente en si se puede volver a verificar todo después. En la cadena de certificados, solo puedes esperar a que se actualice la lista. En la cadena de bloques, puedes volver a verificar cada transacción.
En la práctica, hay dos cosas que hacer. Revisa los servicios que mantienes en funcionamiento de forma permanente y comprueba si alguno sigue dependiendo de un certificado antiguo. Después, echa un vistazo a la lista blanca de retiros de tu monedero y de tu exchange: ¿los firmantes de esa multifirma dependen de la misma oficina, la misma nube o el mismo número de teléfono? Si dos de esos tres elementos coinciden, la seguridad restante se reduce a una sola.
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #Cadena de certificados
El viernes pasado, a las ocho y seis de la noche, un investigador llamado Wayne informó del problema a Firefox y Chrome. A las nueve y cuarenta y ocho, el equipo de Mozilla ya había averiguado las ocho claves por su cuenta. Ni siquiera preguntaron qué método había usado la otra parte. A las diez y cincuenta y nueve, la lista de bloqueo ya se había enviado a Firefox como configuración predeterminada. En menos de tres horas.
Estas claves deberían haber sido claves privadas de la curva P-384, cuyo espacio de búsqueda normal equivale a un número decimal de 116 dígitos.
Los valores encontrados fueron 4, 56 y 115; el mayor de todos apenas llegaba a 237. Todos eran inferiores a 256. El investigador Scott Helme dijo que había extraído las ocho de certificados públicos en menos de un segundo. Extraído. Así de rápido.
Mucha gente cree que, si hay un problema con un certificado, es porque alguien lo hackeó. Esta vez no fue así. Nadie entró en el centro de datos, no se perdieron datos y todos los controles físicos y lógicos seguían intactos. Eso es lo que decía el comunicado que eMudhra emitió para la Bolsa de Bombay y la Bolsa Nacional de Valores de India. Entonces, ¿cómo se debilitó la clave? El script de generación tenía un error. En la ceremonia de generación de claves del 30 de abril del año pasado —una ceremonia que siguió al pie de la letra todos los pasos del módulo de hardware de nivel 3 FIPS 140-2—, el paso de wrap y unwrap generó además otro conjunto de claves débiles. Y, para colmo, las etiquetas eran parecidas. Más tarde, al preparar una solicitud de firma, eligieron el conjunto equivocado y enviaron el débil.
Había superado auditorías durante dos años y, a mediados de 2025, ya estaba en las listas de confianza de los navegadores. Pasaron dieciocho meses sin que nadie se diera cuenta. Las auditorías comprueban si el proceso se siguió según la documentación; no comprueban si la clave tiene suficiente aleatoriedad.
El problema también está en la forma de la cadena de confianza. Todos los certificados emitidos por una CA intermedia se aceptan en los niveles inferiores. De las ocho claves intermedias, seis se usaban para TLS y dos para firmar código. Yash Kadakia, de Security Brigade, estima que habrá que migrar unas 30.000 certificados legítimos que todavía están en uso. También dijo que, en la cadena de confianza de Internet, un error de una empresa puede arrastrar a organizaciones que nunca han tenido relación con ella.
Vale la pena comparar la rapidez con la que reaccionaron los cuatro navegadores. Chrome y Firefox bloquearon los certificados ese mismo día, el 17. Apple lo hizo el 19. Microsoft, el 20. Cloudflare recibió el aviso el 19 y publicó un informe el 20. Google bloqueó los hashes de las claves públicas, así que también quedaron bloqueados los certificados de firma cruzada que usaban las mismas claves, sin siquiera tener que reiniciar. Esa parte se resolvió de manera contundente.
Lo que de verdad quedó sin cubrir fue todo lo que está fuera de los navegadores. Servicios escritos en Go, programas de Python que usan certifi, webpki-roots de Rust, un montón de aplicaciones Android que incluyen su propio almacén de certificados, sistemas Java antiguos en centros de datos, pasarelas empresariales, cámaras, routers... Sus listas de confianza no son las mismas que las de Chrome. Los navegadores lo solucionaron en tres horas; estos componentes tienen que esperar a que se actualice su propia versión. Y la rapidez de la solución depende de cada cuánto se actualice el componente, no tanto de la gravedad del incidente. ¿Sabes cada cuánto se actualiza tu router? Nadie lo ha contabilizado y, hasta ahora, no hay una respuesta clara.
Dennis Jackson, de Mozilla, publicó una página de prueba para comprobar si tu cliente todavía confía en estos certificados. Solo toma unos segundos. Ve y pruébala.
Lo que queda es lo que de verdad merece reflexión. Todo HTTPS se basa en una lista: te doy una lista de las empresas en las que confío; no confío en las que no están en ella. Cuando ocurre un incidente, la medida más contundente que se puede tomar es tachar un nombre. Se puede tachar. La lista está en manos de los navegadores, no de la empresa que tuvo el problema.
En la cadena de bloques funciona al revés. En Bitcoin no hay una empresa que pueda firmar algo y hacer que todos lo acepten. Cada nodo verifica por sí mismo todo el historial, desde la primera transacción. Es lento. Torpe. Consume electricidad. Pero, cuando algo sale mal, no hay que esperar a que los cuatro navegadores publiquen sus listas por separado. El precio también es real: en la cadena de bloques no existe la revocación; si algo se publica por error, queda para siempre en el libro de contabilidad.
Las firmas múltiples de los puentes entre cadenas, los precios que suministran los oráculos y las pruebas de reservas de las stablecoins hacen exactamente lo mismo que una CA intermedia. El nivel superior firma y los niveles inferiores confían. Si hay un problema, la situación no será muy distinta de esta.
La diferencia está únicamente en si se puede volver a verificar todo después. En la cadena de certificados, solo puedes esperar a que se actualice la lista. En la cadena de bloques, puedes volver a verificar cada transacción.
En la práctica, hay dos cosas que hacer. Revisa los servicios que mantienes en funcionamiento de forma permanente y comprueba si alguno sigue dependiendo de un certificado antiguo. Después, echa un vistazo a la lista blanca de retiros de tu monedero y de tu exchange: ¿los firmantes de esa multifirma dependen de la misma oficina, la misma nube o el mismo número de teléfono? Si dos de esos tres elementos coinciden, la seguridad restante se reduce a una sola.
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #Cadena de certificados