Después de tres años de desarrollo y 19 versiones de prueba, se lanzó la biblioteca OpenSSL 3.0.0 con la implementación de los protocolos SSL/TLS y varios algoritmos de cifrado. Esta nueva rama incluye cambios que rompen la compatibilidad hacia atrás a nivel de API y ABI, pero dichos cambios no afectarán el funcionamiento de la mayoría de las aplicaciones, para las cuales la recompilación desde OpenSSL 1.1.1 es suficiente. El soporte para la antigua rama OpenSSL 1.1.1 se mantendrá hasta septiembre de 2023.
El cambio significativo en el número de versión se debe a la transición a la numeración tradicional «Mayor.Menor.Patch». El primer número (Mayor) en el número de versión solo cambiará en caso de que se rompa la compatibilidad a nivel de API/ABI, mientras que el segundo (Menor) cambiará con la adición de funcionalidad sin modificar la API/ABI. Las actualizaciones correctivas se proporcionarán cambiando el tercer número (Patch). El número 3.0.0 inmediatamente después de 1.1.1 fue elegido para evitar cruces con el módulo FIPS en desarrollo para OpenSSL, que utilizaba la numeración 2.x.
Un segundo cambio importante para el proyecto fue la transición de una doble licencia (OpenSSL y SSLeay) a la licencia Apache 2.0. La licencia propietaria de OpenSSL previamente utilizada se basaba en el texto de una licencia Apache 1.0 obsoleta y requería la mención explícita de OpenSSL en el material publicitario al utilizar las bibliotecas de OpenSSL, así como la adición de una nota especial en caso de incluir OpenSSL en un producto. Tales requisitos hacían que la antigua licencia fuera incompatible con la GPL, lo que generaba dificultades al utilizar OpenSSL en proyectos bajo licencia GPL. Para sortear esta incompatibilidad, los proyectos GPL se vieron obligados a utilizar acuerdos de licencia específicos, que complementaban el texto principal de la GPL con un punto que autorizaba explícitamente la vinculación de la aplicación con la biblioteca OpenSSL y mencionaba que los requisitos de la GPL no se aplican a la vinculación con OpenSSL.
En comparación con la rama OpenSSL 1.1.1, OpenSSL 3.0.0 ha agregado más de 7500 cambios, preparados por 350 desarrolladores. Las principales novedades de OpenSSL 3.0.0:
- 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 (se planea iniciar el proceso de certificación del módulo este mes, y se espera obtener el certificado FIPS 140-2 el próximo año). Este nuevo módulo es mucho más fácil de usar y su integración en muchas aplicaciones no será más complicada que modificar un archivo de configuración. Por defecto, el módulo FIPS está desactivado y requiere el uso de la opción enable-fips para ser activado.
- En libcrypto se ha implementado el concepto de proveedores plug-in, que reemplaza al concepto de motores (la API ENGINE se ha marcado como obsoleta). Con los proveedores, se pueden agregar implementaciones personalizadas de algoritmos para operaciones como cifrado, descifrado, generación de claves, cálculo de MAC, creación y verificación de firmas digitales. Es posible tanto conectar nuevos proveedores como crear implementaciones alternativas de algoritmos ya soportados (por defecto, cada algoritmo ahora utiliza el proveedor integrado en OpenSSL).
- Se ha añadido soporte para el protocolo de gestión de certificados CMP (Certificate Management Protocol, RFC 4210), que se puede usar para solicitar certificados de servidores una autoridad certificadora, actualizar certificados y revocar certificados. El trabajo con CMP se realiza mediante una nueva utilidad openssl-cmp, que también implementa soporte para el formato CRMF (RFC 4211) y la transmisión de solicitudes a través de HTTP/HTTPS (RFC 6712).
- Se ha implementado un cliente completo para los protocolos HTTP y HTTPS, que soporta los métodos GET y POST, redireccionamiento de solicitudes, trabajo a través de un proxy, codificación ASN.1 y gestión de tiempos de espera.
- Se ha añadido una nueva API EVP_MAC (Message Authentication Code API), que simplifica la adición de nuevas implementaciones de códigos de autenticación de mensajes.
- Se ha propuesto una nueva interfaz de programación para la generación de claves — EVP_KDF (Key Derivation Function API), que simplifica la adición de nuevas implementaciones de KDF y PRF. La antigua API EVP_PKEY, que proporcionaba acceso a los algoritmos scrypt, TLS1 PRF y HKDF, ha sido reestructurada en forma de una capa implementada sobre las APIs EVP_KDF y EVP_MAC.
- En la implementación del protocolo TLS se ofrece la posibilidad de utilizar la implementación TLS integrada en el núcleo de Linux para clientes y servidores, lo que acelera las operaciones. Para habilitar la implementación TLS proporcionada por el núcleo de Linux, se requiere activar la opción «SSL_OP_ENABLE_KTLS» o la configuración «enable-ktls».
- Se ha añadido soporte para nuevos algoritmos:
- Los algoritmos de derivación de claves (KDF) — «SINGLE STEP» y «SSH».
- Los algoritmos de código de autenticación de mensaje (MAC) — «GMAC» y «KMAC».
- El algoritmo de encapsulación de claves RSA (KEM) «RSASVE».
- El algoritmo de cifrado «AES-SIV» (RFC-8452).
- En el API EVP se han añadido llamadas con soporte para cifrados inversos, que utilizan el algoritmo AES para el cifrado de claves (Key Wrap): «AES-128-WRAP-INV», «AES-192-WRAP-INV», «AES-256-WRAP-INV», «AES-128-WRAP-PAD-INV», «AES-192-WRAP-PAD-INV» y «AES-256-WRAP-PAD-INV».
- En el API EVP se ha añadido soporte para algoritmos de resumen de texto cifrado (CTS): «AES-128-CBC-CTS», «AES-192-CBC-CTS», «AES-256-CBC-CTS», «CAMELLIA-128-CBC-CTS», «CAMELLIA-192-CBC-CTS» y «CAMELLIA-256-CBC-CTS».
- Se ha añadido soporte para firmas digitales CAdES-BES (RFC 5126).
- En AES_GCM se ha implementado el parámetro AuthEnvelopedData (RFC 5083), que permite cifrar y descifrar mensajes autenticados y cifrados utilizando el modo AES GCM.
- Se han extraído al API público las funciones PKCS7_get_octet_string y PKCS7_type_is_other.
- En el API PKCS#12, los algoritmos utilizados por defecto en la función PKCS12_create() han sido reemplazados por PBKDF2 y AES, y para el cálculo de MAC se ha utilizado el algoritmo SHA-256. Para restaurar el comportamiento anterior, se ha previsto la opción «-legacy». Se han añadido muchas nuevas llamadas extendidas PKCS12_*_ex, PKCS5_*_ex y PKCS8_*_ex, como PKCS12_add_key_ex(), PKCS12_create_ex() y PKCS12_decrypt_skey_ex().
- Para la plataforma Windows se ha añadido soporte para la sincronización de hilos utilizando el mecanismo SRWLock.
- Se ha añadido una nueva API para trazado, habilitada mediante el parámetro enable-trace.
- Se ha ampliado el conjunto de claves admitidas en las funciones EVP_PKEY_public_check() y EVP_PKEY_param_check(): RSA, DSA, ED25519, X25519, ED448 y X448.
- Se ha eliminado el subsistema RAND_DRBG, en su lugar se ha propuesto el API EVP_RAND. Se han eliminado las funciones FIPS_mode() y FIPS_mode_set().
- Una parte significativa de la API ha sido clasificada como obsoleta; el uso de llamadas obsoletas en el código de los proyectos generará advertencias durante la compilación. También se han declarado oficialmente obsoletas las API de bajo nivel asociadas con implementaciones específicas de algoritmos (por ejemplo, AES_set_encrypt_key y AES_encrypt). El soporte oficial en OpenSSL 3.0.0 ahora se proporciona exclusivamente para las API de alto nivel EVP, que están abstraídas de tipos de algoritmos particulares (a esta API pertenecen, por ejemplo, las funciones EVP_EncryptInit_ex, EVP_EncryptUpdate y EVP_EncryptFinal). En una de las próximas versiones importantes, las API obsoletas serán eliminadas. Las implementaciones de algoritmos obsoletos, como MD2 y DES, disponibles a través de la API EVP, se han trasladado a un módulo separado 'legacy', que está desactivado de forma predeterminada.
- La documentación y el conjunto de pruebas se han ampliado significativamente. En comparación con la rama 1.1.1, el volumen de la documentación ha aumentado en un 94% y el tamaño del código del conjunto de pruebas en un 54%.
Fuente: opennet.ru
