OpenSSL 4.0.0 veröffentlicht

• Großes Release mit zahlreichen neuen Funktionen und inkompatiblen Änderungen
• Integrierte Unterstützung für ECH (Encrypted Client Hello, RFC 9849), sodass keine separate Implementierung mehr nötig ist, um die Privatsphäre von TLS-Clients zu schützen
• SSLv2 Client Hello sowie SSLv3 und Engine-Code wurden vollständig entfernt, womit die Trennung von Legacy-Protokollen endgültig vollzogen ist
• Unterstützung hinzugefügt für SM2-Signaturen (sm2sig_sm3) auf Basis von RFC 8998, Schlüsselaustausch (curveSM2) und die Post-Quanten-Gruppe curveSM2MLKEM768
• Neue Kryptofunktionen wie cSHAKE (SP 800-185), ML-DSA-MU-Digest, SNMP KDF und SRTP KDF hinzugefügt
• Unterstützung für die Aushandlung von FFDHE-Schlüsselaustausch auf Basis von RFC 7919 in TLS 1.2
• Bei der Installation des FIPS-Moduls kann mit der Option -defer_tests die Ausführung der FIPS-Selbsttests verzögert werden
• Modernisierung der API durch Hinzufügen des const-Qualifizierers zu zahlreichen Funktionssignaturen und die Opakisierung von ASN1_STRING
• Für veraltete Funktionen wie X509_cmp_time() wird der Ersatz durch X509_check_certificate_times() empfohlen
• Bei Nutzung des FIPS-Providers mit PKCS5_PBKDF2_HMAC wird die Prüfung von Mindestwerten erzwungen; zudem wurden zusätzliche Prüfungen für die CRL-Validierung ergänzt
• Umfassende Bereinigung von Legacy-Funktionen, darunter veraltete benutzerdefinierte EVP_CIPHER-, EVP_MD- und EVP_PKEY-Methoden, Funktionen für feste SSL/TLS-Versionen, das Skript c_rehash und BIO_f_reliable()
• Alte Apple-Build-Targets wie darwin-i386 und darwin-ppc entfernt
• Unter Windows wird die Auswahl zwischen statischer und dynamischer Verknüpfung der VC-Laufzeitbibliothek unterstützt
• Dieses Release markiert einen Wendepunkt zur Stärkung von Sicherheit und Standardkonformität in OpenSSL

[kaydash]

Es kommt mir vor, als wäre es erst gestern gewesen, dass wir noch 1.1.1 benutzt haben.

[GN⁺]

Hacker-News-Kommentare

• Es wird Freude darüber ausgedrückt, dass endlich Unterstützung für Encrypted Client Hello (ECH) hinzugefügt wurde

  • Man fragt sich, ob sich die Funktion sofort aktivieren lässt oder ob es wieder lange dauern wird, bis Browser und Server sie unterstützen
  • Außerdem wird QUIC zusammen mit dem Thema erwähnt
  • Es wird allerdings gewarnt, dass die meisten Netzwerke solchen Traffic wahrscheinlich blockieren werden

• Unter Verweis auf den Beitrag State of SSL Stacks im HAProxy-Blog wird betont, dass man v3 nun nicht mehr verwenden sollte

  • Positiv bewertet wird, dass OpenSSL erst im vergangenen Jahr begann, APIs bereitzustellen, mit denen Entwickler QUIC direkt implementieren können
    Früher bedeutete die Verwendung von OpenSSL, dass auch die QUIC-Implementierung zwangsweise den Stack von OpenSSL nutzen musste
    QUIC ist ein Protokoll, das TCP-Funktionen über UDP neu implementiert und die Grundlage von HTTP/3 bildet
    Selbst wenn einem die QUIC-Implementierung von OpenSSL nicht gefiel, gab es jedoch keine andere Wahl
    Wenn zum Beispiel curl gegen OpenSSL gelinkt ist, musste curl automatisch ebenfalls das QUIC von OpenSSL verwenden
    Dazu habe Daniel Stenberg von curl einen kritischen Blogbeitrag geschrieben, heißt es

• Auf die Frage nach dem aktuellen Zustand von OpenSSL wird erwähnt, dass sich die Sicherheit seit dem früheren Heartbleed-Vorfall deutlich verbessert habe

  • Nach Heartbleed wurde das Sicherheitsmanagement von OpenSSL gestärkt, und inzwischen ist es eines der am intensivsten erforschten Sicherheitsziele im Internet
    Allerdings wird oft bewertet, dass sich die Softwarequalität eher verschlechtert habe
    Das Design von OpenSSL 3.0 sei bei der Performance ein Rückschritt gewesen, und wichtige Projekte wie pyca/cryptography zeigten Bestrebungen, OpenSSL zu ersetzen
  • Ein anderer Nutzer bewertet OpenSSL 3 als große Enttäuschung bei Performance, Komplexität und Developer Experience
    Die Kernoperationen von OpenSSL 3 seien deutlich langsamer als bei 1.1.1, und dazu werden der Analysebeitrag zu SSL-Stacks von HAProxy sowie die Stellungnahme des Python-cryptography-Teams zitiert
    In OpenSSL 3 seien viele Elemente dynamisch verändert worden, wodurch Locks exzessiv eingesetzt würden, und auch die API sei auf das OSSL_PARAM-Modell umgestellt worden, was Performance-Einbußen und komplexeren Code verursacht habe

• Im Vergleich zu OpenSSL 3 sei diese Umstellung sehr reibungslos verlaufen
  In Fedora seien die meisten Abhängigkeiten mit Ausnahme der Entfernung von "Engines" ohne größere Probleme angepasst worden

• Es wird darauf hingewiesen, dass manuelle Opt-out-Verfahren zunehmend zu einem größeren Reibungspunkt werden
  Kritisiert wird die Realität, dass Standardeinstellungen erst dann verbessert werden, wenn es Gegenwind aus der Community gibt; dabei wird betont, dass Vertrauen schwer aufzubauen und leicht zu verlieren ist

• Es gibt die scherzhafte Reaktion, die Veröffentlichung sei wohl passend zum Timing des „suckerpinch video“ erfolgt

• Aus Sicht eines Nichtfachmanns wirkt diese Änderung wie eine ziemlich saubere Aufräumaktion, auch wenn Kompatibilitätsbrüche immer belastend sind
  Dabei wird an die Erinnerung angeknüpft, dass OpenSSL 3.x nicht besonders beliebt gewesen sei

  • Darauf folgt die Erwiderung: Deshalb ist es jetzt Version 4

• Man befürchtet, dass es durch das Major-Upgrade langsamer werden könnte, aber in tatsächlichen Benchmarks habe es im Durchschnitt nur etwa 10 % Performanceverlust gegeben
  Bezogen auf die gesamte Internetumgebung sei das kein großes Problem, wird ergänzt

• Die verstärkte Verwendung von const im Code wird begrüßt
  In Embedded-Umgebungen habe man const oft selbst ergänzen müssen, und man finde es gut, dass dies nun standardmäßig stärker berücksichtigt werde

• Zum Schluss wird gescherzt, man stelle sich schon die Schmerzensschreie der Paketmanager von Linux-Distributionen vor