Índice de contenidos
Claves de la noticia
- Rustls 0.23.46 corrige cuatro problemas de seguridad, desde consumo de memoria hasta exposición de datos de sesión.
- El fallo de ECH afecta a clientes 0.23.44 y 0.23.45 que adelantan datos y encuentran un servidor que rechaza la configuración.
- La revisión debe incluir funciones activadas, almacenes de sesión y política de intercambio de claves; el número de versión no explica toda la exposición.
Rustls ha publicado este 14 de octubre la versión 0.23.46 de su biblioteca TLS para Rust. Los cuatro avisos originales describen riesgos distintos y permiten concretar qué aplicaciones deben revisar sus conexiones. El cambio importa a quienes integran la biblioteca en clientes y servicios: una actualización del paquete puede corregir el código, pero no retirar secretos que ya hayan acabado en registros.
Cuatro avisos, cuatro rutas de exposición
Las notas de la versión enlazan cuatro avisos públicos. Leerlos juntos evita convertir el anuncio en una afirmación imprecisa sobre «TLS roto»: uno trata de memoria, otro de diagnósticos de sesión, otro de selección de grupos criptográficos y el último del orden en que se envían datos tras rechazar ECH. No todos se activan con la configuración habitual ni todos dan a un atacante la misma capacidad.
La siguiente tabla cruza los requisitos publicados con la comprobación que permiten hacer. Es una síntesis documental, no una prueba de explotación ni un inventario de aplicaciones españolas afectadas.
| Problema | Condición decisiva | Qué revisar |
|---|---|---|
| Brotli | Descompresión habilitada; en servidores, autenticación de cliente | Funciones de compilación y petición de certificados |
| Secretos en Debug | Almacén de sesión propio que registra valores sensibles | Formateadores y acceso a logs |
| Predicción de claves | Estado guardado tras un ServerHello sin autenticar | Reanudación y elección del grupo en el servidor |
| Rechazo de ECH | 0.23.44/0.23.45, ECH real y datos anticipados | Escrituras antes de completar la negociación |
La conclusión operativa es concreta: estar en una versión antigua obliga a actualizar, pero no demuestra exposición a los cuatro fallos. La configuración y la integración determinan qué camino existe. Este criterio también resulta útil al revisar bibliotecas tras las correcciones de curl: la aplicación visible y la dependencia que utiliza deben examinarse por separado.
Un límite de certificados no limita toda la memoria
El aviso sobre Brotli explica una diferencia fácil de pasar por alto. Rustls limita el resultado descomprimido del certificado, pero el decodificador integrado aceptaba una ventana interna de historial elegida por la entrada. Una cabecera de cinco bytes podía solicitar una asignación de hasta 1 GiB antes de autenticar al interlocutor. Si el asignador no puede satisfacerla, el proceso puede abortar.
La función está deshabilitada por defecto. Un cliente necesita activar Brotli y conectarse al par malicioso; un servidor necesita habilitarlo y solicitar un certificado de cliente. En ninguno de esos dos escenarios hace falta que el atacante posea un certificado de confianza. Por eso la revisión correcta combina las opciones de compilación con el comportamiento del servicio, en lugar de suponer que toda instalación recibe certificados comprimidos.
El alcance declarado es una posible denegación de servicio por agotamiento de memoria. El aviso no acredita ejecución remota de código. Además, aporta una lección verificable para otras integraciones: limitar el tamaño de salida no limita necesariamente las reservas internas del algoritmo que procesa esa salida.
ECH puede fallar después de haber enviado datos
En 0.23.44 y 0.23.45, un cliente podía almacenar datos de aplicación antes de terminar la negociación y enviarlos incluso si el servidor rechazaba Encrypted Client Hello, o ECH. Esta tecnología protege información del saludo inicial. Ante un rechazo, el servidor exterior se autentica contra el nombre público de la configuración, mientras el cliente debe abortar antes de enviar datos de aplicación.
El error estaba en la secuencia: los datos almacenados se cifraban y quedaban en la cola antes de comprobar el rechazo y preparar la alerta. La aplicación recibía el error esperado, pero al enviar la alerta también podía transmitir esos datos. Recibir un error de ECH no bastaba para garantizar que nada se hubiera enviado. Esa conclusión surge del orden descrito por el aviso, sin necesidad de suponer una intrusión adicional.
Los requisitos son acumulativos: usar EchMode::Enable, escribir datos antes de completar la negociación y conectar con un servidor que rechaza esa configuración, por ejemplo porque ha caducado. GREASE ECH no está afectado. El destinatario exterior está autenticado; el problema es que recibe información destinada al servidor interior. No se trata de que cualquier observador de la red pueda descifrarla.
Actualizar no borra los logs ni decide la política criptográfica
Otro aviso señala que el formateo Debug de valores de sesión de cliente incluía el secreto maestro de TLS 1.2 o la clave precompartida de reanudación de TLS 1.3. Un almacén de sesiones personalizado podía filtrarlos al registrarlos. Los diagnósticos ordinarios de conexión y caché integrada permanecían censurados. Para una organización que haya añadido ese registro, revisar quién accede a los logs forma parte de la respuesta; recompilar no elimina los ficheros anteriores.
El cuarto camino afecta a la predicción del intercambio de claves. Un ServerHello sin autenticar podía introducir una preferencia por X25519 para un nombre de servidor. Las conexiones posteriores ofrecían una única participación clásica, aunque siguieran anunciando soporte del grupo híbrido. Si el servidor aceptaba esa participación en vez de solicitar la híbrida, la sesión perdía esa protección poscuántica. El aviso descarta compromiso de claves y evasión de autenticación.
Los servidores que piden el grupo híbrido mediante HelloRetryRequest conservan el intercambio híbrido; los clientes con reanudación desactivada no guardan ese estado. Para equipos españoles que mantengan servicios propios, el trabajo defendible consiste en actualizar la dependencia y cotejar estas cuatro condiciones con su configuración real. Los documentos consultados no permiten afirmar qué proveedores comerciales están afectados ni que se hayan producido ataques.
Imagen: Tecnología Today, imagen conceptual generada con IA.
