Matt Caswell, membre de l'équipe de développement du projet OpenSSL, a annoncé le 7 septembre la sortie de OpenSSL 3.0. « Après 3 ans de développement, 17 versions alpha, 2 versions bêta, plus de 7 500 commits et des contributions de plus de 350 auteurs différents, nous avons finalement publié OpenSSL 3.0 ! », a annoncé Matt Caswell sur le blog officiel dédié à la plateforme.Rappelons que OpenSSL est une boîte à outils de chiffrement comportant deux bibliothèques, libcrypto et libssl, fournissant respectivement une implémentation des algorithmes cryptographiques et du protocole de communication SSL/TLS, ainsi qu'une interface en ligne de commande, Openssl. Développée en C, OpenSSL est disponible sur les principaux systèmes d'exploitation et dispose de nombreux wrappers ce qui la rend utilisable dans une grande variété de langages informatiques. Utilisé par deux tiers des sites Web en 2014, la documentation d’OpenSSL a augmenté de 94 % depuis OpenSSL 1.1.1 et le nombre de « lignes de code » dans nos tests a augmenté de 54 % (après ajustement). « Il n'y a jamais eu de meilleure démonstration de la communauté active et enthousiaste que nous avons que lorsque vous regardez les statistiques du travail de développement d'OpenSSL 3.0. Merci à tous ceux qui ont pris part à ce projet, même si leur participation était minime », a déclaré le membre de l'équipe de développement du projet OpenSSL, Matt Caswell.
Le projet OpenSSL a la chance d'avoir eu un certain nombre d'ingénieurs à plein temps qui ont travaillé sur OpenSSL 3.0, financés de plusieurs manières. Certaines entreprises ont conclu des contrats de support avec l’équipe de développement d‘OpenSSL, sponsorisé des fonctionnalités spécifiques telles que le module FIPS. Notons qu’avant cette sortie, le projet OpenSSL était en difficulté avec FIPS, depuis octobre 2020, OpenSSL n'avait pas de validation FIPS 140 active. OpenSSL avait prévu de restaurer sa validation FIPS avec OpenSSL 3.0, cependant ils ont rencontré des retards importants, et comme les tests FIPS 140-2 se terminaient en septembre 2021, OpenSSL a finalement décidé de concentrer également ses efforts sur les standards FIPS 140-3.
Une caractéristique clé d'OpenSSL 3.0 est le nouveau module FIPS. L’équipe de développement d‘OpenSSL est en train de tester le module et de rassembler les documents nécessaires à la validation de FIPS 140-2. OpenSSL a indiqué que les documents seront soumis dans le courant du mois. Le certificat final ne devrait pas être délivré avant l'année prochaine. L'utilisation du nouveau module FIPS dans les projets de développement d’applications peut être aussi simple que d'apporter quelques modifications au fichier de configuration, bien que de nombreuses applications devront apporter d'autres changements. La page de manuel du module FIPS fournit des informations sur la manière d'utiliser le module FIPS dans vos applications.
Il convient également de noter que depuis OpenSSL 3.0, OpenSSL est passée à la licence Apache 2.0. Les anciennes licences "doubles" OpenSSL et SSLeay s'appliquent toujours aux anciennes versions (1.1.1 et antérieures). OpenSSL 3.0 est une version majeure et n'est pas entièrement rétrocompatible avec la version précédente. La plupart des applications qui fonctionnaient avec OpenSSL 1.1.1 fonctionneront toujours sans changement et devront simplement être recompilées (avec éventuellement de nombreux avertissements de compilation concernant l'utilisation d'API obsolètes).
Certaines applications devront peut-être être modifiées pour être compilées et fonctionner correctement, et de nombreuses applications devront être modifiées pour éviter les avertissements de dépréciation. L'un des principaux changements apportés par OpenSSL 1.1.1 est l'introduction du concept de fournisseur. Les fournisseurs rassemblent et mettent à disposition des implémentations d'algorithmes. Avec OpenSSL 3.0, il est possible de spécifier, soit de manière programmatique, soit via un fichier de configuration, quels fournisseurs l’utilisateur souhaite utiliser pour une application donnée. OpenSSL 3.0 est livré en standard avec 5 fournisseurs différents. Au fil du temps, des tiers pourront distribuer des fournisseurs supplémentaires qui pourront être intégrés à OpenSSL. Toutes les implémentations d'algorithmes disponibles via les fournisseurs sont accessibles via les API de "haut niveau" (par exemple les fonctions préfixées par EVP). Il n'est pas possible d'y accéder en utilisant les API de "bas niveau".
L'un des fournisseurs standard disponibles est le fournisseur FIPS. Il met à disposition des algorithmes cryptographiques validés par la FIPS. Le fournisseur FIPS est désactivé par défaut et doit être activé explicitement au moment de la configuration à l'aide de l'option enable-fips. S'il est activé, le fournisseur FIPS est construit et installé en plus des autres fournisseurs standard. Aucune procédure d'installation séparée n'est nécessaire. Il existe cependant une cible make dédiée install_fips, qui sert à installer uniquement le fournisseur FIPS dans une installation OpenSSL existante.
Tous les algorithmes peuvent ne pas être disponibles pour l'application à un moment donné. Si le code de l'application utilise un algorithme de chiffrement via l'interface EVP, l'application doit vérifier le résultat des fonctions EVP_EncryptInit(), EVP_EncryptInit_ex() et EVP_DigestInit(). Dans le cas où l'algorithme demandé ne serait pas disponible, ces fonctions échoueront. Les fonctions d'API qui ont été dépréciées seront éventuellement supprimées d'OpenSSL dans une prochaine version, il est donc recommandé de mettre à jour les applications pour utiliser des API alternatives afin d'éviter ces fonctions dépréciées. OpenSSL 3.0 introduit un certain nombre de nouveaux concepts que les développeurs d'applications et les utilisateurs d'OpenSSL doivent connaître.
La bibliothèque libcrypto
La bibliothèque cryptographique OpenSSL (libcrypto) implémente une large gamme d'algorithmes cryptographiques utilisés dans divers standards Internet. La fonctionnalité comprend le cryptage symétrique, la cryptographie à clé publique, l'accord de clé, la gestion des certificats, les fonctions de hachage cryptographiques, les générateurs de nombres pseudo-aléatoires cryptographiques, les codes d'authentification de message (MAC), les fonctions de dérivation de clé (KDF) et divers utilitaires. Les services fournis par cette bibliothèque sont utilisés pour implémenter de nombreux autres produits et protocoles tiers. Voici, ci-dessous, un aperçu des concepts clés de libcrypto.
Algorithmes
Les primitives cryptographiques telles que le condensé SHA256 ou le chiffrement AES sont appelés "algorithmes" dans OpenSSL. Chaque algorithme peut avoir plusieurs implémentations disponibles. Par exemple, l'algorithme RSA est disponible sous la forme d'une implémentation "par défaut" adaptée à une utilisation générale, et d'une implémentation "fips" qui a été validée selon les normes FIPS pour les situations où cela est important. Il est également possible qu'une tierce partie ajoute des implémentations supplémentaires, par exemple dans un module de sécurité matériel (HSM).
Opérations
Les différents algorithmes peuvent être regroupés en fonction de leur objectif. Par exemple, il existe des algorithmes pour le chiffrement et d'autres pour les données. Ces différents groupes sont appelés "opérations" dans OpenSSL. Chaque opération a un ensemble différent de fonctions qui lui sont associées.
Fournisseurs
Un fournisseur dans OpenSSL est un composant qui rassemble des implémentations d'algorithmes. Afin d'utiliser un algorithme, l’utilisateur doit avoir au moins un fournisseur chargé qui contient une implémentation de celui-ci. OpenSSL est fourni avec un certain nombre de fournisseurs et ils peuvent également être obtenus auprès de tiers. Si aucun fournisseur n’est chargé explicitement (soit dans le code du programme, soit via la configuration), le fournisseur "par défaut" intégré à OpenSSL sera automatiquement chargé.
Contextes de bibliothèque
Un contexte de bibliothèque peut être considéré comme une "portée" dans laquelle les options de configuration prennent effet. Lorsqu'un fournisseur est chargé, il l'est uniquement dans le cadre d'un contexte de bibliothèque donné. De cette façon, il est possible que différents composants d'une application complexe utilisent chacun un contexte de bibliothèque différent et que différents fournisseurs soient chargés avec des paramètres de configuration différents. Si une application ne crée pas explicitement un contexte de bibliothèque, le contexte de bibliothèque "par défaut" sera utilisé.
Utilisation du nouveau module FIPS
L'utilisation du nouveau module FIPS dans les applications peut être aussi simple que d'effectuer quelques changements dans le fichier de configuration, bien que de nombreuses applications devront effectuer d'autres changements. Les applications écrites pour utiliser le module FIPS d'OpenSSL 3.0 ne doivent pas utiliser d'API ou de fonctionnalités héritées qui évitent le module FIPS. Cela inclut notamment :
- les API cryptographiques de bas niveau (il est recommandé d’utiliser plutôt les API de haut niveau, comme EVP) ;
- les moteurs ;
- toutes les fonctions qui créent ou modifient des methodes personnalisées (par exemple EVP_MD_meth_new(), EVP_CIPHER_meth_new(), EVP_PKEY_meth_new(), RSA_meth_new(), EC_KEY_METHOD_new() ).
Pour faire en sorte que toutes les applications utilisent le module FIPS par défaut, une approche simple consiste à faire en sorte que toutes les applications qui utilisent OpenSSL n'utilisent par défaut que le module FIPS pour les algorithmes cryptographiques. Cette approche peut être réalisée uniquement par configuration. Tant que les applications sont construites et liées à OpenSSL 3.0 et ne remplacent pas le chargement du fichier de configuration par défaut ou ses paramètres, elles peuvent automatiquement commencer à utiliser le module FIPS sans avoir besoin de modifier le code. Pour ce faire, le fichier de configuration OpenSSL par défaut devra être modifié. L'emplacement de ce fichier de configuration dépendra de la plateforme et des options qui ont été données pendant le processus de construction. L'emplacement du fichier peut être vérifié en exécutant cette commande :
| Code : | Sélectionner tout |
1 2 | $ openssl version -d
OPENSSLDIR: "/usr/local/ssl" |
Une variante de l'approche précédente consiste à faire la même chose pour chaque application. Le fichier de configuration OpenSSL par défaut dépend de la valeur compilée pour OPENSSLDIR comme décrit précédemment. Cependant, il est également possible de modifier le fichier de configuration à utiliser via la variable d'environnement OPENSSL_CONF. Par exemple, l'exemple suivant, sous Unix, fera en sorte que l'application soit exécutée avec un emplacement de fichier de configuration non standard :
| Code : | Sélectionner tout |
$ OPENSSL_CONF=/my/nondefault/openssl.cnf myapplication
Les applications peuvent choisir de charger explicitement le fournisseur FIPS plutôt que de s'appuyer sur le fichier config pour le faire. Le fichier config est toujours nécessaire pour contenir les données de configuration du module FIPS (comme son état d'autotest et ses données d'intégrité). Mais dans ce cas, le fournisseur FIPS n’est pas automatiquement activé via le fichier de configuration.
Utilisation du module FIPS dans SSL/TLS
L'écriture d'une application qui utilise libssl en conjonction avec le module FIPS est à peu près la même que celle d'une application libssl normale. Si le développeur utilise les propriétés globales et le contexte de bibliothèque par défaut pour spécifier l'utilisation des algorithmes validés par FIPS, cela se fera automatiquement pour tous les algorithmes cryptographiques de libssl. S’il utilise un contexte de bibliothèque autre que celui par défaut pour charger le fournisseur FIPS, il est possible de le fournir à libssl en utilisant la fonction SSL_CTX_new_ex(). Cette fonction fonctionne comme un remplaçant de la fonction SSL_CTX_new(), sauf qu'elle donne la possibilité de spécifier le contexte de bibliothèque à utiliser. Il est également possible d’utiliser la même fonction pour spécifier les propriétés spécifiques de libssl. Dans cl'exemple ci-dessous, on crée deux objets SSL_CTX en utilisant deux contextes de bibliothèque différents.
| Code C : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | /* * We assume that a nondefault library context with the FIPS * provider loaded has been created called fips_libctx. */ SSL_CTX *fips_ssl_ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method()); /* * We assume that a nondefault library context with the default * provider loaded has been created called non_fips_libctx. */ SSL_CTX *non_fips_ssl_ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); |
Dans le deuxième exemple, on crée deux objets SSL_CTX en utilisant différentes propriétés pour spécifier l'utilisation de FIPS :
| Code C : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | /* * The "fips=yes" property includes all FIPS approved algorithms * as well as encoders from the default provider that are allowed * to be used. The NULL below indicates that we are using the * default library context. */ SSL_CTX *fips_ssl_ctx = SSL_CTX_new_ex(NULL, "fips=yes", TLS_method()); /* * The "provider!=fips" property allows algorithms from any * provider except the FIPS provider */ SSL_CTX *non_fips_ssl_ctx = SSL_CTX_new_ex(NULL, "provider!=fips", TLS_method()); |
Source : OpenSSL
Et vous ?
Que pensez-vous de la version 3.0 d'OpenSSL ? Peut-on affirmer sans risque de se tromper qu'OpenSSL est incontournable pour la sécurité informatique ?Voir aussi :
Sortie de Qt 5.12.4, avec une nouvelle version d'OpenSSL pour disposer du protocole TLS 1.3, plus sécurisé pour les connexions chiffrées OpenSSL abandonne le support des versions TLS 1.0/1.1 sur Debian Unstable, quelles implications pour les utilisateurs de Sid ? OpenSSL : un audit de sécurité lancé pour améliorer la sécurité de la bibliothèque de chiffrement, les résultats attendus pour l'été Google fork OpenSSL et crée BoringSSL, pour réduire les efforts de maintenance d'OpenSSL dans ses produits 
