Después de tres años de desarrollo y 19 versiones de prueba se dio a conocer hace poco el lanzamiento de la nueva versión de OpenSSL 3.0.0 la cual tiene más de 7500 cambios aportados por 350 desarrolladores y que tambien representa un cambio significativo en el número de versión y que se debe a la transición a la numeración tradicional.

De ahora en adelante, el primer dígito (Mayor) en el número de versión cambiará solo cuando se viole la compatibilidad en el nivel de API / ABI, y el segundo (Menor) cuando se aumente la funcionalidad sin cambiar la API/ABI. Las actualizaciones correctivas se enviarán con un cambio de tercer dígito (parche). Se eligió el número 3.0.0 inmediatamente después de 1.1.1 para evitar colisiones con el módulo FIPS en desarrollo para OpenSSL, que tenía el número 2.x.

El segundo cambio importante para el proyecto fue la transición de una licencia dual (OpenSSL y SSLeay) a una licencia Apache 2.0. La licencia OpenSSL nativa utilizada anteriormente se basaba en la licencia Apache 1.0 heredada y requería una mención explícita de OpenSSL en los materiales promocionales cuando se usaban las bibliotecas OpenSSL, y una nota especial si OpenSSL se envió con el producto.

Estos requisitos hicieron que la licencia anterior fuera incompatible con la GPL, lo que dificultaba el uso de OpenSSL en proyectos con licencia GPL. Para eludir esta incompatibilidad, los proyectos GPL se vieron obligados a aplicar acuerdos de licencia específicos, en los que el texto principal de la GPL se complementó con una cláusula que permitía explícitamente que la aplicación se vincule con la biblioteca OpenSSL y mencionando que la GPL no se aplica a la vinculación con OpenSSL.

Novedades de OpenSSL 3.0.0

Por la parte de las novedades que se presentan en OpenSSL 3.0.0 podremos encontrar que se ha propuesto un nuevo módulo FIPS, que incluye la implementación de algoritmos criptográficos que cumplen con el estándar de seguridad FIPS 140-2 (el proceso de certificación del módulo está planeado para comenzar este mes, y la certificación FIPS 140-2 se espera el próximo año). El nuevo módulo es mucho más fácil de usar y su conexión a muchas aplicaciones no será más difícil que cambiar el archivo de configuración. De forma predeterminada, FIPS está deshabilitado y requiere que la opción enable-fips esté habilitada.

En libcrypto se implementó el concepto de proveedores de servicios conectados que reemplazó el concepto de motores (la API ENGINE quedó obsoleta). Con la ayuda de proveedores, se puede agregar sus propias implementaciones de algoritmos para operaciones como cifrado, descifrado, generación de claves, cálculo MAC, creación y verificación de firmas digitales.

Tambien se destaca que se agregó soporte para CMP, que se puede usar para solicitar certificados del servidor de CA, renovar certificados y revocar certificados. El trabajo con CMP se realiza mediante la nueva utilidad openssl-cmp, que también implementa el soporte para el formato CRMF y la transmisión de solicitudes a través de HTTP/HTTPS.

Además se ha propuesto una nueva interfaz de programación para la generación de claves: EVP_KDF (API de función de derivación de claves), que simplifica la incorporación de nuevas implementaciones de KDF y PRF. La antigua API EVP_PKEY, a través de la cual estaban disponibles los algoritmos scrypt, TLS1 PRF y HKDF, se ha rediseñado en forma de capa intermedia implementada sobre las API EVP_KDF y EVP_MAC.

Y en la implementación del protocolo TLS ofrece la posibilidad de utilizar el cliente y el servidor TLS integrados en el kernel de Linux para acelerar las operaciones. Para habilitar la implementación de TLS proporcionada por el kernel de Linux, se debe habilitar la opción «SSL_OP_ENABLE_KTLS» o la configuración «enable-ktls».

Por otra parte se menciona que una parte importante de la API se ha movido a la categoría de obsoleta: el uso de llamadas obsoletas en el código de los proyectos generará una advertencia durante la compilación. Las API de bajo nivel vinculadas a ciertos algoritmos han sido declaradas oficialmente obsoletas.

El soporte oficial en OpenSSL 3.0.0 ahora se proporciona solo para las API de EVP de alto nivel, extraídas de ciertos tipos de algoritmos (esta API incluye, por ejemplo, las funciones EVP_EncryptInit_ex, EVP_EncryptUpdate y EVP_EncryptFinal). Las API obsoletas se eliminarán en una de las próximas versiones principales. Las implementaciones de algoritmos heredados, como MD2 y DES, disponibles a través de la API de EVP, se han movido a un módulo «heredado» separado, que está deshabilitado de manera predeterminada.

Finalmente si estás interesado en conocer más al respecto, puedes consultar los detalles en el siguiente enlace.