Rustls 0.23.45 corrige un fallo de TLS 1.3 que llevaba dos años en el código
La librería aceptaba mensajes de handshake enviados en el nivel de cifrado equivocado desde la versión 0.23.13. OpenSSL y BoringSSL no están afectados.
Rustls ha sacado la versión 0.23.45 para tapar un agujero que llevaba abierto desde septiembre de 2024, cuando se publicó la 0.23.13. El fallo está en cómo la librería maneja los mensajes de handshake de TLS 1.3: aceptaba mensajes que llegaban en un nivel de cifrado que no les correspondía, siempre que vinieran detrás de un mensaje de cambio de clave en el mismo registro.
El aviso ya es público. Un atacante colocado en la ruta de la conexión podía inyectar mensajes en texto plano que Rustls daba por buenos. La raíz del asunto es que la implementación se salía de lo que dicta el RFC 8446, la especificación de TLS 1.3.
Qué se puede y qué no se puede hacer con esto
Conviene no exagerar el alcance. El transcript del handshake sigue autenticado, así que quien esté en medio de la red no puede alterar un handshake ni completarlo por su cuenta. El efecto práctico, según el propio anuncio, es más limitado: un peer podía mandar mensajes que deberían viajar cifrados en claro sin que Rustls cortara la conexión.
Eso lo aleja de un escenario de intercepción clásico y lo acerca a un incumplimiento de especificación con consecuencias acotadas. Aun así, es el tipo de cosa que se parchea sin pensarlo, sobre todo si en tu despliegue hay peers en los que no confías del todo.
OpenSSL, BoringSSL y el resto de implementaciones no arrastran este problema. Es un fallo propio de Rustls, y no el primero de esta clase: el mismo patrón apareció en una vulnerabilidad de Go en enero, apuntando a un tipo de descuido que se repite cuando alguien reimplementa un protocolo con criptografía de por medio. Que el lenguaje de turno sea memory safe no libra al código de interpretar mal una RFC.
El arreglo entró en el repositorio ayer y ya está disponible en la 0.23.45. El aviso de seguridad se puede consultar en el advisory de GitHub y los binarios y el código, en las notas de la versión.
Si tienes Rustls expuesto en un servidor o en un cliente que habla con terceros, actualiza. El salto desde cualquier 0.23.x es de mantenimiento y no rompe la API. La duda que queda es cuánto tiempo más habría seguido ahí de no haber salido a la luz: estuvo dos años en el código sin que nadie lo detectara, y eso dice bastante sobre cuánta gente revisa los detalles de conformidad de TLS 1.3 más allá de que la conexión cifre y funcione.
