Open-Source-Testsuite TLS-Anvil: Auf der Jagd nach Sicherheitslücken in TLS-Bibliotheken

Transport-Layer-Security (TLS) ist mit Abstand die wichtigste kryptografische Sicherheitskomponente in der digitalen Kommunikation: Neben dem bekannten Einsatz in HTTPS wird TLS auch in vielen anderen Protokollen wie beispielsweise SMTPS, POP3S oder FTPS genutzt. Zudem setzen mobile Apps TLS als Baustein ein, um Software-Updates abzusichern und Daten vertraulich und vor Manipulation geschützt zu übertragen. Die Sicherheit von TLS als Komponente muss daher für alle möglichen Einsatzgebiete gewährleistet sein. Ohne die Sicherheitsgarantien, die diese Komponente bietet, können Angreifer sensible Daten abfangen oder Schadsoftware in die Datenübertragung einschleusen. Dabei ist die Aufgabe, welche die TLS-Bibliothek übernehmen muss, nicht einfach. Das Ökosystem, in dem eine TLS-Bibliothek agieren muss, ist hochkomplex und in einem ständigen Wandel.

Neue Standards, beispielsweise TLS 1.3 oder DTLS, müssen integriert werden, während auch ältere Standards weiterhin unterstützt werden müssen. Zudem ist die eingesetzte Kryptografie hochsensibel gegenüber Implementierungsfehlern und immer ausgefeilteren Seitenkanalangriffen. Hierdurch können auch schon kleine Fehler in der Implementierung zu einem vollständigen Verlust der Sicherheitseigenschaften führen.

Die Komplexität von TLS und Datagram Transport Layer Security (DTLS), aber auch die ständige (Weiter-) Entwicklung von neuartigen Angriffen, machen es den Entwicklern sehr schwer, alle Schwachstellen für Angriffe schon während der Implementierung zu beseitigen. Sie benötigen daher Werkzeuge, mit denen sie die TLS-Bibliotheken auf Fehler testen können. Dieses Testen gestaltet sich in der Praxis allerdings äußerst schwierig: Während funktionale Basistests (das heißt Tests, die überprüfen, ob TLS im normalen Betrieb funktioniert) relativ einfach zu implementieren sind, gibt es für andere Bereiche des Testens noch keine befriedigenden Lösungen.

Forscherinnen und Forscher des Projekts KoTeBi („Kombinatorisches Testen von TLS-Bibliotheken“) haben nun eine TLS-Testsuite entwickelt, die helfen soll, diese Probleme zu beseitigen. Sie soll zukünftig vollautomatisch und umfassend die Entwicklung und den Einsatz von TLS-Bibliotheken überwachen und analysieren können.

Wie funktioniert TLS?

Das TLS-Protokoll ermöglicht es zwei Endpunkten, einen sicheren Kommunikationskanal aufzubauen. Zu diesem Zweck führen die Kommunikationspartner einen TLS-Handshake durch. Ein beispielhafter TLS-Handshake ist in Abbildung 1 dargestellt.

Der Client und der Server senden dabei verschiedene Handshake-Nachrichten, um kryptografische Parameter auszuhandeln und TLS-Sitzungsschlüssel abzuleiten. Die wichtigsten Nachrichten sind dabei das ClientHello und das ServerHello. Im ClientHello teilt der Client mit, welche Funktionen, Protokolle und Algorithmen er unterstützt. Im ServerHello wählt der Server anschließend aus, was genau davon benutzt werden soll. Die ausgehandelten Parameter und Schlüssel werden dann innerhalb des Kanals verwendet, um die Vertraulichkeit, Integrität und Authentizität der ausgetauschten
Nachrichten (AppData) zu schützen.

Ein TLS-Handshake enthält zahlreiche kryptografische Parameter und kann durch optionale Erweiterungen, sogenannte TLS-Extensions, ergänzt werden. Handshakes unterscheiden sich außerdem abhängig von der TLS-Version. Die derzeit aktuellen TLS-Versionen sind TLS 1.2 und TLS 1.3. Ein Parameter, der ausgehandelt wird, ist die Cipher-Suite. Sie legt die Algorithmen für den Schlüsselaustausch, die Authentifizierung, die Verschlüsselung sowie einen zu verwendenden Hash-Algorithmus fest. Eine Cipher-Suite für TLS 1.3 könnte zum Beispiel so aussehen: TLS_AES_128_GCM_SHA256.

TLS-Extensions werden im Handshake mit ausgehandelt und können Veränderungen des Handshake-Ablaufes bewirken. Beispielsweise können sie verändern, wie Nachrichten authentifiziert werden (zum Beispiel „Encrypt-Than-Mac“), welche zusätzlichen Nachrichten geschickt werden (zum Beispiel „Heartbeat“) und vieles mehr. Insgesamt ist die Anzahl der veränderbaren Parameter in einem TLS-Handshake sehr groß, was zu Problemen beim Testen führen kann, wie wir später noch zeigen.

Wie ist TLS spezifiziert?

TLS ist in mehreren Dokumenten, sogenannten Requests for Comments (RFCs), spezifiziert. Da TLS iterativ gewachsen ist, alte Dokumente durch neue ergänzt oder invalidiert wurden und es viele verschiedene Versionen und Erweiterungen gibt, ist die Anzahl der TLS-spezifischen RFCs sehr groß (siehe Abbildung 2).

Die vielen Protokollversionen, Erweiterungen und kryptografischen Algorithmen erhöhen die Komplexität von TLS und machen die Implementierung einer sicheren TLS-Bibliothek sehr schwierig. Aus Gründen der Abwärtskompatibilität müssen Standard-TLS-Bibliotheken mehrere TLS-Versionen ab TLS 1.0 und auch veraltete kryptografische Algorithmen wie 3DES unterstützen. Die Komplexität von TLS und die Anforderungen an die Abwärtskompatibilität haben in der Vergangenheit zu mehreren kritischen Angriffen geführt, beispielsweise POODLE oder ROBOT.

Den Vorgaben in den RFCs zu folgen, ist also von großer Bedeutung für die Sicherheit der Implementierung. Ein Beispiel für so eine sicherheitsrelevante Anforderung aus RFC 5246 ist die folgende: The receiver MUST check this padding and MUST use the bad_record_mac alert to indicate padding errors. Die Vorgabe ist eine Gegenmaßnahme gegen sogenannte „Padding Oracle“-Angriffe und muss von der Implementierung unabhängig von anderen gewählten Parametern erfüllt werden, um die Sicherheit der Verbindung sicherzustellen.

Parameter und Sicherheitsverhalten

Während frühere Versionen von TLS noch die wichtigsten kryptografischen Parameter ausschließlich über die Cipher-Suite ausgehandelt haben, gibt es inzwischen eine Reihe weiterer Mechanismen, um der gewachsenen Zahl von kryptografischen Primitiven gerecht zu werden. Beispielsweise kann über die Cipher-Suite zu-nächst der Schlüsselaustausch über elliptische Kurven vereinbart werden. Die Auswahl der konkreten elliptischen Kurve, eine zentrale Säule der Sicherheit des aufzubauenden Kanals, erfolgt dann zusätzlich über die „Supported Groups“- Extension.

Außerdem definiert die Cipher-Suite zwar einen Schlüsseltyp für die Authentifizierung, lässt Details dazu, wie etwa die Frage nach der verwendeten Hashfunktion, aber offen. Auch hier erfolgt das Aushandeln über eine TLS-Extension. Bei der Interaktion von diesen drei beispielhaften Parametern gilt es zunächst zu beachten, dass jeder einzelne das Sicherheitsniveau der aufgebauten TLS-Verbindung beeinflussen kann. Beispielsweise kann der Sicherheitseffekt einer starken elliptischen Kurve durch die Wahl einer schwachen Hashfunktion für die Signatur negiert werden. Zudem gibt es für jeden der drei Parameter Auswahlmöglichkeiten, die die zulässigen Optionen für die jeweils beiden anderen einschränken.

In der Vergangenheit haben invalide Kombinationen von Parametern immer wieder Ausnahmefälle in Bibliotheken ausgelöst, durch die Sicherheitsüberprüfungen umgangen werden konnten. Sicherheitstests sollten daher Parameter nicht isoliert betrachten, sondern ein besonderes Augenmerk auf die Interaktion von Parametern untereinander legen.

Kombinatorisches Testen

Die Komplexität von Schwachstellen in Softwaresystemen kann stark variieren. Um manche Schwachstellen zu finden, reicht es aus, einfache Softwaretests zu implementieren, da die Schwachstellen unabhängig von weiteren Parametern auftreten. Andere komplexe Schwachstellen treten nur auf, wenn eine bestimmte Kombination von Parametern zum Einsatz kommt. Um diese Art von Fehlern zu finden, sollten Tests parametrisiert werden, wobei die gleichen Tests mit unterschiedlichen Parametern durchgeführt werden. Mit zunehmender Anzahl von Parametern kann es jedoch zu einer
kombinatorischen Explosion kommen, wodurch nicht mehr alle möglichen Kombinationen getestet werden können.

Beispielsweise kann ein Test mit zehn Parametern, bei dem jeder Parameter zehn unterschiedliche Werte haben kann, zu 10.000.000.000 Parameterkombinationen führen, was die Testausführung unpraktikabel macht. Es ist zudem unwahrscheinlich, dass alle zehn Parameter einen bestimmten Wert annehmen müssen, damit eine Schwachstelle auftritt. Wahrscheinlicher ist, dass lediglich eine
Untermenge der zu testenden Parameter einen bestimmten Wert annehmen muss, damit die Schwachstelle auftritt.

Hier setzt das kombinatorische Testen an, das in Abbildung 3 dargestellt ist. Dabei wird eine Teststärke k (im Beispiel 2) definiert, um dann gezielt alle Kombinationen zu testen, welche aus insgesamt k Parametern bestehen. Dabei wird versucht, die Parameter so auszuwählen, dass möglichst wenige Tests ausgeführt werden müssen, um alle Kombinationen der Teilmenge zu prüfen.

Design einer Testsuite

Im Forschungsprojekt KoTeBi wurde nun eine Testsuite namens „TLS-Anvil“ entwickelt, die durch kombinatorisches Testen Fehler in TLS-Bibliotheken finden soll. Die Testsuite baut auf dem TLS-Analyse-Werkzeug „TLS-Attacker“ auf, das seit 2015 gemeinsam von der Ruhr-Universität Bochum, der Universität Paderborn, dem Technology Innovation Institute (TII, Abu Dhabi) und der Hackmanit GmbH entwickelt wird, um damit TLS-Bibliotheken auf Schwachstellen zu untersuchen. TLS-Attacker enthält eine eigens zur Analyse von TLS-Bibliotheken entwickelte TLS-Implementierung, die Sicherheitsanalysten einfachen Zugriff auf alle Aspekte einer TLS-Verbindung gibt.

Die Tests selbst sind als sogenannte Test-Templates definiert. Dabei handelt es sich um eine Vorlage, die auf einer Anforderung an die zu testende Software basiert. Test-Templates legen fest, welche TLS-Nachrichten gesendet werden und welche Antworten von der Testsuite erwartet werden. Außerdem definieren sie, wann ein Testfall erfolgreich ist oder fehlschlägt.

In TLS-Anvil sind verschiedene Test-Templates implementiert, die hauptsächlich auf den Anforderungen aus 13 unterschiedlichen TLS-RFCs basieren. Der Fokus lag dabei auf Anforderungen, die in den RFCs durch die Schlüsselwörter „MUST“, „SHALL“ und „REQUIRED“ sowie „MUST NOT“ und „SHALL NOT“ als besonders wichtig gekennzeichnet sind. Weiterhin wurden Tests zu impliziten Anforderungen entwickelt, die zwar aus dem Kontext des RFCs hervorgehen, jedoch nicht explizit genannt werden. Hinzu kommen Tests zur Einhaltung der im RFC definierten State Machines und zur Vermeidung von aus der Literatur bekannten Fehlern.

TLS-Anvil geht bei einer Testausführung in drei Phasen vor:

1. Feature Extraction: In dieser Phase wird die zu untersuchende Software zunächst auf ihre Funktionalität gescannt. Dazu zählen unter anderem die unterstützten Cipher-Suites und TLS-Versionen. Nach der Feature Extraction können Tests ausgeschlossen werden, die Funktionen erfordern, die von der Software nicht unterstützt werden.
2. Test-Phase: Im nächsten Schritt werden hintereinander alle Tests mithilfe von TLS-Attacker ausgeführt. Dabei wird jedes Test-Template nach dem Prinzip des kombinatorischen Testens mehrmals mit unterschiedlichen Parametern gestartet. Bei einem Test werden ein oder mehrere Handshakes mit der zu testenden Software durchgeführt und die Antworten gespeichert.
3. Testauswertung: Im letzten Schritt wird ausgewertet, inwieweit die geprüfte Software die Tests bestanden hat. Dabei werden die Ergebnisse für jedes Test-Template in vier Kategorien unterteilt: erfolgreich bestanden, konzeptuell bestanden, teilweise fehlgeschlagen oder komplett fehlgeschlagen. Eine Auswertung kann anschließend durch Einsicht in den generierten Report erfolgen.

TLS-Anvil ist damit viel mehr als nur ein einfacher Scanner. Die Testsuite kann Implementierungsfehler und Interoperabilitätsprobleme aufdecken. Dabei geht sie systematisch vor und kombiniert verschiedene Parameter, um eine möglichst hohe Codeabdeckung zu erhalten.

Die Tests basieren auf den Anforderungen aus den TLS-Standards und decken somit die wichtigsten Fälle ab. Durch ein visuelles Interface können die Testreports ausgewertet werden (siehe Abbildung 4). Dabei geben verschiedene Filter und Werkzeuge die Möglichkeit, gefundenen Fehlern auf den Grund zu gehen. Die
Software dient als hilfreiches Tool für Sicherheitsforscher, Prüfstellen sowie TLS-Hersteller.

Fehler vor der Veröffentlichung beseitigen

Um zu vermeiden, dass sicherheitskritische Fehler in Software vorkommen, welche bereits in Geräten und Produkten zum Einsatz kommt, setzt TLS-Anvil auf den Ansatz des Continuous Testings. Das bedeutet, dass die Testsuite bereits während der Entwicklung als Teil des Produktions-und Updatezyklus eingesetzt werden kann.

Dieser Schritt ist sowohl für TLS-Entwickler als auch Produkthersteller relevant. Sie können während der Entwicklung mithilfe der Testsuite gezielt nach Problemen in ihrer Implementierung suchen. Die Tests können als Systemintegrationstest verwendet werden. Somit sparen die Hersteller Ressourcen, die für die Entwicklung solcher aufwendigen Tests aufgewendet werden müssten.

Gleichzeitig können sich die Hersteller sicher sein, dass sie die komplexen TLS-Standards richtig verstanden und implementiert haben und somit die Konformität zum Standard einhalten. Dies sorgt für eine bessere Effizienz und eine geringere Fehlerquote in der Entwicklung.

In der Praxis sieht das Verfahren wie folgt aus: Ein Code-Update einer TLS-Bibliothek oder eines Produktes, das TLS nutzt, wird gepusht. Dieser Vorgang löst die Continuous-Integration-(CI)-Pipeline des Projektes aus – ein Development Build wird erstellt. Als nächstes wird TLS-Anvil gestartet und führt automatisiert Tests auf dem Development Build aus. Es wird ein Testreport generiert. Wurden Implementierungsfehler gefunden, blockiert dies den Release-Zyklus und der fehlerhafte Code kann nicht im finalen Produkt landen, bevor er behoben wurde (siehe auch Abbildung 5).

Wie sicher TLS-Bibliotheken?

In einer ersten Evaluierung des kombinatorischen Testansatzes für RFC-Anforderungen konnte TLS-Anvil bereits erfolgreich eingesetzt werden, wie M. Maehren et al. in ihrer Veröffentlichung „TLS-Anvil: Adapting Combinatorial Testing for TLS Libraries” auf der USENIX Security 2022 demonstrierten. Die automatisierte Analyse von 13 bekannten Open-Source-TLS-Bibliotheken ergab neben einer Vielzahl unkritischer Abweichungen vom Standard auch Interoperabilitätsprobleme und Sicherheitslücken.

Für die kommerziell eingesetzte Bibliothek MatrixSSL konnte beispielsweise gezeigt werden, dass für bestimmte Cipher-Suites eine Padding-Oracle-Schwachstelle ausgenutzt werden kann, um die Vertraulichkeit der TLS-Verbindung zu brechen. Außerdem konnten durch manipulierte Längenfelder einzelner Nachrichten Parsingfehler ausgelöst werden, die die CPU-Auslastung deutlich erhöhten und so für Denial-of-Service-Angriffe ausgenutzt werden könnten.

Die Evaluierung bestätigte außerdem, dass es gerade für TLS sinnvoll ist, Tests aus den Standards abzuleiten, da diese insbesondere für die neueste Version (TLS 1.3) die Erfahrungen aus Implementierungsfehlern der Vergangenheit widerspiegeln.

So wurde bei der Bibliothek wolfSSL festgestellt, dass durch das Versenden invalider Zertifikatsnachrichten die Authentifikation des Servers vollständig umgangen werden kann. Dadurch wären Verbindungen eines Clients anfällig für Man-in-the-Middle-Angriffe, die alle Sicherheitsziele von TLS brechen. Der RFC enthält genau für diesen Fehlerfall eine Anforderung, die die Detektion solcher invaliden Nachrichten sicherstellen soll.

Diese gravierende Sicherheitslücke hätte daher durch RFC-basierte Tests, wie sie in TLS-Anvil implementiert sind, vor der Veröffentlichung der Bibliothek festgestellt werden können. Als eines von 15 diagnostizierten Interoperabilitätsproblemen hat sich gezeigt, dass MatrixSSL bei bestimmten Kombinationen aus Cipher-Suite und elliptischen Kurven falsche kryptografische Parameter in TLS-1.3-Verbindungen eingesetzt hat. Für einen Kommunikationspartner wäre dieses Fehlverhalten nicht von einem Angriff auf die Verbindung zu unterscheiden, sodass die Verbindung sofort terminiert werden müsste.

Die Zukunft von TLS-Testing

TLS ist inzwischen als Standard für Verschlüsselung im Internet nicht mehr wegzudenken. Viele Entwickler und Produkthersteller verlassen sich dabei auf TLS-Bibliotheken, welche die Verschlüsselung für sie übernehmen. Forschungsergebnisse zeigen jedoch immer wieder, dass es bei der Entwicklung solcher Bibliotheken zu Fehlern kommen kann. Auch bei der Implementierung können Fehlkonfigurationen zu Sicherheitsrisiken führen.

Diese Fehler zu erkennen war bisher schwer. Doch mit modernen Testansätzen wie dem kombinatorischen Testen können automatisiert sicherheitskritische Fehler erkannt werden. Das Projekt KoTeBi hat eine Open-Source-Testsuite erarbeitet, die bereits unter Beweis gestellt hat, dass sie einen großen Beitrag zur Erhöhung der Sicherheit von TLS-Bibliotheken leisten kann.

TLS-Entwickler haben nun die Möglichkeit, solche Werkzeuge zu nutzen und sie in ihren Produktlebenszyklus einzubauen. Dadurch werden Schwachstellen und Kompatibilitätsprobleme schon vor der Veröffentlichung aufgedeckt. Die Entwicklung der Testsuite des Projekts KoTeBi geht stetig voran – alle interessierten Personen und Unternehmen können TLS-Anvil allerdings bereits verwenden: www.kotebi.de.