Rustls cumple diez años con la vista puesta en la 0.24 y un 1.0 estable
La biblioteca TLS escrita en Rust celebra una década con la 0.23 como línea estable, mejores cifras que OpenSSL y BoringSSL en varias pruebas, y una 0.24 que cambiará buffers, asincronía y proveedores criptográficos.
Rustls, la biblioteca TLS escrita en Rust, cumple diez años. El proyecto arrancó en mayo de 2016, alcanzó interoperabilidad amplia con sitios web y publicó la 0.1.0 ese mismo año. Una década después, la línea 0.23 se ha mantenido estable con decenas de actualizaciones que no rompen la API, y los mantenedores ya preparan la 0.24 con cambios de arquitectura y un futuro 1.0 pensado para mantenimiento a largo plazo.
El desarrollo pasó de un esfuerzo de base impulsado por contribuidores independientes como Brian Smith y Dirkjan Ochtman a un proyecto open source con financiación sostenida y mantenedores dedicados. En ese camino aparecen aportes de AWS, auditorías de terceros respaldadas por CNCF y Cure53, y el programa ISRG Prossimo. Ese dinero permitió trabajo a tiempo completo en robustez, refactorización de arquitectura y cumplimiento. También llegaron funciones como criptografía post-cuántica, certificación FIPS y Encrypted ClientHello.
Los números frente a OpenSSL y BoringSSL
En las pruebas que acompañan a la retrospectiva, rustls 0.23.37 se mide contra OpenSSL 3.6.1 y BoringSSL en x86_64. Rustls entrega 2.357 handshakes completos por segundo y núcleo, frente a 1.713 de OpenSSL y 1.302 de BoringSSL. En handshakes reanudados lidera con 7.249, mientras BoringSSL se queda en 5.687 y OpenSSL en 3.780. La recepción de datos alcanza 7.333 MB/s por núcleo, por 6.238 de OpenSSL y 6.218 de BoringSSL. Al enviar, BoringSSL va ligeramente por delante con 7.565 MB/s por núcleo, rustls registra 7.421 y OpenSSL 5.844. Son cifras que publica el propio proyecto, no de un tercero independiente.
Qué cambia en la 0.24
La próxima versión introduce almacenamiento externo mediante el nuevo trait TlsInputBuffer. En lugar de pasar todos los datos por los traits de E/S estándar, la entrada llega por ese mecanismo y la salida se añade a vectores que proporciona el usuario. Eso permite descifrado in-place y elimina copias de memoria redundantes. Para asincronía, la 0.24 usa tipos de sesión que modelan los estados del handshake de forma secuencial, de modo que el handshake puede ejecutarse en estilo bloqueante, asíncrono o basado en finalización. También llega el modo split, pedido por la comunidad en 2019: antes un único objeto de conexión gestionaba envío y recepción; ahora el tráfico posterior al handshake se separa en objetos SendTraffic y ReceiveTraffic que implementan Send y pueden operar en hilos distintos con un canal interno de baja contención. En cargas full-duplex, la aplicación puede duplicar el rendimiento. Además, los proveedores criptográficos se separan en crates como rustls-aws-lc-rs y rustls-ring, lo que elimina pánicos por unificación de características de compilación y permite configurar proveedores globales desde fuera.
El plan es estabilizar la 0.24 y después pasar a una API 1.0 estable. Para quien mantiene servicios expuestos, rustls ya es una pieza habitual en cadenas de herramientas y proxies, y la 0.24 ataca dos problemas que importan en producción: copias de memoria y contención entre hilos. La duda razonable está en cuánto tarda ese 1.0 y si la migración desde 0.23 obliga a tocar código de integración. La promesa de la 0.24 es que no haya ruptura, pero el cambio de buffers y el modo split son lo bastante profundos como para leer bien las notas antes de actualizar.
