OpenSSL 4.1.0 bringt DTLS 1.3, GREASE und schnellere PQC

Das OpenSSL-Projekt hat am 23. Oktober 2026 OpenSSL 4.1.0 veröffentlicht. Die Feature-Version bringt Unterstützung für DTLS 1.3, GREASE nach RFC 8701 und schnellere Post-Quanten-Algorithmen auf x86_64 und ppc64le. Dazu kommen einige Änderungen, die Builds und Skripte brechen können: Konfigurationsoptionen und Build-Ziele fallen weg, das Hilfsprogramm tsget braucht ein anderes Perl-Modul.

Ein Sicherheitsupdate ist 4.1.0 nicht, niemand muss deshalb heute handeln. Relevant ist die Version vor allem für Paketbetreuer, Entwickler und Admins mit eigenen OpenSSL-Builds. Wer OpenSSL nur über die Distribution bezieht, bekommt 4.1 erst mit einem späteren Distributionsrelease. Dringender ist für manche Umgebungen ein anderes Datum: Die Unterstützung für OpenSSL 3.6 endet am 1. November 2026.

Was ist passiert?

Laut Release-Notes auf GitHub umfasst OpenSSL 4.1.0 diese Neuerungen:

• DTLS 1.3 nach RFC 9147, dokumentiert in der Handbuchseite ossl-guide-dtlsv13(7)
• GREASE nach RFC 8701: Zufällige, bedeutungslose Werte im Handshake sollen verhindern, dass Gegenstellen bei unbekannten Erweiterungen scheitern
• DTLS-Unterstützung in der SSL-Listener-API
• Unterstützung für die IKEv2-Schlüsselableitung (KDF)
• Optimierte NTT-Operationen für ML-DSA und ML-KEM auf ppc64le, schnelleres ML-DSA auf x86_64, AVX-512-optimiertes SHAKE x4 für ML-DSA sowie AVX-512- und VAES-Optimierungen für die AES-CBC-Entschlüsselung
• Erste Unterstützung der Elbrus-2000-Architektur (e2k)

DTLS ist das Gegenstück zu TLS für Datagramm-Protokolle wie UDP, bei denen Pakete verloren gehen oder in falscher Reihenfolge ankommen können. Mit Version 1.3 übernimmt DTLS die Sicherheitsverbesserungen von TLS 1.3.

Für wen ist das relevant?

Vor allem für Distributions- und Paketbetreuer, Entwickler von Anwendungen mit eigener OpenSSL-Bindung und Admins, die OpenSSL selbst kompilieren, etwa für Container-Images oder Appliances. Diese Änderungen sollten sie vor einem Wechsel kennen:

• Die Build-Ziele für Windows on Itanium (VC-WIN64I) und Windows CE (VC-CE) entfallen.
• Die Configure-Optionen no-ecdsa und no-ecdh sind entfernt, weil sie die Implementierungen nie wirklich abgeschaltet haben. Stattdessen ist no-ec zu verwenden.
• tsget nutzt jetzt Net::Curl::Easy statt des aufgegebenen WWW::Curl::Easy. Wer das Werkzeug für Zeitstempel einsetzt, muss das Modul vor dem Upgrade installieren.
• Neu sind die Build-Ziele VC-WIN32-MSVC2013 und VC-WIN64A-MSVC2013 für ältere MSVC-Compiler.

Wie ausgereift ist das Release?

Das Projekt nennt vier bekannte Fehler, alle rund um DTLS. Nach einem DTLS-1.3-KeyUpdate verwirft OpenSSL ausstehende Post-Handshake-Nachrichten aus dem Wiederholungspuffer, etwa ein NewSessionTicket. Dauerhafte Empfangsfehler an einem DTLS-Listener können als SSL_ERROR_WANT_READ gemeldet werden, wiederholbare Schreibfehler als SSL_ERROR_SYSCALL. Zudem können DTLS-1.3-Server Handshakes abbrechen, wenn der Client einen Teil der ersten Server-Antwort vorzeitig bestätigt, etwa nach Paketverlust. Korrekturen sind angekündigt. Wer DTLS 1.3 produktiv einsetzen will, sollte daher ein Folgerelease abwarten oder gründlich unter Paketverlust testen.

Was sollten Admins jetzt tun?

• Inventar prüfen: Welche OpenSSL-Version läuft wo, etwa per openssl version auf Hosts und in Container-Images, und stammt sie aus Distributionspaketen oder eigenen Builds?
• Supportfristen abgleichen: 3.6 läuft am 1. November 2026 aus, 4.0 am 14. Mai 2027, das LTS-Release 3.5 bis 8. April 2030. Für 4.1 nennt das Projekt November 2027.
• Eigene Build-Skripte auf no-ecdsa, no-ecdh und entfernte Ziele durchsuchen und anpassen.
• Bei Nutzung von tsget das Perl-Modul Net::Curl::Easy bereitstellen.
• Für produktive Server ohne Bedarf an neuen Funktionen beim LTS-Zweig 3.5 bleiben und 4.1 zunächst in einer Testumgebung prüfen.

Einordnung für Unternehmen

Für die meisten KMU ändert sich mit 4.1.0 zunächst nichts, denn Server und Anwendungen nutzen die OpenSSL-Version der Distribution, und die Hersteller pflegen ihre Pakete selbst. Wichtiger ist der Blick auf eigene Container-Images und Appliances mit statisch gelinktem OpenSSL. Hier entscheidet der Supportstand des eingesetzten Zweigs darüber, ob künftige Sicherheitskorrekturen noch ankommen. Wer heute noch 3.6 oder älter selbst baut, sollte den Wechsel auf 3.5 LTS oder einen 4.x-Zweig jetzt planen.

Passende Anleitungen auf S-EDV

• OpenSSL HollowByte: DoS-Lücke mit stillem Fix: Warum der Versionsstand eigener Builds zählt.
• OpenSSH 10.6 mit Post-Quanten-Signaturen: Der Stand der Post-Quanten-Migration bei einem weiteren Kernwerkzeug.

Quellen

• OpenSSL: Release-Notes zu OpenSSL 4.1.0 auf GitHub (23.10.2026)
• OpenSSL Library: Downloads und Supportende der Release-Zweige
• OpenSSL Library: Release-Strategie und Supportzeiträume
• Linuxiac: OpenSSL 4.1 mit DTLS 1.3 und Krypto-Optimierungen
• Phoronix: OpenSSL 4.1 mit weiteren AVX-512-Optimierungen (23.10.2026)