Rustls 0.23.45 behebt einen TLS-1.3-Fehler von 2024

Rustls 0.23.45 erschien am 14. September 2026 und behebt einen Fehler im TLS-1.3-Handshake, der etwa zwei Jahre in veröffentlichtem Code steckte. Betroffen ist jede Version von 0.23.13 bis 0.23.44. Wer von Rustls abhängt, sollte also prüfen, welche Version der eigene Build tatsächlich auflöst. Phoronix berichtete über die Veröffentlichung, und das Projekt hat die Details als Advisory GHSA-2mjx-qc3c-rqvc hinterlegt.

Rustls ist eine in Rust geschriebene TLS-Bibliothek. TLS ist das Protokoll hinter HTTPS, und eine TLS-Bibliothek ist das, womit Ihr Programm eine verschlüsselte Verbindung aufbaut. Rustls ist eine häufige Wahl in Rust-Diensten, die OpenSSL vermeiden wollen.

Was der Fehler tatsächlich erlaubt

Mitten im TLS-1.3-Handshake wechseln beide Seiten die Schlüssel. Nachrichten nach diesem Wechsel sollen mit dem neuen Schlüssel verschlüsselt sein. Rustls hat das nicht immer erzwungen.

Das Advisory benennt die Bedingung genau. Rustls akzeptierte Handshake-Nachrichten auf der falschen Verschlüsselungsebene, wenn sie einer schlüsselwechselnden Nachricht innerhalb desselben Records folgten. Ein Record ist der Block, den das Protokoll wirklich auf die Leitung legt, daher können mehrere Handshake-Nachrichten gemeinsam reisen.

Ehrlich gelesen ist das schmaler, als es zunächst klingt. "Das Handshake-Transkript ist weiterhin authentifiziert", heißt es in der Ankündigung. Ein Angreifer in einer Netzwerkposition kann damit also keinen Handshake verändern oder einen abschließen, den er nicht abschließen dürfte. Praktisch heißt es: Ein Gegenüber konnte im Klartext senden, was das Protokoll verschlüsselt verlangt, und Rustls wies die Verbindung nicht ab.

Das ist also ein Fehler in der Strenge und keine gebrochene Authentifizierung. Wichtig bleibt es dennoch. Eine Bibliothek, die von der Spezifikation verbotene Nachrichten annimmt, weicht in ihrem Verhalten von RFC 8446 ab. Und aus solchen Abweichungen entstehen Interoperabilitätsfehler und spätere Angriffe.

Speichersicherheit war nie die ganze Aufgabe

Phoronix zieht den nützlichen Schluss, und er gehört klar gesagt. Rustls existiert unter anderem, weil speicherunsicherer TLS-Code eine lange Geschichte schwerer Fehler hat, und Rust beseitigt diese Fehlerklasse. Dieser Fehler gehört nicht dazu.

Nichts an Rust verhindert, dass ein Protokoll-Zustandsautomat eine Nachricht annimmt, die er hätte ablehnen sollen. Das ist ein Logikfehler, und Logikfehler überleben jede Sprachwahl. Eine Neuschreibung in einer sicheren Sprache befreit von Pufferüberläufen und Use-after-free, nicht davon, eine Spezifikation falsch zu lesen.

Diese Seite hat denselben Punkt von der anderen Seite gemacht: Ein Rust-Paket war das Vehikel für einen Lieferketten-Angriff zur Build-Zeit auf arrayref. Die Sprache ist eine Verteidigungsschicht, und nur eine.

Welche Versionen zu prüfen sind

Version	Status
0.23.13 bis 0.23.44	Betroffen
0.23.45	Behoben
Vor 0.23.13	Liegt laut Advisory vor der Änderung, die den Fehler einführte

Der Fehler wurde im September 2024 eingeführt. Deshalb beginnt der betroffene Bereich bei 0.23.13 und nicht am Anfang. Das Problem wird außerdem als GO-2026-4340 geführt.

Was das für Entwickler bedeutet

Aktualisieren, und dann herausfinden, was Sie wirklich ausgeführt haben. Das sind zwei getrennte Aufgaben, und die zweite wird übersprungen.

Führen Sie cargo update -p rustls aus und prüfen Sie, dass Sie bei 0.23.45 oder neuer landen. Führen Sie dann cargo tree -i rustls aus, um zu sehen, was es hereingezogen hat. Rustls ist meist eine indirekte Abhängigkeit und kommt über einen HTTP-Client oder ein Server-Framework. Welche Version Sie erhalten, entscheiden also die Spannen, die diese Crates zulassen. Eine transitive Festlegung in einer Bibliothek, die Sie nicht kontrollieren, ist der häufige Grund, warum ein Upgrade scheinbar nichts bewirkt.

Wenn Sie eine Binärdatei statt eines Dienstes ausliefern, prüfen Sie die Lockfile, aus der Sie wirklich gebaut haben, nicht die heute auf Ihrem Rechner. cargo audit in die CI einzubauen lohnt sich unabhängig davon, ob dieser Fehler Sie betrifft, und es wird das Advisory melden, sobald die Datenbank es führt.

Verbringen Sie damit aber nicht den Nachmittag in der Notfallbehandlung. In keiner der beiden Quellen gibt es Hinweise auf eine Ausnutzung, und das Advisory sagt selbst, dass das Transkript authentifiziert bleibt, was die schlimmste Lesart ausschließt. Behandeln Sie es als gewöhnliche Abhängigkeitsaktualisierung mit einer echten Frist, nicht als Notfall.

Die größere Lehre betrifft die Lebensdauer eines stillen Protokollfehlers. Dieser steckte zwei Jahre in ausgelieferten Versionen, in einer Bibliothek, die genau wegen ihrer Sicherheitseigenschaften gewählt wird, und gefunden wurde er durch Prüfung und nicht durch einen Vorfall. Das ist das System bei der Arbeit. Und es erinnert daran, dass "in Rust geschrieben" eine Aussage über eine Fehlerkategorie ist und über nichts weiter.