Es scheint bei OpenSSL ab Version 3 zu Leistungsproblemen zu kommen, wie ich einem Kommentar im Diskussionsbereich des Blogs entnehmen konnte. Ich ziehe diesen Text mal in einen separaten Blog-Beitrag heraus.
Anzeige
Blog-Leser Norddeutsch schrieb zum 11. Mail 2025 unter "Performance Issues & OpenSSL >= Version 3 …": wer bei OpenSSL, HA-Proxy oder HTTP/3 Probleme wie hohe CPU-Last, Durchsatz und wenige parallele Verbindungen erleidet sollte sich folgende Links anschauen.
a) Messungen vom CURL-Projekt auf Github hier
b) Diagnose und Analyse vom HA-Proxy Projekt hier
Auf GitHub gibt es den Eintrag curl HTTP/3 Performance, der sich mit einigen Performance-Messungen auseinandersetzt. Tenor: 10-90% Performance Drop bei Einsatz von OpenSSL 3.0 bis 3.3 oder 3.4.
Norddeutsch schreibt: Ursache scheint der "Programmierstil" ab OpenSSL Version 3.0 in Verbindung mit Locks und QUIC-Implementierung zu sein. Nur "400 connections per second on a 48-core machine [..]" statt 140.000 mit OpenSSL 1.1.1 ist in Produktivumgebung schon recht kritisch – zumal der Durchsatz je nach Messung ab 30/40 Threads sichtbar nicht mehr nach oben skaliert.
Anzeige
Tom hat darauf mit dem folgenden Kommentar geantwortet: Ich (persönlich) bin hier auf dem 3.0-LTS-Zweig und werde nach Auslaufen im September 2026 auf den 3.5-LTS-Zweig umsteigen – benutze OPENSSL aber nur "ab und zu" und zu weniger rechenintensiven Aufgaben.
Danke für die Hinweise.
Anzeige
"Performance-Probleme bei OpenSSL >= Version 3"
"Es scheint bei OpenSSL ab Version 3 zu Leistungsproblemen zu kommen"
"Ursache scheint der "Programmierstil" ab OpenSSL Version 3.0"
vs
"Tenor: 10-90% Performance Drop bei Einsatz von OpenSSL 3.0 bis 3.3 oder 3.4"
"dem 3.0-LTS-Zweig und werde nach Auslaufen im September 2026 auf den 3.5-LTS"
hmmm ist 3.5 denn jetzt auch betroffen oder nicht?
ich finde diese Aussagen etwas widersprüchlich
Der Ursprung der Meldung ist wohl die Leistungsbewertung von HAProxy, die das ganze mal bewertet und mit anderen SSL Libs verglichen hat:
https://www.haproxy.com/blog/state-of-ssl-stacks
Die haben wohl z.T. essentielle API umgeschrieben / rausgenommen was bei vielen Lösungen zu Problemen führt und diese deshalb nach wie vor nicht auf der aktuellsten Version laufen. Ebenso werden dort auch passende Alternativen genannt die auch deutich performanter laufen.
FYI: Fefe hat auch was dazu:
https://blog.fefe.de/?ts=96de4f71
Die Schere geht erst weit über 10000 Verbindungen pro SEKUNDE auf. Das dürfte außer Firmen niemanden groß interessieren. Auch CPUs mit 90 Cores sind für Privatpersonen nicht erschwinglich.
Und Experten bekommen es gerade noch so hin ihre nginx-Instanz gegen BoringSSL oder AWS-LC at compile time zu linken. Selbst der Drei-Zeiler für Python war trivial.
Und OpenSSL 1.1.1w ist nach wie vor sicher und hat TLS1.3. Ich bin den Artikel von den Profis in der Primärquelle die Tage mehrmals durch und es ist wirklich nur relevant, wenn man Millionen von Nutzern hat. Gebt den OpenSSL-Jungs mal mehr Zeit, ist immer unverschämt, wie gratis FLOSS-Projekte "zu langsam" sind aber keiner Zahlt die Devs.
Bug bounty und PRs von Firmen die das Problem lösen wollen? Null.
Ich sitze das aus, in schon 1-2 Jahren wird der Bottlneck weg sein. Spätestens, wenn eine faule Firma ein Pullrequest versucht.
Die Versionen 1.0.2 und 1.1.1 haben das Ende ihres öffentlichen Supports erreicht und werden nur noch im erweiterten "Premium-Support" angeboten!
UMSONST gibt es unterstützt nur noch die Versionen ab 3.0 aufwärts.
Ist mir alles bekannt. Das ist ja wohl das Problem der Firmen und derer Umsonst-Mentalität.
Ziemlicher Blödsinn den du hier schreibst. Openssl hat 8 bezahlte Entwickler. Sie haben sich auch dazu entschieden eine eigene QUIC API zu schreiben anstatt die von BoringSSL zu übernehmen die übrigens auch in allen anderen libs implementiert ist.
Empfehle dir mal den Blog-Post von HA-Proxy zu lesen bevor du dir hier irgendwas zusammenreimst.