TLS-Libraries im Vergleich: Analyse mit TLS-Anvil

Mit TLS-Anvil wird die Konformitätsprüfung von TLS-Bibliotheken einfacher, nachvollziehbarer und effizienter.

Um die neue Version unseres TLS-Testframeworks TLS-Anvil vorzustellen, haben wir die Demo-Implementierungen von acht verschiedenen TLS-Bibliotheken auf ihre Konformität mit den Anforderungen aus relevanten RFCs analysiert. Die Ergebnisse zeigen, dass TLS-Anvil zuverlässig erkennen kann, welche Unterschiede die Bibliotheken in den Punkten Funktionsumfang und Verhalten in Grenzfällen haben, worduch die Konformitätsprüfung vereinfacht wird.

Einleitung

TLS ist aktuell das wichtigste kryptografische Protokoll zur Sicherung von Verbindungen. Es schützt die Kommunikation zu Servern sowohl für Privatpersonen die im Internet surfen als auch für Unternehmen welche selnsible Daten austauschen. TLS ist nicht zuletzt so weit verbreitet, da es so eine große Flexibilität bietet. Je nach individuellen Anforderungen kann TLS mit einer Vielzahl unterschiedlicher Verschlüsselungs-, Authentifizierungs- und Hash-Algorithmen konfiguriert werden. Zusätzliche Funktionen bieten optionale Erweiterungen die das Basisprotokoll ergänzen. Systemadministratoren und Produktentwickler müssen nicht nur entscheiden, welche TLS-Bibliothek sie verwenden möchten, sondern auch, wie sie diese richtig konfigurieren, um ihren Anforderungen an Leistung, Kompatibilität und Sicherheit gerecht zu werden.

Kryptografische Standards entwickeln sich mit dem Fortschritt der Forschung und der zunehmenden Effizienz von Computern weiter. Algorithmen oder Verfahren, die einst als sicher galten, können mit der Zeit aufgrund von Durchbrüchen in der Kryptoanalyse oder durch immer effizientere Brute-Force-Angriffe anfällig für Schwachstellen werden. Aus diesem Grund veröffentlichen nationale Behörden wie das BSI (Bundesamt für Sicherheit in der Informationstechnik) und das NIST (National Institute of Standards and Technology) regelmäßig Leitlinien zum korrekten Einsatz bewährter Verfahren.

Unterschiedliche TLS-Bibliotheken haben unterschiedliche Anforderungen und Ziele für ihre Software. So konzentrieren sich einige auf einen möglichst großen Funktionsumfangs und andere auf möglichst effiziente Handshakes. Alle Implementierungen müssen jedoch den komplexen Anforderungen von TLS entsprechen, um sicherzustellen, dass keine Sicherheits- oder Kompatibilitätsprobleme auftreten. Diese Anforderungen erstrecken sich wiederum über zahlreiche Dokumente (RFCs). Im Vergleich von TLS-Bilbliotheken gibt es bereits gute Analysen, welche sich auf Leistungsunterschiede konzentrieren. Wir stützen unseren Vergleich auf die Ergebnisse von TLS-Anvil, welches die Konformität mit verschiedenen RFC-Standards misst, mit dem Hauptziel der Sicherheit.

Das TLS-Test Framework

TLS-Anvil ist ein automatisiertes Testframework, das entwickelt wurde, um die Robustheit, Korrektheit und Standardkonformität von TLS-Implementierungen zu bewerten. TLS-Anvil basiert auf dem TLS-Attacker-Framework und ermöglicht hochgradig konfigurierbare Testszenarien. Neben der Überprüfung, ob eine TLS-Implementierung den RFCs entspricht, bewertet TLS-Anvil auch, ob eine Bibliothek mit Sicherheitsrichtlinien wie BSI TR-02102-2 und NIST SP 800-52r2 übereinstimmt.

Eine wesentliche Stärke von TLS-Anvil ist die Verwendung von kombinatorischen Tests, bei denen durch Variation von Protokollparametern, Nachrichtensequenzen und Erweiterungen systematisch eine große Anzahl von Testfällen generiert und ausgeführt wird. Dieser Ansatz deckt subtile Fehler und Inkonsistenzen auf, die möglicherweise nur in bestimmten, nicht offensichtlichen Konfigurationen auftreten. TLS-Anvil beinhaltet eine umfassende Testsuite, wobei jeder Test auf einen bestimmten Aspekt einer TLS-Implementierung abzielt, wie z. B. ihre Robustheit bei unerwarteten Eingaben, die Einhaltung der RFC-Anforderungen oder das korrekte Protokollverhalten. Jeder Test führt mehrere Handshakes mit unterschiedlichen Parameterkombinationen durch und liefert so tiefe und differenzierte Einblicke in die Art und Weise, wie eine Implementierung mit dem Protokoll umgeht.

Ausgewählte TLS-Bibliotheken und Testmethodik

Für unsere Bewertung haben wir eine Reihe von TLS-Bibliotheken ausgewählt, darunter die am häufigsten verwendeten wie OpenSSL, BoringSSL, LibreSSL und WolfSSL sowie Botan, das in eingebetteten Systemen beliebt ist. Wir haben auch die weniger häufig verwendeten Bibliotheken MBedTLS und OpenHiTLS einbezogen. Für jede Bibliothek haben wir die zum Zeitpunkt des Tests (Juni 2025) aktuellste Version bewertet (siehe Tab. 1).

Um die Konsistenz zwischen den Testumgebungen sicherzustellen, wurde jedes zu testende System (SUT) mit der  TLS-Docker-Library eingerichtet, einer Docker-basierten Sammlung, die die integrierten Testserver und Testclients verschiedener TLS-Bibliotheken bereitstellt. Diese Konfiguration gewährleistet Reproduzierbarkeit und isoliert die Tests von systemspezifischen Variablen.

TLS-Anvil ermöglicht die Festlegung der Stärke der kombinatorischen Abdeckung. Für diese Analyse wurde die Stärke auf 1 gesetzt. Alle in der Testsuite verfügbaren Tests wurden aktiviert, wobei nicht jede Implementierung alle Funktionen unterstützten, was zu einer unterschiedlichen Anzahl an Tests pro Bibliothek führte.

Nach der Ausführung erstellt TLS-Anvil detaillierte Berichte für jeden Test. Diese Berichte enthalten:

• • Eine Zusammenfassung mit allen ausgeführten Testfällen im JSON-Format
  • Die spezifischen Parameterkombinationen, die in jedem Testlauf verwendet wurden
  • Die Ergebnisse jedes Tests
  • Eine vollständige Netzwerk-Trace (PCAP) für jeden Testfall

Diese detaillierten Logs bilden die Grundlage unserer Bewertung und ermöglichen es uns, Funktionslücken, nicht konformes Verhalten und Fehler in Randfällen zu identifizieren. Zur Visualisierung kann Anvil-Web verwendet werden, das eine Webschnittstelle zum Parsen der JSON-Datei und zur übersichtlichen Darstellung der Ergebnisse bietet.

Unsere Analyse beschränkt sich auf die in jeder Bibliothek enthaltenen integrierten Testserver und -clients. Viele davon ignorieren zusätzliche Nachrichten nach der ersten Finished Nachricht was zu False-Positives bei Tests führen kann, die das Verhalten nach dem Handshake bewerten (z. B. KeyUpdate).

Ergebnisse des Serververgleichs

Unsere Tests der Server-Implementierungen zeigen mehrere wiederkehrende Muster in der Art und Weise, wie verschiedene Bibliotheken mit Protokoll-Randfällen umgehen, sowie einige sicherheitsrelevante Schwachstellen. Die Gesamtzahl der fehlgeschlagenen Tests für die verschiedenen Bibliotheken ist in Abb. 1 dargestellt.

Fehlgeschlagene TLS-Anvil-Tests der Server-Implementierungen (Abbildung 1)

Ergebnisse hinsichtlich Compliance und Interoperabilität

Bei fast allen getesteten TLS-Servern schlugen bestimmte Testkategorien durchweg fehl, wobei einige davon technisch gesehen einen Verstoß gegen Standards darstellen, jedoch nicht direkt ausnutzbar sind:

Feature Gaps und inkorrektes Advertisement. 
Einige Server unterstützen bestimmte Teile des Protokolls nicht, die gemäß dem Standard vorgeschrieben sind oder die vom Server zuvor als unterstützt angegeben wurden. WolfSSL und LibreSSL können keine großen Listen von Signatur- und Hash-Algorithmen verarbeiten. OpenHiTLS gab fälschlicherweise die Unterstützung für die SECP256R1-Gruppe an. Einige Server (WolfSSL, MBedTLS) verarbeiten FFDHE-Gruppen falsch.

Toleranz gegenüber nicht-standardkonformen Cleintverhalten. 
Viele Bibliotheken setzten den Handshake fort oder behielten eine Sitzung trotz Protokollverstößen bei, anstatt sie abzubrechen. Beispiele hierfür sind die Tolerierung inzwischen verbotener Erweiterungen wie die Komprimierte Darstellung von epileptischen Kurven (OpenSSL, WolfSSL, MBedTLS) oder leere Handshake- und Alert-Nachrichten in TLS 1.3 (BoringSSL, Botan).

Unvollständiger Verbindungsabschluss.
Mehrere Bibliotheken senden vor dem Schließen der Verbindung keinen close_notify Alert (OpenSSL, BoringSSL, LibreSSL) oder ignorieren Alerts, anstatt die Sitzung zu beenden (WolfSSL, MBedTLS).

Nichtdurchsetzung von Beschränkungen für Protokollversionen und -erweiterungen. 
Gemäß dem Standard müssen bestimmte Kombinationen von Erweiterungen, Parametern und Protokollversionen abgelehnt werden. Mehrere Server akzeptierten Erweiterungen und Parameter, die in den spezifischen Protokollversionen eigentlich verboten sein sollten. Botan akzeptiert TLS 1.2 Brainpool-Kurven in TLS 1.3, OpenSSL 1.1.1w akzeptiert PSK ohne psk_key_exchange_modes.

Ignorieren oder unvollständige Verarbeitung von KeyUpdates. 
In fast allen Implementierungen wurden KeyUpdate Nachrichten entweder vollständig ignoriert oder verarbeitet ohne die Schlüssel zu aktualisieren (Botan, OpenSSL, BoringSSL, MBedTLS, WolfSSL, OpenHiTLS). Dies liegt wie oben beschrieben wahrscheinlich an der Verwendung der Demo-Implementierungen.

Nicht-standardkonforme Verarbeitung von Record-Grenzen und Längenfeldern.
Einige Server (MBedTLS, WolfSSL) brechen den Handshake bei Record overflows oder geänderten Längenfeldern nicht ab. 

Potenziell sicherheitsrelevante Findings

Während viele Probleme geringfügige Interoperabilitäts- oder Konformitätsprobleme waren, fallen einige als potenziell sicherheitsrelevant besonders auf:

Akzenptieren schwacher oder veraltete Algorithmen. 
WolfSSL akzeptiert die SECP224R1 (P-224)-Kurve, die nur eine Sicherheit von 112 Bit bietet und damit unter dem empfohlenen Minimum von 128 Bit liegt. Obwohl derzeit keine praktischen Angriffe auf diese Kurve bekannt sind, ist sie in TLS 1.3 veraltet und aufgrund der geringeren Sicherheit eine schlechte Wahl für langfristige kryptografische Sicherheit. WolfSSL akzeptiert auch RSA mit SHA-224, was selten und schwächer als SHA-256 ist. Obwohl es sich um eine verkürzte Variante von SHA-256 handelt und nicht grundlegend falsch ist, bietet es ein geringeres Sicherheitsniveau und wird in aktuellen kryptografischen Standards selten verwendet oder empfohlen. LibreSSL unterstützt weiterhin RC4-Verschlüsselung, welche als unsicher gilt und in keiner modernen TLS-Implementierung verwendet werden sollten.

Keine Ablehnung von ungültigen öffentlichen Schlüsseln. 
WolfSSL akzeptiert auch Punkte, die nicht auf der elliptischen Kurve (EC) liegen. LibreSSL ignoriert unzulässige EC-Punkte z.B. den Null-Schlüssel für die X25519- und X448-Kurve in TLS 1.3. Dieses Problem sollte vorsichtshalber behoben werden.

Ergebnisse des Clientvergleichs

Die TLS-Anvil-Tests der Client-Implementierungen ergaben eine Reihe von Abweichungen von der Konformität, wobei sich einige Ergebnisse über mehrere Bibliotheken hinweg überschnitten. Die Gesamtzahl der fehlgeschlagenen Tests für die verschiedenen Bibliotheken ist in Abb. 2 dargestellt.

Fehlgeschlagene TLS-Anvil-Tests der Client-Implementierungen (Abbildung 2)

Ergebnisse hinsichtlich Compliance und Interoperabilität

Bestimmte Testkategorien schlugen bei mehreren getesteten TLS-Clients durchweg fehl. Obwohl die meisten davon einen Verstoß gegen Standards darstellen, können sie nicht direkt ausgenutzt werden:

Feature Gaps und inkorrektes Advertisement. 
Einige Clients unterstützen bestimmte Teile des Protokolls nicht, die gemäß dem Standard vorgeschrieben sind oder die vom Server zuvor als unterstützt angegeben wurden. MBedTLS akzeptiert keine BRAINPOOL-Gruppen. WolfSSL fügt keine Cookies in den ClientHello ein, obwohl dies erwartet wird. Letzteres kann dazu führen, dass der Server die Verbindung zum Schutz vor DoS-Angriffen abbricht.

Toleranz gegenüber nicht-standardkonformen Serververhalten. 
Clients brachen häufig nicht ab, wenn sie Protokollverletzungen oder nicht unterstützte Parameter erhielten. Dazu gehörte das Akzeptieren verbotener oder nicht ausgehandelter Erweiterungen (OpenSSL, LibreSSL, WolfSSL, MBedTLS) und veralteter Kompressionsformate für EC-Punkte (OpenSSL 1.1.1, LibreSSL).

Unvollständiger Verbindungsabschluss. 
Viele Clients haben vor dem Schließen der Verbindung keinen close_notify Alert gesendet (OpenSSL, BoringSSL, LibreSSL, WolfSSL). Einige haben sogar nach fatalen Alerts den Socket offen gelassen (LibreSSL, WolfSSL).

Ignorieren oder unvollständige Verarbeitung von KeyUpdates. 
Ähnlich wie auf der Serverseite ist KeyUpdate bei den meisten Clients schlecht implementiert. Botan, OpenSSL, BoringSSL und WolfSSL ignorieren entweder eingehende KeyUpdate-Nachrichten oder senden selbst keine. Dies liegt wie oben beschrieben wahrscheinlich an der Verwendung der Demo-Implementierungen.

Nicht-standardkonforme Verarbeitung von Record-Grenzen und Längenfeldern. 
Mehrere Clients haben Tests im Zusammenhang mit der Record-Verarbeitung nicht bestanden: Fehlende Unterstützung für Record-Fragmentierung (Botan), Akzeptieren von Record-Overflow (WolfSSL, LibreSSL).

Potenziell sicherheitsrelevante Findings

Während viele Probleme geringfügige Interoperabilitäts- oder Konformitätsprobleme waren, fallen einige als potenziell sicherheitsrelevant besonders auf:

Akzenptieren schwacher oder veraltete Algorithme. 
Mehrere Clients boten kryptografische Algorithmen an, die nicht mehr empfohlen werden. Die elliptische Kurve SECP224R1 wurde in WolfSSL gefunden (112-Bit-Sicherheit, in TLS 1.3 veraltet). SHA-1-basierte Signaturen wurden von BoringSSL und LibreSSL angeboten. RSA mit SHA-224 wird von WolfSSL und OpenSSL angeboten. Diese Algorithmen bieten eine geringere Sicherheit und werden in modernen Implementierungen nicht empfohlen. Eine weitere Unterstützung erhöht das Risiko von Downgrade-Angriffen, wenn sie mit Fehlern bei der Protokollverhandlung kombiniert werden.

Keine Ablehnung von ungültigen öffentlichen Schlüssel.
Wie der Server akzeptiert auch der WolfSSL-Client Punkte, die nicht auf der elliptischen Kurve liegen, was zu den zuvor erwähnten Sicherheitsrisiken im Zusammenhang mit Angriffen durch ungültige Punkte führen kann.

Fazit

Unsere Analyse von TLS-Bibliotheken mit TLS-Anvil zeigt eine Vielzahl von Bereichen auf, in denen sowohl bei Client- als auch bei Server-Implementierungen Verbesserungsbedarf besteht. Die meisten der beobachteten Fehler sind in der Praxis nicht sofort ausnutzbar, aber sie decken Lücken in der Robustheit und eine zu hohe Toleranz gegenüber ungültigen oder nicht konformen Eingaben auf. Insgesamt haben wir einige wiederkehrende Muster beobachtet:

• Standardmäßig tolerant. Die meisten getesteten TLS-Clients bevorzugen Toleranz zu nichtkonformen Verhalten gegenüber einer strikten Durchsetzung des Protokollstandards. Dies verringert zwar Handshake-Fehler mit nicht konformen Servern, kann aber auch die Sicherheitsgarantien schwächen.
  
  
• KeyUpdate wird häufig vernachlässigt. Sowohl Clients als auch Server zeigen eine unvollständige Unterstützung. Dieses Verhalten könnte jedoch auf die genutzten Demo-Clients und Demo-Server beschränkt sein, da diese zusätzliche Nachrichten nach der ersten Finished-Nachricht ignorieren.

• Veraltete Kryptographie. Selbst moderne Bibliotheken lassen in ihrer Standard-Konfiguration veraltete Algorithmen zu, wahrscheinlich aus Gründen der Abwärtskompatibilität.

Praktische Bedeutung integrierter Tests mit TLS-Anvil. 
Unsere Analyse zeigt, dass selbst moderne Bibliotheken noch Verbesserungspotenzial haben und nicht alle Standards vollständig erfüllen. TLS-Anvil ermöglicht das Testen auf Sicherheits-, Interoperabilitäts- und Konformitätsprobleme. Es kann dabei helfen, Probleme zu finden und Produkte und Anwendungen nachweislich sicherer zu machen. TLS-Anvil lässt sich leicht in kontinuierliche automatisierte Testpipelines integrieren, um Sicherheit und Interoperabilität während des gesamten Produktionszyklus aufrechtzuerhalten.

Unsere Experten:innen entwickeln die optimale Lösung für Sie

TLS – CI/CD (Continuous Integration/Continuous Delivery) – Kryptographie

Möchten Sie sicherstellen, dass die Implementierung von TLS in Ihrem Projekt sicher ist?
Oder planen Sie Ihre entwickelte TLS-Bibliothek auf Schwachstellen zu überprüfen?

Wir beraten Sie gerne; kontaktieren Sie uns für eine unverbindliche Erstberatung.
So stehen wir Ihnen mit folgenden Services und Lösungen zur Seite:

IT-Sicherheitsberatung  |  IT-Sicherheitsschulungen   |  Penetrationstests

Zögern Sie nicht und finden Sie mit uns Ihren Weg zur sicheren Entwicklung und Implementierung von TLS.
Wir freuen uns darauf Sie bei Ihren Projekten zu unterstützen.

Ihr Ansprechpartner für Kryptographie und TLS

Prof. Dr. Juraj Somorovsky
juraj.somorovsky@hackmanit.de