OpenSSL 4.1 liefert DTLS 1.3 nach zwei Wochen Verzögerung

OpenSSL 4.1.0 ist da. Das Projekt hat das Release am 23. Oktober 2026 getaggt, und die wichtigste Neuerung ist DTLS 1.3, die neueste Version des Verschlüsselungsprotokolls für Datenverkehr, der als einzelne Datagramme verschickt wird. Viele Apps beziehen ihre Verschlüsselung von OpenSSL. Die Unterstützung dort entscheidet daher, wann diese Apps DTLS 1.3 überhaupt einschalten können.

Das GitHub-Release nennt es „ein Feature-Release, das bedeutende neue Funktionen hinzufügt". Phoronix berichtete am selben Morgen über das stabile Release.

Was in OpenSSL 4.1 neu ist

DTLS ist die Version von TLS, die für UDP gebaut ist, wo Pakete verspätet, in falscher Reihenfolge oder gar nicht ankommen können. TLS ist das Protokoll hinter dem Schloss-Symbol im Browser. DTLS 1.3 folgt RFC 9147, dem im April 2022 veröffentlichten Standard. Die Unterstützung in OpenSSL kommt also mehr als vier Jahre nach der Spezifikation.

Die Release Notes nennen diese Änderungen:

Änderung	Was sie bewirkt
DTLS 1.3 (RFC 9147)	Neuestes Datagramm-TLS, mit einer neuen Anleitungsseite, ossl-guide-dtlsv13(7)
DTLS in der Listener-API	Ein Server-Socket kann viele DTLS-Clients annehmen
GREASE (RFC 8701)	Sendet zufällige Platzhalterwerte, um Server zu erkennen, die bei unbekannten Werten versagen
IKEv2 KDF	Schlüsselableitung für den Schlüsselaustausch des IKEv2-VPN
Elbrus2000 (e2k)	Erste Unterstützung für diese CPU-Architektur
Neue Targets für MSVC 2013	Build-Targets VC-WIN32-MSVC2013 und VC-WIN64A-MSVC2013

GREASE braucht noch eine Zeile Erklärung. Clients senden erfundene Werte in Feldern, in denen künftige Versionen echte Werte ergänzen könnten. Ein Server, der daran abstürzt, fällt jetzt auf, bevor eine echte Erweiterung erscheint.

Schnellere Post-Quanten-Mathematik

Ein Großteil der Arbeit an der Geschwindigkeit zielt auf Post-Quanten-Kryptografie. ML-DSA und ML-KEM sind neue Algorithmen für Signaturen und Schlüsselaustausch, die künftigen Quantencomputern standhalten sollen. Schnellerer Code für sie senkt die Kosten des Umstiegs.

Laut den Release Notes fügt 4.1 AVX-512-Code für das SHAKE-Hashing hinzu, das ML-DSA auf x86_64-Chips nutzt. Es beschleunigt die Mathematik von ML-DSA und ML-KEM auf ppc64le, der POWER-Architektur von IBM. AVX-512- und VAES-Befehle beschleunigen außerdem die AES-CBC-Entschlüsselung auf x86_64.

Was entfernt wurde

Das Release streicht zwei alte Windows-Plattformen, wie Phoronix anmerkt: Windows auf Itanium (VC-WIN64I) und Windows CE (VC-CE). Auch die Build-Optionen no-ecdsa und no-ecdh sind weg; der Ersatz ist no-ec. Das Hilfsskript tsget braucht jetzt das Perl-Modul Net::Curl::Easy statt WWW::Curl::Easy.

Warum das finale Release zu spät kam

Der Weg zu 4.1.0 war holprig. Laut Linux Compatible erschien am 9. Oktober 4.1.0-beta2 anstelle des geplanten finalen Releases. Zwei DTLS-Sicherheitsprobleme, #33172 und #33173, tauchten während der Beta auf und hielten den Tag auf. Laut der Website scheinen sie vor dem Release am 23. Oktober behoben worden zu sein.

Das Release erscheint dennoch mit vier bekannten DTLS-Fehlern. Der größte, #32878, betrifft Schlüsselaktualisierungen. Nach einem KeyUpdate in DTLS 1.3 können andere ausstehende Records aus dem Puffer für erneutes Senden fallen. Ein verlorenes Session-Ticket wird dann womöglich nie erneut gesendet. Eine Korrektur ist für ein späteres Release geplant. Linux Compatible nennt außerdem Einschränkungen: keine Unterstützung für die Connection ID von DTLS 1.3, und DTLS 1.3 über SCTP fällt auf ältere Versionen zurück.

Support-Zeiträume

OpenSSL 4.1 ist kein Release mit Langzeitsupport. Die Download-Seite des Projekts nennt November 2027 als Ende der Lebensdauer. OpenSSL 4.0, dessen neuester Patch 4.0.3 vom 29. September ist, wird bis zum 14. Mai 2027 unterstützt. OpenSSL 3.5 bleibt das Langzeit-Release und wird bis zum 8. April 2030 unterstützt.

Die Release-Richtlinie des Projekts schließt API- oder ABI-Brüche in einem Minor-Release aus. Laut Linux Compatible bleibt 4.1 mit der 4.0-Linie kompatibel. Die meisten gegen 4.0 gebauten Apps sollten also nicht neu kompiliert werden müssen.

Was das für Entwickler bedeutet

Wenn Sie UDP-Dienste mit DTLS betreiben, ist 4.1 das erste OpenSSL mit 1.3. Testen Sie es in Staging, nicht in Produktion. Die vier offenen Fehler stecken alle im neuen DTLS-Code, und #32878 kann nach einer Schlüsselaktualisierung Session-Tickets verlieren. Führen Sie eigene Tests zu Schlüsselaktualisierung und Paketverlust durch, bevor Sie sich darauf verlassen.

Server, die viele DTLS-Clients über einen Socket annehmen, sollten sich die Listener-API ansehen. Laut Linux Compatible unterstützt SSL_new_listener() jetzt DTLS 1.3 und ersetzt DTLSv1_listen(), das nur DTLS 1.0 und 1.2 abdeckte.

Die meisten Nutzer von TLS über TCP können im normalen Rhythmus aktualisieren. Die Post-Quanten-Beschleunigungen zahlen sich auf x86_64-Servern mit AVX-512 und auf POWER-Systemen aus.

Planen Sie Ihr Support-Fenster. Braucht Ihr Produkt eine Bibliothek mit Support über 2027 hinaus, bleiben Sie beim Langzeit-Release 3.5 und behandeln Sie 4.1 als kurzlebigen Zweig. Windows-Builds für Itanium oder CE müssen bei 4.0 oder älter bleiben.