Sortie d’OpenSSL 4.0.0

 (github.com/openssl)
5 points par GN⁺ 15 일 전 | 2 commentaires | Partager sur WhatsApp
  • Une sortie majeure comprenant de nombreuses nouvelles fonctionnalités et modifications incompatibles
  • La prise en charge de ECH (Encrypted Client Hello, RFC 9849) est intégrée, rendant inutile une implémentation séparée pour protéger la confidentialité des clients TLS
  • Le code SSLv2 Client Hello, SSLv3 et engine a été complètement supprimé, entérinant la rupture avec les protocoles legacy
  • Ajout de la prise en charge de la signature SM2 (sm2sig_sm3), de l’échange de clés (curveSM2) basé sur la RFC 8998, ainsi que du groupe post-quantique curveSM2MLKEM768
  • Ajout de nouvelles fonctions cryptographiques comme cSHAKE (SP 800-185), les digests ML-DSA-MU, la SNMP KDF, la SRTP KDF, etc.
  • Prise en charge de la négociation de l’échange de clés FFDHE basé sur la RFC 7919 dans TLS 1.2
  • Lors de l’installation du module FIPS, l’option -defer_tests permet de différer l’exécution des auto-tests FIPS
  • Modernisation de l’API avec l’ajout du qualificateur const à de nombreuses signatures de fonctions API et l’opacification de ASN1_STRING, entre autres
  • Pour les fonctions obsolètes comme X509_cmp_time(), il est recommandé de les remplacer par X509_check_certificate_times()
  • Avec l’utilisation du provider FIPS de PKCS5_PBKDF2_HMAC, la vérification des valeurs minimales est désormais imposée, et des contrôles supplémentaires ont été ajoutés à la validation des CRL
  • Grand nettoyage des fonctionnalités legacy, notamment les méthodes personnalisées obsolètes EVP_CIPHER, EVP_MD, EVP_PKEY, les fonctions de version SSL/TLS figées, le script c_rehash, BIO_f_reliable(), etc.
  • Suppression des anciennes cibles de build Apple comme darwin-i386 et darwin-ppc
  • Prise en charge sous Windows du choix entre liaison statique et dynamique du runtime VC
  • Cette sortie marque un tournant pour le renforcement de la sécurité et de la conformité aux standards d’OpenSSL

À lire aussi

2 commentaires

 
kaydash 13 일 전

J’ai l’impression que c’était hier, l’époque où on utilisait 1.1.1.
 
GN⁺ 15 일 전
Réactions sur Hacker News

  • Certains se réjouissent enfin de l’ajout du support de Encrypted Client Hello (ECH)

    • Ils se demandent si c’est une fonctionnalité activable dès maintenant, ou s’il faudra encore longtemps avant qu’elle soit prise en charge par les navigateurs et les serveurs
    • QUIC est également mentionné
    • Mais ils avertissent que la plupart des réseaux risquent de bloquer ce type de trafic

  • En citant un billet du blog HAProxy sur l’état des piles SSL, ils insistent sur le fait qu’il ne faut désormais plus utiliser la v3

    • Ils jugent positif qu’OpenSSL n’ait commencé que l’an dernier à fournir des API permettant aux développeurs d’implémenter QUIC eux-mêmes
      Auparavant, utiliser OpenSSL signifiait aussi être forcé d’utiliser sa propre pile QUIC
      QUIC est un protocole qui réimplémente les fonctions de TCP au-dessus d’UDP, et constitue la base de HTTP/3
      Mais même si l’implémentation QUIC d’OpenSSL ne plaisait pas, il n’y avait pas d’alternative
      Par exemple, si curl était lié à OpenSSL, curl devait lui aussi automatiquement utiliser le QUIC d’OpenSSL
      Il est rappelé que Daniel Stenberg de curl a écrit un billet de blog critique à ce sujet

  • À la question sur l’état actuel d’OpenSSL, certains rappellent que la sécurité s’est nettement améliorée depuis l’ancien incident Heartbleed

    • Après Heartbleed, le dispositif de gestion de la sécurité d’OpenSSL a été renforcé, et le projet est devenu l’une des cibles de recherche en sécurité les plus étudiées sur Internet
      Mais beaucoup estiment que la qualité logicielle a au contraire régressé
      La conception d’OpenSSL 3.0 a marqué un recul en matière de performances, et des projets majeurs comme pyca/cryptography montrent une volonté de remplacer OpenSSL
    • Un autre utilisateur estime qu’OpenSSL 3 a été une grande déception en matière de performances, de complexité et d’expérience développeur
      Les opérations centrales d’OpenSSL 3 sont bien plus lentes que celles de la 1.1.1, et il cite l’analyse des piles SSL par HAProxy ainsi que la déclaration de l’équipe Python cryptography
      OpenSSL 3 a rendu de nombreux éléments dynamiques, ce qui a entraîné un usage excessif des verrous (locks), et l’API est passée au modèle OSSL_PARAM, provoquant une baisse de performances et une complexification du code

  • Par rapport à OpenSSL 3, certains indiquent que cette transition s’est déroulée de manière très fluide
    Sous Fedora, à part la suppression des « Engines », la plupart des dépendances ont été corrigées sans problème majeur

  • Il est souligné que les procédures manuelles d’opt-out deviennent un point de friction de plus en plus important
    La situation où il faut une levée de boucliers de la communauté pour améliorer les réglages par défaut est critiquée, avec ce rappel qu’il est difficile de gagner la confiance et facile de la perdre

  • Certains réagissent en plaisantant que la sortie semble calée sur le timing de la « suckerpinch video »

  • Du point de vue d’un non-spécialiste, ce changement ressemble à un grand ménage assez propre, mais les ruptures de compatibilité restent toujours pesantes
    Ils se souviennent aussi qu’OpenSSL 3.x n’avait pas été particulièrement apprécié

    • D’où la réplique : c’est justement pour cela que cette fois c’est la version 4

  • Certains craignent qu’une montée de version majeure rende le logiciel plus lent, mais disent que les benchmarks n’ont montré en moyenne qu’environ 10 % de baisse de performances
    À l’échelle de l’ensemble d’Internet, ils ajoutent que cela ne devrait pas poser de gros problème

  • L’augmentation de l’usage de const dans le code est bien accueillie
    En environnement embarqué, il fallait souvent ajouter soi-même des const, et le fait que cela soit désormais appliqué par défaut est apprécié

  • Enfin, une plaisanterie imagine les cris d’angoisse des gestionnaires de paquets des distributions Linux