Après trois années de développement et 19 versions de test, la bibliothèque OpenSSL 3.0.0 est sortie avec l'implémentation des protocoles SSL/TLS et de divers algorithmes de chiffrement. La nouvelle branche inclut des modifications qui rompent la compatibilité ascendante au niveau de l'API et de l'ABI, mais les modifications n'affecteront pas le fonctionnement de la plupart des applications qui nécessitent une reconstruction pour migrer depuis OpenSSL 1.1.1. La branche précédente d'OpenSSL 1.1.1 sera prise en charge jusqu'en septembre 2023.
Un changement important dans le numéro de version est dû au passage à la numérotation traditionnelle « Major.Minor.Patch ». Désormais, le premier chiffre (Majeur) du numéro de version ne changera que si la compatibilité est rompue au niveau API/ABI, et le second (Mineur) changera lorsque la fonctionnalité sera augmentée sans changer l'API/ABI. Des mises à jour correctives seront fournies avec une modification du troisième chiffre (Patch). Le numéro 3.0.0 immédiatement après 1.1.1 a été choisi pour éviter les chevauchements avec le module FIPS en cours de développement pour OpenSSL, pour lequel la numérotation 2.x a été utilisée.
Le deuxième changement important pour le projet a été le passage d'une double licence (OpenSSL et SSLeay) à la licence Apache 2.0. La précédente licence propriétaire OpenSSL était basée sur le texte de l'ancienne licence Apache 1.0 et nécessitait une mention explicite d'OpenSSL dans les supports marketing lors de l'utilisation des bibliothèques OpenSSL, ainsi qu'une notification spéciale si OpenSSL était fourni dans le cadre du produit. Ces exigences rendaient l'ancienne licence incompatible avec la GPL, rendant difficile l'utilisation d'OpenSSL dans des projets sous licence GPL. Pour contourner cette incompatibilité, les projets GPL ont été contraints d'utiliser des accords de licence spécifiques dans lesquels le texte principal de la GPL était complété par une clause qui permettait explicitement à l'application d'être liée à la bibliothèque OpenSSL et mentionnait que les exigences de la GPL ne répondaient pas aux exigences de la GPL. s'appliquent à la liaison avec OpenSSL.
Par rapport à la branche OpenSSL 1.1.1, OpenSSL 3.0.0 a ajouté plus de 7500 350 modifications apportées par 3.0.0 développeurs. Principales innovations d'OpenSSL XNUMX :
- Un nouveau module FIPS a été proposé, incluant la mise en œuvre d'algorithmes cryptographiques conformes à la norme de sécurité FIPS 140-2 (le processus de certification du module devrait commencer ce mois-ci et la certification FIPS 140-2 est attendue l'année prochaine). Le nouveau module est beaucoup plus simple à utiliser et le connecter à de nombreuses applications ne sera pas plus difficile que de modifier le fichier de configuration. Par défaut, le module FIPS est désactivé et nécessite l'activation de l'option activate-fips.
- libcrypto implémente le concept de fournisseurs enfichables, qui a remplacé le concept de moteurs (l'API ENGINE est obsolète). Avec l'aide de fournisseurs, vous pouvez ajouter vos propres implémentations d'algorithmes pour des opérations telles que le cryptage, le déchiffrement, la génération de clés, le calcul MAC, la création et la vérification de signatures numériques. Il est possible à la fois d'en connecter de nouveaux et de créer des implémentations alternatives d'algorithmes déjà pris en charge (par défaut, le fournisseur intégré à OpenSSL est désormais utilisé pour chaque algorithme).
- Ajout de la prise en charge du protocole de gestion des certificats (RFC 4210), qui peut être utilisé pour demander des certificats à un serveur d'autorité de certification, mettre à jour des certificats et révoquer des certificats. Le travail avec CMP s'effectue à l'aide du nouvel utilitaire openssl-cmp, qui prend également en charge le format CRMF (RFC 4211) et l'envoi de requêtes via HTTP/HTTPS (RFC 6712).
- Un client à part entière pour les protocoles HTTP et HTTPS a été implémenté, prenant en charge les méthodes GET et POST, la redirection des requêtes, fonctionnant via un proxy, le codage ASN.1 et le traitement des délais d'attente.
- Un nouvel EVP_MAC (Message Authentication Code API) a été ajouté pour faciliter l'ajout de nouvelles implémentations d'insertions fictives.
- Une nouvelle interface logicielle pour générer des clés est proposée - EVP_KDF (Key Derivation Function API), qui simplifie l'ajout de nouvelles implémentations de KDF et PRF. L'ancienne API EVP_PKEY, grâce à laquelle les algorithmes scrypt, TLS1 PRF et HKDF étaient disponibles, a été repensée sous la forme d'une couche implémentée au-dessus des API EVP_KDF et EVP_MAC.
- La mise en œuvre du protocole TLS offre la possibilité d'utiliser le client et le serveur TLS intégrés au noyau Linux pour accélérer les opérations. Pour activer l'implémentation TLS fournie par le noyau Linux, vous devez activer l'option "SSL_OP_ENABLE_KTLS" ou le paramètre "enable-ktls".
- Ajout de la prise en charge de nouveaux algorithmes :
- Les algorithmes de génération de clés (KDF) sont « SINGLE STEP » et « SSH ».
- Les algorithmes d'insertion simulée (MAC) sont « GMAC » et « KMAC ».
- Algorithme d'encapsulation de clé RSA (KEM) "RSASVE".
- Algorithme de chiffrement « AES-SIV » (RFC-8452).
- Ajout d'appels à l'API EVP avec prise en charge des chiffrements inverses utilisant l'algorithme AES pour chiffrer les clés (Key Wrap) : « AES-128-WRAP-INV », « AES-192-WRAP-INV », « AES-256-WRAP- INV", "AES-128-WRAP-PAD-INV", "AES-192-WRAP-PAD-INV" et "AES-256-WRAP-PAD-INV".
- Ajout de la prise en charge des algorithmes d'emprunt de texte chiffré (CTS) à l'API EVP : « AES-128-CBC-CTS », « AES-192-CBC-CTS », « AES-256-CBC-CTS », « CAMELLIA-128-CBC ». -CTS", "CAMELLIA-192-CBC-CTS" et "CAMELLIA-256-CBC-CTS".
- Ajout de la prise en charge des signatures numériques CAdES-BES (RFC 5126).
- AES_GCM implémente le paramètre AuthEnvelopedData (RFC 5083) pour activer le chiffrement et le déchiffrement des messages authentifiés et chiffrés à l'aide du mode AES GCM.
- Les fonctions PKCS7_get_octet_string et PKCS7_type_is_other ont été ajoutées à l'API publique.
- L'API PKCS#12 remplace les algorithmes par défaut utilisés dans la fonction PKCS12_create() par PBKDF2 et AES et utilise l'algorithme SHA-256 pour calculer MAC. Pour restaurer le comportement passé, l'option "-legacy" est fournie. Ajout d'un grand nombre de nouveaux appels étendus à PKCS12_*_ex, PKCS5_*_ex et PKCS8_*_ex, tels que PKCS12_add_key_ex().PKCS12_create_ex() et PKCS12_decrypt_skey_ex().
- Pour la plate-forme Windows, la prise en charge de la synchronisation des threads à l'aide du mécanisme SRWLock a été ajoutée.
- Ajout d'une nouvelle API de traçage, activée via le paramètre activate-trace.
- La gamme de clés prises en charge dans les fonctions EVP_PKEY_public_check() et EVP_PKEY_param_check() a été étendue : RSA, DSA, ED25519, X25519, ED448 et X448.
- Le sous-système RAND_DRBG a été supprimé, remplacé par l'API EVP_RAND. Les fonctions FIPS_mode() et FIPS_mode_set() ont été supprimées.
- Une partie importante de l'API est devenue obsolète : l'utilisation d'appels obsolètes dans le code du projet entraînera des avertissements lors de la compilation. Les API de bas niveau liées à certaines implémentations d'algorithmes (par exemple, AES_set_encrypt_key et AES_encrypt) ont été officiellement déclarées obsolètes. La prise en charge officielle dans OpenSSL 3.0.0 n'est désormais fournie que pour les API EVP de haut niveau qui sont extraites des types d'algorithmes individuels (cette API inclut, par exemple, les fonctions EVP_EncryptInit_ex, EVP_EncryptUpdate et EVP_EncryptFinal). Les API obsolètes seront supprimées dans l'une des prochaines versions majeures. Les implémentations d'algorithmes existants tels que MD2 et DES, disponibles via l'API EVP, ont été déplacées vers un module « hérité » distinct, qui est désactivé par défaut.
- La documentation et la suite de tests ont été considérablement élargies. Par rapport à la branche 1.1.1, le volume de documentation a augmenté de 94 % et la taille du code de la suite de tests a augmenté de 54 %.
Source: opennet.ru