Назад к обновлениям
New releaseJul 31, 2026

TLS-Attacker v7.0.0-rtc

Фреймворк на Java для систематического фаззинга и анализа TLS-библиотек. Позволяет произвольное создание и модификацию сообщений протокола, а также тестирование клиентов/серверов TLS на предмет обнаружения уязвимостей.

Поделиться

TLS-Attacker

GitHub release (latest by date) licence Build Status

TLS-Attacker — это Java-фреймворк для анализа TLS-библиотек. Он позволяет отправлять произвольные протокольные сообщения в произвольном порядке TLS-пиру и определять их модификации с помощью предоставляемого интерфейса. Это даёт разработчику возможность легко настроить собственный поток TLS-протокола и протестировать его на своей TLS-библиотеке.

Обратите внимание: TLS-Attacker — это исследовательский инструмент, предназначенный для разработчиков TLS и пентестеров. В нём нет графического интерфейса и индикаторов «зелёный/красный».

Сборка и запуск

Для сборки и использования TLS-Attacker необходимы Java и Maven. В Ubuntu Maven можно установить, выполнив:

$ sudo apt-get install maven

TLS-Attacker в настоящее время требует Java JDK 21 для работы.

Если у вас установлена подходящая версия Java, выполните команду maven из каталога TLS-Attacker:

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

Если вы торопитесь, можно пропустить тесты, используя:

$ mvn clean install -DskipTests=true

Полученные jar-файлы помещаются в папку «apps».

Если вы хотите использовать этот проект в качестве зависимости, вам не нужно компилировать его самостоятельно; вы можете включить его в свой pom.xml следующим образом:

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

TLS-Attacker поставляется с демонстрационными приложениями, которые предоставляют простой доступ к функциональности TLS-Attacker.

Вы можете запустить TLS-Attacker в качестве клиента с помощью следующей команды:

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

или в качестве сервера:

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

Хотя эти примеры приложений сами по себе очень мощные, TLS-Attacker раскрывает свой полный потенциал при использовании в качестве программной библиотеки.

Структура кода

TLS-Attacker состоит из нескольких (maven) проектов:

  • TLS-Client: пример клиентского приложения
  • TLS-Core: стек протоколов и сердце TLS-Attacker
  • TLS-Mitm: прототип для MitM-сценариев
  • TLS-Server: пример серверного приложения
  • TLS-Proxy: использование TLS-Attacker для SSLSockets
  • TraceTool: инспекция и модификация трасс рабочего процесса TLS-Attacker
  • Transport: транспортные утилиты для нижних уровней
  • Utils: набор вспомогательных классов

Дизайн TLS-Attacker

Дополнительную информацию об этих модулях можно найти в Wiki.

Возможности

В настоящее время поддерживаются следующие функции:

  • SSL 3, версии TLS 1.0 (RFC-2246), 1.1 (RFC-4346), 1.2 (RFC-5246) и 1.3 (RFC-8446)
  • SSL 2 (частичная поддержка)
  • Алгоритмы обмена ключами (EC)DH(E), RSA, PSK, SRP, GOST и ANON
  • Шифры CBC, AEAD и потоковые (AES, CAMELLIA, DES, 3DES, IDEA, RC2, ARIA, GOST_28147_CNT_IMIT, RC4, SEED, NULL)
  • ~300 наборов шифров, ~30 расширений
  • Клиент и сервер
  • HTTPS
  • Рабочие процессы с участием более двух сторон
  • Множество расширений
  • Tokenbinding (EC) и Tokenbinding через HTTP
  • Сокеты
  • TLS 1.3 0-RTT
  • STARTTLS
  • ...

Использование

Здесь приведены несколько очень простых примеров использования TLS-Attacker.

Во-первых, вам нужно запустить TLS-сервер (пожалуйста, не используйте публичные серверы). Запустите скрипт keygen.sh, если вы этого ещё не сделали. Например, вы можете использовать тестовый сервер OpenSSL:

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

Эта команда запускает TLS-сервер на порту 4433.

Если вы хотите подключиться к серверу, используйте эту команду:

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

Примечание: Если это рукопожатие завершается неудачей, вероятно, вы не указали конкретный набор шифров. TLS-Attacker не будет полностью соблюдать выбранные сервером наборы шифров.

Вы можете использовать другой набор шифров, версию TLS или подключиться к другому порту с помощью следующих параметров:

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

Если вы более опытный разработчик, вы можете создать собственный поток TLS-сообщений, написав Java-код. Например:

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 использует концепцию WorkflowTrace для определения «потока TLS-сообщений». WorkflowTrace состоит из списка действий, которые затем выполняются одно за другим. Хотя для типичного «потока TLS-сообщений» требуются только SendAction и ReceiveAction, фреймворк не ограничивается этим и реализует множество других действий, которые можно использовать для выполнения ещё более произвольных потоков сообщений. Список реализованных действий с пояснениями можно найти в Wiki.

Мы знаем, что многие из вас ненавидят Java. Поэтому вы также можете использовать XML-структуру и запустить свой настраиваемый TLS-протокол из XML:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowTrace>
    <!-- Отправить ClientHello -->
    <Send>
        <configuredMessages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <EllipticCurves/>
                    <SignatureAndHashAlgorithmsExtension/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ClientHello>
        </configuredMessages>
        <configuredRecords>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Получить ответ сервера -->
    <Receive>
        <expectedMessages>
            <ServerHello>
                <extensions>
                    <ECPointFormat/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ServerHello>
            <Certificate/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    
    <!-- Отправить обмен ключами клиента и Finish -->
    <Send>
        <configuredMessages>
            <RSAClientKeyExchange/>
            <ChangeCipherSpec/>
            <Finished/>
        </configuredMessages>
        <configuredRecords>
            <record/>
            <record/>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Получить Finish сервера -->
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
</workflowTrace>

Если эта XML-структура находится в файле TLS-Attacker/apps/workflow.xml, вам нужно выполнить:

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

Protocol-Attacker / Система уровней

Изначально разработанный для атак на протокол TLS, TLS-Attacker способен поддерживать произвольные протоколы. Для этого TLS-Attacker назначает стек уровней каждому соединению. Этот стек уровней состоит из различных протокольных уровней, которые пользователь хочет использовать. С помощью стека уровней пользователь может добавлять такие уровни, как DTLS или HTTP (ещё находятся в разработке), в произвольном порядке.

Чтобы отправлять и получать произвольные сообщения с помощью стека уровней, пользователь может определить конфигурации для каждого уровня. Эти конфигурации определяют, какие сообщения отправлять или получать. Это также позволяет пользователю указать контейнеры сообщений/данных, специфичные для каждого уровня. Например, можно указать, какие TLS-сообщения и записи должен отправлять TLS-Attacker. TLS-Attacker автоматически инкапсулирует заданные TLS-сообщения в записи.

Модифицируемые переменные

TLS-Attacker использует концепцию модифицируемых переменных (Modifiable Variables) для внесения изменений в предопределённые рабочие процессы во время выполнения. Модифицируемые переменные позволяют задать модификации базовых типов до или после того, как их значения фактически установлены. Когда их фактические значения определены и при попытке доступа к значению через геттеры, исходное значение будет возвращено в модифицированной форме. Более подробно эта концепция описана на https://github.com/tls-attacker/ModifiableVariable.

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

В этом примере мы определили новый ModifiableInteger и установили его значение равным 30. Затем мы определили новую модификацию AddModification, которая просто возвращает сумму двух целых чисел. Мы установили её значение 20. Если выполнить вышеуказанную программу, будет выведено 50.

Конечно, мы можем использовать эту концепцию при построении TLS-рабочих процессов. Представьте, что вы хотите протестировать сервер на уязвимость Heartbleed. Для этого нужно увеличить длину полезной нагрузки в запросе Heartbeat. С TLS-Attacker это можно сделать следующим образом:

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

Как видите, мы явно увеличили длину полезной нагрузки сообщения Heartbeat на 20000. Если запустить атаку против уязвимого сервера (например, OpenSSL 1.0.1f), вы должны увидеть корректный ответ Heartbeat.

Дополнительные примеры атак и более подробные объяснения TLS-Attacker можно найти в wiki.

Расширенные возможности

Некоторые действия требуют контекста или конфигурации для правильного выполнения. Например, если TLS-Attacker пытается отправить сообщение ClientHello, ему необходимо знать, какие значения в него помещать, например, какие наборы шифров или какую версию протокола использовать. TLS-Attacker берёт эту информацию из файла конфигурации (по умолчанию расположен в TLS-Core/src/main/resources/default_config.xml). Значения, определяемые во время выполнения, сохраняются в TlsContext. Когда значение, которое обычно выбирается из контекста, отсутствует (потому что сообщение ещё не получено), выбирается значение по умолчанию из Config. Вы можете указать собственный файл конфигурации из командной строки с помощью параметра «-config». Обратите внимание, что если вы явно не определите значение по умолчанию в файле конфигурации, TLS-Attacker заполнит этот пробел жёстко заданными значениями (которые равны предоставленной конфигурации по умолчанию). Более подробно о настройке TLS-Attacker можно узнать в wiki.

Благодарности

Мы хотим поблагодарить всех, кто внёс вклад в проект TLS-Attacker.

Особая благодарность следующим людям за их заметный вклад:

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

Дальнейшие вклады и pull request'ы приветствуются.

Научные публикации

Основные концепции TLS-Attacker и несколько атак описаны в следующей статье:

Ниже мы перечисляем недавние научные исследования, в которых использовался TLS-Attacker. Полный список можно найти в Wiki

Если у вас есть какие-либо исследовательские идеи или вам нужна поддержка, не стесняйтесь обращаться к нам в Twitter (@ic0nz1 , @jurajsomorovsky , @marcelmaehren , @nerinola1 , @JonSnowWhite2) или на https://www.hackmanit.de/.

Если TLS-Attacker помогает вам найти ошибку в реализации TLS, пожалуйста, упомяните этот инструмент. Спасибо!

Читать далее

Категории

Анализ уязвимостейФаззингСетевая безопасностьКриптографияТестирование на Проникновение