After three years of development and 19 test releases, OpenSSL 3.0.0 has been released, featuring implementations of the SSL/TLS protocols and various encryption algorithms. This new branch includes changes that break backward compatibility at the API and ABI levels, but these changes will not affect the operation of most applications, which can be ported from OpenSSL 1.1.1 with a simple rebuild. Support for the previous branch, OpenSSL 1.1.1, will be maintained until September 2023.
The significant version number change is related to the transition to traditional 'Major.Minor.Patch' numbering. The first digit (Major) in the version number will now only change in case of breaking compatibility at the API/ABI level, while the second digit (Minor) will change with functionality enhancements that do not alter the API/ABI. Patch updates will be delivered with changes to the third digit (Patch). The number 3.0.0 was chosen immediately after 1.1.1 to avoid overlaps with the in-development FIPS module for OpenSSL, which used the 2.x numbering.
The second significant change for the project was the transition from a dual license (OpenSSL and SSLeay) to the Apache 2.0 license. The previously used proprietary OpenSSL license was based on the outdated Apache 1.0 license text and required explicit mention of OpenSSL in promotional materials when using OpenSSL libraries, as well as the addition of a special notice when delivering OpenSSL as part of a product. Such requirements made the old license incompatible with the GPL, creating difficulties when using OpenSSL in GPL-licensed projects. To navigate this GPL incompatibility, GPL projects were forced to adopt specific licensing agreements that supplemented the main GPL text with a clause explicitly allowing linking the application with the OpenSSL library and stating that the GPL requirements do not apply to linking with OpenSSL.
Compared to the OpenSSL 1.1.1 branch, OpenSSL 3.0.0 has over 7500 changes prepared by 350 developers. Key innovations in OpenSSL 3.0.0:
- A new FIPS module has been proposed, which includes the implementation of cryptographic algorithms that comply with the FIPS 140-2 security standard (the certification process for the module is expected to start this month, with the FIPS 140-2 certificate anticipated next year). The new module is significantly easier to use, and its integration with various applications will be no more complicated than changing a configuration file. By default, the FIPS module is disabled and requires the enable-fips option to be activated.
- The concept of plug-in providers has been implemented in libcrypto, replacing the engine concept (the ENGINE API is now deprecated). With providers, you can add your own implementations of algorithms for operations such as encryption, decryption, key generation, MAC computation, and digital signature creation and verification. Both new implementations can be added, as well as alternative implementations of existing supported algorithms (by default, the built-in OpenSSL provider is used for each algorithm).
- Support for the CMP (Certificate Management Protocol, RFC 4210) has been added, which can be used to request certificates from server the certificate authority, update certificates, and revoke certificates. Interaction with CMP is done through the new openssl-cmp utility, which also supports the CRMF format (RFC 4211) and request transmission over HTTP/HTTPS (RFC 6712).
- A fully functional client for HTTP and HTTPS protocols has been implemented, supporting the GET and POST methods, request redirection, proxy operations, ASN.1 encoding, and timeout handling.
- A new API, EVP_MAC (Message Authentication Code API), has been added to simplify the addition of new implementations of message authentication codes.
- A new interface for key generation — EVP_KDF (Key Derivation Function API) — has been proposed to simplify the addition of new implementations of KDF and PRF. The old API EVP_PKEY, which provided access to the scrypt, TLS1 PRF, and HKDF algorithms, has been reworked in the form of a layer implemented on top of the EVP_KDF and EVP_MAC APIs.
- In the implementation of the TLS protocol, the ability to use the TLS implementation built into the Linux kernel for client and server has been provided to speed up operations. To enable the Linux kernel's TLS implementation, the 'SSL_OP_ENABLE_KTLS' option must be activated or the 'enable-ktls' setting must be configured.
- Support for new algorithms has been added:
- Key derivation algorithms (KDF) — "SINGLE STEP" and "SSH."
- Message authentication code algorithms (MAC) — "GMAC" and "KMAC."
- RSA key encapsulation algorithm (KEM) "RSASVE."
- Encryption algorithm "AES-SIV" (RFC-8452).
- The EVP API has added calls supporting inverse ciphers using the AES algorithm for key encryption (Key Wrap): "AES-128-WRAP-INV", "AES-192-WRAP-INV", "AES-256-WRAP-INV", "AES-128-WRAP-PAD-INV", "AES-192-WRAP-PAD-INV" and "AES-256-WRAP-PAD-INV."
- The EVP API has added support for ciphertext stealing algorithms (CTS): "AES-128-CBC-CTS", "AES-192-CBC-CTS", "AES-256-CBC-CTS", "CAMELLIA-128-CBC-CTS", "CAMELLIA-192-CBC-CTS" and "CAMELLIA-256-CBC-CTS."
- Support for CAdES-BES digital signatures (RFC 5126) has been added.
- In AES_GCM, the AuthEnvelopedData parameter (RFC 5083) has been implemented, allowing messages to be encrypted and decrypted using authenticated and encrypted mode AES GCM.
- The public API has been enhanced with functions PKCS7_get_octet_string and PKCS7_type_is_other.
- In the PKCS#12 API, the algorithms used by default in the PKCS12_create() function have been replaced with PBKDF2 and AES, and the SHA-256 algorithm is used for MAC calculation. An option "-legacy" is provided to restore previous behavior. A large number of new extended calls PKCS12_*_ex, PKCS5_*_ex, and PKCS8_*_ex, such as PKCS12_add_key_ex(), PKCS12_create_ex(), and PKCS12_decrypt_skey_ex(), have been added.
- For the Windows platform, support for thread synchronization using the SRWLock mechanism has been added.
- A new API for tracing has been added, enabled through the enable-trace parameter.
- The range of keys supported in EVP_PKEY_public_check() and EVP_PKEY_param_check() functions has been expanded: RSA, DSA, ED25519, X25519, ED448, and X448.
- The RAND_DRBG subsystem has been removed and replaced with the EVP_RAND API. The FIPS_mode() and FIPS_mode_set() functions have been eliminated.
- A significant portion of the API has been deprecated — using deprecated calls in project code will result in warnings during compilation. This includes low-level APIs that are tied to specific algorithm implementations (e.g., AES_set_encrypt_key and AES_encrypt), which have now been officially declared deprecated. Official support in OpenSSL 3.0.0 is now only provided for high-level APIs EVP, abstracted from specific types of algorithms (such as the functions EVP_EncryptInit_ex, EVP_EncryptUpdate, and EVP_EncryptFinal). In one of the upcoming major releases, deprecated APIs will be removed. Implementations of outdated algorithms, such as MD2 and DES, available through the EVP API, have been moved to a separate 'legacy' module that is disabled by default.
- Documentation and test set have been significantly expanded. Compared to the 1.1.1 branch, the documentation volume has increased by 94%, and the test suite code size by 54%.
Source: opennet.ru
