Cuando OpenSSL 3 fue lanzado por primera vez, prometía ser un punto de inflexión. Después de casi treinta años de desarrollo, esta versión estaba destinada a traer mejoras significativas y modernizar el proyecto. Sin embargo, lo que llegó fueron regresiones de rendimiento tan graves que prácticamente inutilizaron la biblioteca para cualquier despliegue de alto volumen. Para empeorar las cosas, la rama estable anterior (1.1.1) fue deprecada rápidamente, dejando a los operadores sin una alternativa viable.

Durante mucho tiempo, este problema fue un secreto a voces. Existían issues en el tracker de OpenSSL, pero solo quienes experimentaban directamente los problemas de rendimiento los encontraban. Fue necesario que los desarrolladores de HAProxy escribieran un artículo extenso sobre el estado de las bibliotecas SSL en general —y OpenSSL en particular— para que el mensaje quedara claro: si te importa el rendimiento, mantente alejado de OpenSSL 3.x.

Este año, en la conferencia inaugural de OpenSSL, varias presentaciones proporcionaron contexto sobre las regresiones de rendimiento y otros cambios en la rama 3.x:

William Bellingrath (Juniper Networks) compartió datos de rendimiento exhaustivos comparando OpenSSL desde la versión 1.1.1 hasta la 3.4, incluyendo algunos adelantos sobre la 3.5.

Tomáš Mráz, desarrollador de OpenSSL, ofreció consejos prácticos sobre cómo optimizar el rendimiento de OpenSSL 3.x.

Alex Gaynor y Paul Kehrer, mantenedores de la biblioteca cryptography de Python, compartieron su experiencia migrando su código desde 1.1.1 a la rama 3.x.

Martin Schmatz (IBM Research) presentó los resultados de las pruebas extensivas de IBM sobre OpenSSL 3.5.3, enfocándose en comprender el impacto de rendimiento de la criptografía post-cuántica.

Después de cuatro años de mejoras continuas, OpenSSL 3.5.x parece estar finalmente en una forma razonablemente aceptable. El rendimiento es ahora comparable —por fin— al de la antigua rama 1.1.1. Sin embargo, todavía existen muchas oportunidades de optimización sin explotar.

Esta mejora llega en un momento crucial: estamos en medio de una transición masiva hacia la criptografía post-cuántica. Las principales distribuciones Linux han elegido OpenSSL 3.5.x como la versión base para esta migración:

• Debian 13 Trixie (lanzado en agosto de 2025)
• Red Hat Enterprise Linux 10.1 (lanzado en noviembre de 2025)
• Ubuntu 26.04 LTS (próximo lanzamiento en abril de 2026)

La criptografía post-cuántica ya tiene un costo de rendimiento inherente por la naturaleza de sus algoritmos. No podemos permitirnos hacerla aún más lenta de lo necesario por problemas de implementación evitables.

Este episodio plantea preguntas fundamentales sobre el desarrollo de infraestructura crítica: ¿Cómo equilibramos la innovación con la estabilidad? ¿Cuándo es aceptable romper la compatibilidad de rendimiento en nombre del progreso? ¿Qué responsabilidad tienen los proyectos de código abierto con los operadores de producción?

OpenSSL es la columna vertebral de la seguridad en internet. Cada decisión de diseño tiene consecuencias que se propagan a millones de sistemas. La historia de OpenSSL 3 nos recuerda que el rendimiento no es un detalle de implementación, sino un requisito arquitectónico.

Para quienes trabajamos con infraestructura VoIP de alto volumen, estas lecciones resuenan especialmente. La latencia y el throughput no son negociables cuando manejas miles de llamadas simultáneas con cifrado TLS/SRTP.

Conclusión

Si bien es reconfortante saber que OpenSSL 3.5.x finalmente está a la altura, esta saga de cuatro años debería servir como recordatorio: en sistemas críticos, el rendimiento debe medirse, no asumirse. Y cuando se trata de criptografía a escala, cada milisegundo cuenta.