Die SSL-Technologie bildet das Rückgrat der modernen Internetkommunikation und sichert Millionen von Verbindungen weltweit ab. SSL-Stacks, also die Sammlung von SSL-Bibliotheken und deren Implementierungen, sind für die Sicherheit und Effizienz von Webservern, Proxy-Systemen und vielen anderen Anwendungen fundamental. In den letzten Jahren hat sich die Landschaft der SSL-Stacks jedoch deutlich verändert. Insbesondere die Veröffentlichung von OpenSSL 3.0 im Jahr 2021 hat eine Vielzahl von Herausforderungen für Entwickler, Administratoren und Unternehmen mit sich gebracht.
Dieser Wandel stellt nicht nur technische Fragen, sondern betrifft auch Betriebskosten, Kompatibilität und zukünftige Entwicklungen der SSL-Infrastruktur. OpenSSL galt über viele Jahre als der De-facto-Standard unter den SSL-Bibliotheken. Seine Verbreitung in nahezu allen gängigen Betriebssystemen sowie umfangreiche Funktionalitäten sorgten für eine solide Basis, auf die viele Softwareprodukte zurückgreifen konnten. Die Veröffentlichung von OpenSSL 3.0 war ursprünglich als ein Schritt hin zu mehr Modularität und erhöhter Sicherheit gedacht.
Doch diese neue Version brachte gravierende Performance-Regressionen mit sich, die besonders in Multi-Threading-Umgebungen deutlich wurden. Viele bisher genutzte APIs wurden zudem depreziert, was die Integration beziehungsweise den Einsatz erschwerte und bei manchen Projekten Anpassungen oder sogar Neuentwicklungen erforderte. Ein besonders wichtiger Rückschlag bestand darin, dass die für moderne Protokolle wie QUIC und HTTP/3 so essenzielle QUIC-API nicht in OpenSSL 3.0 integriert wurde. QUIC ist ein aufstrebendes Transportprotokoll, das herkömmliches TLS über TCP ablöst und sich durch effizientere Verbindungsaufbauten und integrierte Verschlüsselung auszeichnet.
Die fehlende Unterstützung erschwerte die Einführung neuer Technologien und verlangsamte die Adoption von QUIC in vielen Umgebungen. Entwickler mussten daher oft auf alternative Bibliotheken oder spezielle Patches zurückgreifen, was den Wartungsaufwand erhöhte. Die drastischen Performanceeinbußen von OpenSSL 3.0 führten in der Praxis dazu, dass Systeme deutlich mehr Hardware-Ressourcen benötigen, um die gleiche Anzahl an Anfragen zu verarbeiten wie mit älteren Versionen. Messungen zeigten, dass in manchen Szenarien die Leistung auf ein Zehntel sank, was nicht nur zu höheren Betriebskosten durch zusätzlichen Hardwarebedarf führt, sondern auch zu einem größeren Energieverbrauch und somit einer schlechteren Umweltbilanz.
In einem Zeitalter von Nachhaltigkeit und steigendem Bewusstsein für Ressourceneffizienz ist dies ein nicht zu unterschätzender Nachteil. Angesichts dieser Probleme suchten Fachleute und Unternehmen nach Alternativen. Einige der bedeutendsten Konkurrenten sind BoringSSL, LibreSSL, WolfSSL und AWS-LC. Jede dieser Bibliotheken bringt eigene Vor- und Nachteile mit sich. BoringSSL entstand als Abspaltung von OpenSSL, wird von Google gehalten und zeichnet sich durch schnelle Implementierungen neuer Features aus.
Allerdings folgt BoringSSL dem „live at HEAD“-Modell, das häufige API-Änderungen bedeutet, was langfristige Stabilität erschwert. Dennoch führte BoringSSL die QUIC-Unterstützung frühzeitig ein und diente somit als eine wichtige Entwicklungsbasis. LibreSSL wiederum entstand ebenfalls als Fork, mit dem Ziel, OpenSSL sicherer und sauberer zu machen, indem unnötiger und unsicherer Code entfernt wurde. Das Projekt setzt auf eine neue API namens libtls, die als einfacher und sicherer gilt, aber erhebliche Codeanpassungen bei Anwenderprojekten erfordert. LibreSSL legt Wert auf Sicherheit statt auf maximale Performance und verzichtet bewusst auf einzelne Funktionen, die als problematisch gelten, etwa 0-RTT.
WolfSSL punktet vor allem im eingebetteten Bereich und bei leichtgewichtigen Anwendungen. Es bietet eine API-Kompatibilität zu OpenSSL, ohne selbst ein Fork zu sein, was Portierungen vereinfacht. Mit einem Fokus auf Leistung und FIPS-Zertifizierung werden auch industrielle Einsatzszenarien abgedeckt. WolfSSL zeigte in Tests vielversprechende Performance-Werte, ist jedoch bei der Integration in größere Softwareprodukte aufgrund fehlender Features und API-Unterschiede oft anspruchsvoll. AWS-LC ist ein weiterer wichtiger Kandidat, der von Amazon entwickelt wird.
Dieser Fork von BoringSSL und OpenSSL zielt auf hohe Performance und Sicherheit ab, insbesondere auf AWS-Hardware optimiert. AWS-LC bietet eine API-Backwards-Kompatibilität, was Wartungsaufwand verringert. Das Projekt zeigt eine aktive Entwicklung und schnelle Reaktionsfähigkeit bei Fehlerbehebungen, was es für viele Nutzer attraktiv macht. Neben der Wahl der richtigen SSL-Bibliothek spielen auch funktionale Anforderungen eine wichtige Rolle. Moderne SSL-Stacks müssen eine Vielzahl von TLS-Versionen unterstützen, um verschiedenste Client-Anforderungen abzudecken, und gleichzeitig den Fortschritt zu neueren und sichereren Protokollen wie TLS 1.
3 fördern. Funktionalitäten rund um Zertifikate, wie deren Verifikation, CRL-Prüfungen, OCSP-Status und SNI-Unterstützung, sind unerlässlich für den stabilen Lauf von Systemen. Weiterhin sind Erweiterungen wie ALPN relevant, um zum Beispiel HTTP/2 zu unterstützen, ebenso wie Stapling für OCSP und Transparenzprüfungen, die die Sicherheit erhöhen. Die Performance von SSL/TLS-Operationen ist ein Schlüsselfaktor für den Betrieb moderner Webinfrastrukturen. Handshakes und Verschlüsselungsprozesse sind rechnerisch aufwendig und beanspruchen stark die CPU.
Gerade bei Frontends von stark frequentierten Websites kann dies zum Performance-Flaschenhals werden. Moderne Systeme setzen deshalb auf optimale Multi-Core- und Thread-Auslastung, um die vorhandene Hardware maximal zu nutzen und so die Anzahl der nötigen Server gering zu halten. Dies trägt auch erheblich zur Reduktion von Energieverbrauch und CO2-Emissionen bei. Die starke Lastverteilung und Ressourcenausnutzung führen bei einigen SSL-Bibliotheken dazu, dass Systeme mit weniger physischen Knoten auskommen, was die Infrastruktur vereinfacht und Kosten sparen kann. Dabei zeigen die Tests, dass Bibliotheken wie AWS-LC und WolfSSL in der Lage sind, mit effizienten Locking-Mechanismen und geringem Overhead eine hohe Parallelität zu ermöglichen.
OpenSSL 3.x hingegen leidet unter einer Architektur, die zu einer übermäßigen Verwendung von Locks und atomaren Operationen führt, was die Parallelisierung deutlich limitiert. Die Herausforderungen bei der Wartung von SSL-Bibliotheken sind ebenfalls beträchtlich. Sicherheitslücken müssen zeitnah gepatcht werden, was stabile, getestete und gut dokumentierte Update-Prozesse voraussetzt. Die Migration zwischen Versionen gestaltet sich komplex, da API-Änderungen und der Erhalt von Abwärtskompatibilität hohen Entwicklungsaufwand erfordern.
Zudem ist Expertise in der Konfiguration und Nutzung der Bibliotheken notwendig, was in vielen Teams nicht in ausreichendem Maße vorhanden ist. Ein weiterer Faktor ist die Rolle von Betriebssystem-Distributoren: Da viele Linux-Distributionen nun gezwungen sind, OpenSSL 3.0 auszuliefern, sind Nutzer oft auf eine Version angewiesen, die suboptimale Performance bietet und weniger unterstützt wird. Alternativen, die bessere Leistung liefern, sind häufig nicht offiziell paketiert und erfordern manuellen Aufwand. Dies erschwert die sichere und effiziente Nutzung moderner SSL-Technologien erheblich.
QUIC stellt einen Wendepunkt in der Verschlüsselungstechnologie dar und zeigt, wie SSL-Bibliotheken sich weiterentwickeln müssen. QUIC integriert Verschlüsselung und Transportprotokoll enger als herkömmliche TLS- über TCP-Lösungen, was neue Anforderungen an Bibliotheken stellt. Die fehlende oder nicht standardisierte Unterstützung von QUIC APIs in OpenSSL 3.0 und der teilweise noch aggressive Entwicklungsrhythmus von BoringSSL führen zu einer fragmentierten Landschaft, die die breite Einführung von QUIC ausbremst. Innovative Zwischenlösungen wie QuicTLS, die Patches auf OpenSSL 1.
1.1 aufbringen, bieten eine Brücke, sind aber keine langfristige Antwort. Die Community hofft, dass Projekte wie AWS-LC oder WolfSSL durch ihre aktiven Entwicklungen und Unterstützung für QUIC die dominierende Rolle übernehmen können. Langfristig wäre auch ein gemeinschaftliches Zusammenführen der Kompetenzen und Projekte wünschenswert, um stabile, hochperformante SSL-Stacks mit umfassender QUIC-Unterstützung zu etablieren. Der Ausblick für die SSL-Landschaft bleibt spannend.
OpenSSL muss sich mit der Kritik an der Architektur von Version 3.0 auseinandersetzen und Lösungen finden, um Nutzer nicht zu verlieren. Gleichzeitig zeigen Alternative Bibliotheken, dass hoher Sicherheitsstandard, Performance und neue Protokollunterstützung keine Gegensätze sein müssen. Für Nutzer und Betreiber heißt es, den Markt genau zu beobachten, alternative Optionen auszuprobieren und die am besten geeignete Lösung für den jeweiligen Einsatzzweck zu wählen. Die Herausforderungen konfrontieren die gesamte Internet-Branche mit der Frage, wie Sicherheit, Leistung und Wartbarkeit in Einklang gebracht werden können.
![History of Diffusion – Yang Song [video]](/images/3334A7EC-548F-4B91-923E-C1935B2BF748)
