After three years of development and 19 test releases, the OpenSSL 3.0.0 library was released with the implementation of the SSL/TLS protocols and various encryption algorithms. The new branch includes changes that break backwards compatibility at the API and ABI level, but the changes will not affect the operation of most applications that require a rebuild to migrate from OpenSSL 1.1.1. The previous branch of OpenSSL 1.1.1 will be supported until September 2023.
A significant change in the version number is due to the transition to the traditional “Major.Minor.Patch” numbering. From now on, the first digit (Major) in the version number will change only if compatibility is broken at the API/ABI level, and the second (Minor) will change when functionality is increased without changing the API/ABI. Corrective updates will be delivered with a change to the third digit (Patch). The number 3.0.0 immediately after 1.1.1 was chosen to avoid overlaps with the currently under development FIPS module for OpenSSL, for which the 2.x numbering was used.
The second important change for the project was the transition from a dual license (OpenSSL and SSLeay) to the Apache 2.0 license. The previous proprietary OpenSSL license was based on the text of the legacy Apache 1.0 license and required explicit mention of OpenSSL in marketing materials when using OpenSSL libraries, as well as a special notice if OpenSSL was provided as part of the product. These requirements made the old license incompatible with the GPL, making it difficult to use OpenSSL in GPL-licensed projects. To get around this incompatibility, GPL projects were forced to use specific license agreements in which the main text of the GPL was supplemented with a clause that explicitly allowed the application to be linked with the OpenSSL library and mentioned that the requirements of the GPL did not apply to linking with OpenSSL.
Compared to the OpenSSL 1.1.1 branch, OpenSSL 3.0.0 added more than 7500 changes contributed by 350 developers. Main innovations of OpenSSL 3.0.0:
- A new FIPS module has been proposed, including the implementation of cryptographic algorithms that comply with the FIPS 140-2 security standard (the certification process for the module is scheduled to begin this month, and FIPS 140-2 certification is expected next year). The new module is much easier to use and connecting it to many applications will be no more difficult than changing the configuration file. By default, the FIPS module is disabled and requires the enable-fips option to be enabled.
- libcrypto implements the concept of pluggable providers, which replaced the concept of engines (the ENGINE API has been deprecated). With the help of providers, you can add your own implementations of algorithms for such operations as encryption, decryption, key generation, MAC calculation, creation and verification of digital signatures. It is possible to both connect new ones and create alternative implementations of already supported algorithms (by default, the provider built into OpenSSL is now used for each algorithm).
- Added support for the Certificate Management Protocol (RFC 4210), which can be used to request certificates from a CA server, update certificates, and revoke certificates. Working with CMP is carried out using the new openssl-cmp utility, which also supports the CRMF format (RFC 4211) and sending requests via HTTP/HTTPS (RFC 6712).
- A full-fledged client for the HTTP and HTTPS protocols has been implemented, supporting the GET and POST methods, request redirection, working through a proxy, ASN.1 encoding and timeout processing.
- A new EVP_MAC (Message Authentication Code API) has been added to make it easier to add new implementations of mock inserts.
- A new software interface for generating keys is proposed - EVP_KDF (Key Derivation Function API), which simplifies the addition of new implementations of KDF and PRF. The old EVP_PKEY API, through which the scrypt, TLS1 PRF and HKDF algorithms were available, has been redesigned in the form of a layer implemented on top of the EVP_KDF and EVP_MAC APIs.
- The implementation of the TLS protocol provides the ability to use the TLS client and server built into the Linux kernel to speed up operations. To enable the TLS implementation provided by the Linux kernel, you must enable the "SSL_OP_ENABLE_KTLS" option or the "enable-ktls" setting.
- Added support for new algorithms:
- Key generation algorithms (KDF) are “SINGLE STEP” and “SSH”.
- Simulated insertion algorithms (MAC) are “GMAC” and “KMAC”.
- RSA Key Encapsulation Algorithm (KEM) "RSASVE".
- Encryption algorithm "AES-SIV" (RFC-8452).
- Added calls to the EVP API with support for inverse ciphers using the AES algorithm to encrypt keys (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".
- Added support for ciphertext borrowing (CTS) algorithms to the EVP API: “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".
- Added support for CAdES-BES digital signatures (RFC 5126).
- AES_GCM implements the AuthEnvelopedData (RFC 5083) parameter to enable encryption and decryption of messages authenticated and encrypted using the AES GCM mode.
- The PKCS7_get_octet_string and PKCS7_type_is_other functions have been added to the public API.
- The PKCS#12 API replaces the default algorithms used in the PKCS12_create() function with PBKDF2 and AES, and uses the SHA-256 algorithm to calculate MAC. To restore past behavior, the "-legacy" option is provided. Added a large number of new extended calls to PKCS12_*_ex, PKCS5_*_ex and PKCS8_*_ex, such as PKCS12_add_key_ex().PKCS12_create_ex() and PKCS12_decrypt_skey_ex().
- For the Windows platform, support for thread synchronization using the SRWLock mechanism has been added.
- Added a new tracing API, enabled via the enable-trace parameter.
- The range of keys supported in the 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, replaced by the EVP_RAND API. The FIPS_mode() and FIPS_mode_set() functions have been removed.
- A significant part of the API has been rendered obsolete - using obsolete calls in project code will result in warnings during compilation. Including low-level APIs tied to certain implementations of algorithms (for example, AES_set_encrypt_key and AES_encrypt) have been officially declared obsolete. Official support in OpenSSL 3.0.0 is now only provided for high-level EVP APIs that are abstracted from individual algorithm types (this API includes, for example, the EVP_EncryptInit_ex, EVP_EncryptUpdate, and EVP_EncryptFinal functions). Deprecated APIs will be removed in one of the next major releases. Implementations of legacy algorithms such as MD2 and DES, available through the EVP API, have been moved to a separate "legacy" module, which is disabled by default.
- The documentation and test suite have been significantly expanded. Compared to branch 1.1.1, the volume of documentation has increased by 94%, and the size of the test suite code has increased by 54%.
Source: opennet.ru