La llegada de OpenSSL 4.0 marca una ruptura importante con versiones anteriores de esta biblioteca de referencia para SSL/TLS y criptografía, ampliamente usada en servidores web, aplicaciones empresariales y dispositivos de red. El salto de versión mayor no es solo simbólico: arrastra cambios incompatibles, nuevas funciones centradas en privacidad y seguridad futura, y la retirada de tecnologías que llevaban años en desuso.

Para administradores de sistemas, responsables de ciberseguridad y desarrolladores, esta versión supone un punto de inflexión a la hora de actualizar infraestructuras: introduce mejoras como Encrypted Client Hello y soporte avanzado de criptografía post‑cuántica, pero también elimina soporte para protocolos antiguos, el sistema de engines y varias APIs, obligando a revisar el código y los procesos de compilación antes de dar el salto.

Novedades principales de OpenSSL 4.0

La rama 4.0 de OpenSSL se presenta como una actualización de gran calado, con un enfoque claro en reforzar la privacidad, modernizar la base de código y limpiar lastre heredado. El equipo del proyecto ha aprovechado el cambio de versión mayor para introducir modificaciones incompatibles, eliminar soporte para plataformas marginales y ajustar el comportamiento por defecto de varios componentes internos.

Entre los cambios más visibles se encuentra la incorporación de Encrypted Client Hello (ECH), la ampliación del catálogo de algoritmos para entornos post‑cuánticos, la deprecación y eliminación de funciones históricas en el tratamiento de certificados y tiempos X.509, así como la revisión de opciones de compilación, scripts y objetivos de construcción en distintos sistemas operativos.

Privacidad reforzada con Encrypted Client Hello (ECH)

Uno de los avances más comentados es la integración de Encrypted Client Hello conforme al RFC 9849. ECH permite cifrar el mensaje Client Hello de TLS, de modo que un observador pasivo en la red no pueda acceder al Server Name Indication (SNI), es decir, al nombre del servidor al que se conecta el cliente.

Este cambio es especialmente relevante, donde la protección de la privacidad y los metadatos de conexión tiene un peso creciente en el marco regulatorio y en las políticas de muchas organizaciones. La adopción de ECH contribuye a reducir la capacidad de terceros para perfilar el tráfico TLS identificando dominios concretos a los que acceden usuarios y empresas.

Con OpenSSL 4.0, los desarrolladores que implementen ECH podrán ocultar información sensible del handshake inicial, dificultando la inspección pasiva e incrementando el nivel de confidencialidad de las conexiones, tanto en servicios públicos como en entornos corporativos donde se prioriza el cumplimiento normativo y la protección de datos.

Adiós a SSLv3, SSLv2 Client Hello y al sistema de engines

La nueva versión rompe definitivamente con parte del pasado del protocolo, ya que elimina el soporte para SSLv3, un estándar que llevaba años considerado inseguro y que estaba deshabilitado por defecto en OpenSSL desde la versión 1.1.0. De este modo, cualquier aplicación que todavía dependiera de SSLv3 tendrá que migrar a TLS moderno para poder funcionar con la rama 4.0.

También desaparece el soporte para el Client Hello de SSLv2, que se mantenía por compatibilidad histórica pero estaba completamente fuera de las prácticas recomendadas de seguridad. Su retirada contribuye a reducir la superficie de ataque y simplificar el código, alineando OpenSSL con las exigencias actuales de cifrado robusto en infraestructuras.

Otro cambio estructural es la eliminación completa del engine API utilizado para integrar hardware y software criptográfico externo. A partir de OpenSSL 4.0, la opción de compilación no-engine pasa a ser la única disponible, y la macro OPENSSL_NO_ENGINE está siempre presente. Esto obliga a revisar implementaciones que explotaban engines personalizados para tareas como aceleración criptográfica o uso de módulos HSM.

En paralelo, se recortan también métodos personalizados heredados de EVP_CIPHER, EVP_MD, EVP_PKEY y EVP_PKEY_ASN1, junto con métodos de versión SSL/TLS ya obsoletos y funciones de gestión de estados de error (como ERR_get_state() y sus variantes de eliminación de estado), consolidando una API más limpia y coherente con las necesidades actuales.

Impulso a la criptografía post‑cuántica y nuevos algoritmos

De cara al futuro, OpenSSL 4.0 avanza en su estrategia de prepararse frente a amenazas derivadas de la computación cuántica. La versión introduce nuevas capacidades de criptografía híbrida y digestión, orientadas a fortalecer los intercambios de clave ante posibles ataques en un escenario post‑cuántico.

Entre las novedades se incorpora el grupo de intercambio de claves híbrido curveSM2MLKEM768, que combina elementos clásicos con esquemas post‑cuánticos, así como el algoritmo de huella ML-DSA-MU y la función cSHAKE según NIST SP 800‑185. Estos elementos amplían las posibilidades para diseñar protocolos más resistentes a futuros avances criptanalíticos.

Además, el proyecto suma soporte para el intercambio de claves FFDHE negociado en TLS 1.2, siguiendo lo establecido en el RFC 7919. Esto permite a las implementaciones que aún operan con TLS 1.2 beneficiarse de mejores parámetros de Diffie‑Hellman de grupo finito, elevando el nivel de seguridad en escenarios donde la actualización inmediata a TLS 1.3 no es viable.

Cambios de API y comportamiento que afectan a integradores

Para quienes mantienen aplicaciones que enlazan con OpenSSL, la versión 4.0 introduce modificaciones directas en la API que pueden romper compilaciones existentes. Una de las transformaciones clave es que el tipo ASN1_STRING pasa a ser opaco, lo que limita el acceso directo a su estructura interna y obliga a utilizar funciones de alto nivel.

Muchas funciones, especialmente vinculadas al procesamiento de certificados X.509, incorporan ahora calificadores const en sus firmas, ajustando la semántica de inmutabilidad y forzando ajustes en código que hacía supuestos menos estrictos. Esto puede generar advertencias o errores de compilación en proyectos que no actualicen las definiciones correspondientes.

En el ámbito del control de tiempos, se han declarado obsoletas funciones como X509_cmp_time(), X509_cmp_current_time() y X509_cmp_timeframe(). El uso recomendado pasa a ser X509_check_certificate_times(), lo que implica adaptar rutinas de validación de certificados que hasta ahora se apoyaban en las funciones antiguas.

Otro punto relevante es que libcrypto deja de realizar limpieza global de datos asignados a través de atexit(). En su lugar, OPENSSL_cleanup() se ejecuta como un destructor global o no se lanza por defecto, dependiendo de la configuración. Esto puede afectar a aplicaciones que confiaban en la limpieza automática al finalizar el proceso, obligando a gestionar de forma más explícita el ciclo de vida de los recursos.

Asimismo, se elimina BIO_f_reliable(), una funcionalidad que llevaba rota desde la rama 3.0 y que ahora desaparece sin sustituto directo. Los proyectos que aún lo utilizasen tendrán que rediseñar la lógica asociada o adoptar otras primitivas de la biblioteca para cubrir necesidades similares.

Mayor rigor en verificación de certificados y derivación de claves

OpenSSL 4.0 refuerza la verificación estricta de certificados X.509 cuando se activa X509_V_FLAG_X509_STRICT. Con esta bandera habilitada, se ejecutan comprobaciones adicionales de la extensión AKID (Authority Key Identifier), endureciendo los criterios de validación y alineando la biblioteca con prácticas de seguridad más exigentes.

En el proceso de comprobación de listas de revocación (CRL), la nueva versión añade controles adicionales para asegurar que la validación de certificados revocados sea más exhaustiva. Estos cambios impactan en entornos donde la gestión de PKI es especialmente sensible, como administraciones públicas, banca o grandes corporaciones que dependen de cadenas de confianza robustas.

También se introducen límites inferiores obligatorios en el uso de PKCS5_PBKDF2_HMAC cuando se recurre al proveedor FIPS. Este ajuste busca evitar configuraciones demasiado débiles en la derivación de claves a partir de contraseñas, lo que en la práctica obliga a usar parámetros mínimamente fuertes en entornos donde se exige conformidad con FIPS, muy habituales en sectores críticos.

Ajustes en compilación, plataformas soportadas y herramientas

En la parte de compilación y soporte de plataformas, OpenSSL 4.0 da pasos hacia una configuración más moderna y simplificada. El proyecto deshabilita por defecto el soporte para curvas elípticas obsoletas en TLS, tal y como se precisa en el RFC 8422, así como el uso de curvas elípticas explícitas. No obstante, se mantienen opciones de configuración para quienes necesiten reactivarlas por motivos de compatibilidad puntual.

Respecto a los objetivos de construcción, se eliminan las variantes darwin‑i386 y darwin‑ppc, lo que deja fuera oficialmente a sistemas muy antiguos de Apple basados en arquitecturas i386 y PowerPC/PPC64. En la práctica, esto no debería afectar a la mayoría de despliegues actuales, donde esas plataformas llevan tiempo en desuso, pero formaliza su salida del soporte principal.

En cuanto a herramientas, se retira el script histórico , que pasa a ser la forma recomendada de generar índices de hashes para certificados en directorios. Además, para instalaciones FIPS se introduce la opción -defer_tests en la utilidad openssl fipsinstall, permitiendo aplazar ciertos auto‑tests, lo que puede facilitar despliegues en entornos con restricciones de tiempo de arranque.

En sistemas Windows, la actualización añade capacidad para elegir entre enlace estático o dinámico del runtime de Visual C++. Esta flexibilidad resulta útil para desarrolladores y equipos DevOps que empaquetan aplicaciones para diferentes escenarios de distribución, ya que pueden ajustar el tipo de runtime en función de requisitos de compatibilidad o tamaño de los binarios.

Impacto para organizaciones y desarrolladores

En el contexto donde gran parte de la infraestructura de Internet y servicios críticos se apoya en OpenSSL, la versión 4.0 supone un cambio estratégico que requiere planificación. Organizaciones públicas, proveedores cloud, entidades financieras y empresas tecnológicas deberán evaluar cuidadosamente los efectos de los cambios de API y la retirada de protocolos, especialmente en sistemas heredados o aplicaciones poco mantenidas.

La incorporación de ECH y el refuerzo de la criptografía post‑cuántica pueden verse como oportunidades para elevar el nivel de protección por defecto, pero al mismo tiempo exigen pruebas exhaustivas en entornos de preproducción. En muchos casos será necesario coordinar a equipos de desarrollo, seguridad y operaciones para garantizar que la transición no rompe servicios ni introduce regresiones.

Para proyectos open source que dependen fuertemente de OpenSSL, la adaptación implicará ajustar firmas de funciones, revisar el uso de tipos ahora opacos y sustituir componentes retirados como engines o funciones de tiempo X.509. La ventaja es que, una vez actualizados, estos proyectos se beneficiarán de una base criptográfica más alineada con los estándares actuales y con menor deuda técnica.

En conjunto, OpenSSL 4.0 se posiciona como una versión de limpieza, modernización y preparación a medio y largo plazo, que obliga a invertir esfuerzo en migración pero ofrece a cambio mejoras claras en privacidad, seguridad y coherencia interna de la biblioteca, aspectos clave para seguir sosteniendo la infraestructura digital sobre cimientos criptográficos sólidos.