tls-attacker/tls-scannerペネトレーションテスターと研究者向けの自動化されたTLSサーバーおよびクライアント構成スキャナー。暗号スイート、プロトコルバージョン、セキュリティガイドラインを評価し、カスタマイズ可能なスキャン深度と機械可読な出力を提供します。
TLS-Scannerは、ペネトレーションテスターやセキュリティ研究者がTLSサーバーおよびクライアントの設定を評価するのを支援するツールです。
注意: TLS-Scannerは、TLS開発者、ペネトレーションテスター、管理者、研究者を対象とした研究ツールです。GUIはありません。最初のバージョンであり、いくつかのバグが含まれている可能性があります。
TLS-Scannerをコンパイルして使用するには、以下を実行する必要があります:
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
あるいは、急いでいる場合は、以下を使用してテストをスキップできます:
$ mvn clean package -DskipTests=true
TLS-Scannerをライブラリとして使用したい場合は、以下のコマンドでインストールする必要があります:
$ mvn clean install
TLS-Scannerを実行するには、apps/フォルダ内のjarファイルのいずれかを実行する必要があります。 これらは、アプリを自分でコンパイルするか、 GitHubからリリースされたjarファイルをダウンロードすることで入手できます。
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433
TLS-Scannerは指定されたサーバー(ここではポート4433のlocalhost)を評価し、最後にレポートを出力します。
レポートは、検出結果の深刻度を伝えるために色を使用します:
スキャンしたいホストを-connectパラメータで指定する必要があります。
スキャンのパフォーマンスを向上させたい場合は、-threadsパラメータを使用して使用するスレッド数を増やすことができます。
パフォーマンス上の理由からもう1つの重要なパラメータは-scanDetailパラメータで、スキャンの詳細度を設定するために使用できます。高速から非常に詳細までの可能な値は: QUICK、NORMAL、DETAILED、ALLです。
出力の詳細度は-reportDetailパラメータで設定できます。ガイドラインの詳細を確認するには、-reportDetail ALLを使用してください。
デフォルトでは、結果はコンソールにのみ書き込まれます。機械可読な出力が必要な場合は、-outputFile output.jsonを使用して結果をJSONファイルに自動的に書き込むことができます。
変更すべき最も重要なパラメータは-scanDetailと-reportDetailです。以下では、これらのパラメータのいくつかのユースケースについて説明します。
ほとんどの場合、デフォルトのパラメータ設定で十分です。これは、両方の詳細レベルをNORMALに設定してスキャンを実行します。
高速スキャンを実行してシステムの概要をすばやく把握したい場合は、両方の詳細レベルをQUICKに設定することをお勧めします。これにより、一部の実行されるプローブの範囲が制限されて実行時間が短縮され、レポートの詳細度が制限されて非常に詳細で技術的な情報が含まれなくなります。
システムを完全に評価し、当社が持つすべてを実行したい場合は、両方の詳細レベルをALLに設定することをお勧めします。これにより、既存のすべてのプローブが完全に実行され、さらなる分析と評価のために非常に詳細な情報が出力されます。
-scanDetailのようなパラメータを個別に設定する代わりに(またはそれに加えて)、実行するプローブと使用するこれらのパラメータを再利用可能なJSONスキャンプロファイルにまとめることができます。これは-profile <path/to/profile.json>パラメータで指定します。これはTlsServerScannerとTlsClientScannerの両方で利用可能です。
プロファイルは以下の内容を持つJSONファイルです:
inheritedFromProfiles: プローブを結合する他のプロファイルへのパス。これを宣言しているプロファイルファイルのディレクトリを基準に解決されます(絶対パスはそのまま使用されます)。probes: 実行するプローブ。ProbeType enumクラスの完全修飾名から、実行するその定数名のリストへのマップとして指定します。これにより、プローブをタイプごとにグループ化し、プローブごとにタイプを繰り返す必要がなくなります。また、単一のプロファイルで異なるProbeType実装(例: TlsProbeTypeとQuicProbeType)のプローブを自由に組み合わせることもできます。各タイプごとのリストは"*"(そのタイプのすべての定数)と"!CONSTANT_NAME"(以前に名前または"*"で追加された定数を削除)も受け付け、順番に処理されます — 例についてはscan-profiles/内のEverything.jsonとdemo.jsonを参照してください。settings (オプション): -scanDetail、-reportDetail、-postAnalysisDetail、-noColor、-outputFile、-probeTimeout、-parallelProbes、-threadsなどのパラメータのオーバーライド。省略されたフィールドは通常のデフォルト値(またはコマンドラインで渡された値)を保持します。probesとは異なり、settingsは継承されません — -profileで指定したプロファイルに直接宣言された設定のみが適用されます。たとえ他のプロファイルからプローブを継承していても同様です。アクティブなプロファイル(およびそれが継承するすべて)から解決されたプローブのみが実行され、それ以外はすべてスキップされます。
例: ベースプロファイルのプローブと独自のプローブを組み合わせ、スキャン詳細度を調整する:
base.json:
{
"probes": {
"de.rub.nds.tlsscanner.core.constants.TlsProbeType": ["PROTOCOL_VERSION", "CIPHER_SUITE"]
}
}
quic.json (base.jsonと同じディレクトリ内):
{
"inheritedFromProfiles": ["base.json"],
"settings": {
"scanDetail": "QUICK"
},
"probes": {
"de.rub.nds.tlsscanner.core.constants.QuicProbeType": ["SUPPORTED_VERSIONS"]
}
}
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433 -profile quic.json
これはPROTOCOL_VERSION、CIPHER_SUITE、SUPPORTED_VERSIONSを-scanDetail QUICKで実行します。
スキャナーで利用可能なすべてのプローブを(ターゲットに接続せずに)確認するには、-listProbesを使用します。
これはプロファイルのprobesフィールドが期待する正確なJSON構文で、ProbeTypeクラスごとにグループ化して出力するので、プロファイルにそのままコピー&ペーストできます:
$ java -jar apps/TLS-Server-Scanner.jar -listProbes
{
"de.rub.nds.tlsscanner.core.constants.TlsProbeType" : [ "ALPN", "ESNI", "CERTIFICATE", ... ],
"de.rub.nds.tlsscanner.core.constants.QuicProbeType" : [ "SUPPORTED_VERSIONS", ... ]
}
すべての可能なパラメータに関する詳細情報を取得するには、-helpパラメータを使用するか、パラメータを何も設定せずにjarを実行してください。
TLS-Server-Scannerを簡単に使用するためのビルド済みDockerイメージを提供しています。
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
このイメージはサーバースキャン用に作られていますが、他のjarファイルも含まれています。 これらはentrypointを変更することでアクセスできます。
$ docker run -it --network host --entrypoint java ghcr.io/tls-attacker/tlsscanner -jar TLS-Client-Scanner.jar
コンテナを自分でビルドするためのDockerfileも提供しています:
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
注意: 私はDockerのベストプラクティスに決して詳しいわけではありません。Dockerfileを改善する方法をご存知の場合は、 お気軽にプルリクエストを送ってください
(TLS)プローブには、この特定のプローブを実行するために必要な前提条件がある場合があります。要件システムを使用すると、プローブを実行するために満たす必要があるそのような要件のセットを定義できます。
各要件は、要件が満たされたかどうかを示すブール値を返すevaluate関数を提供します。
要件は、よく知られた論理演算を使用していくつかの方法で連結できます。各要件はand、or、not、xor
インスタンスメソッドを提供し、複数の要件を連鎖させることができます。現在、以下のプローブが実装されており、すぐに使用できます:
FulfilledRequirement - 常にtrueと評価されます。要件がないことを示すのに便利です。UnfulfillableRequirement - 常にfalseと評価されます。プローブの実行を防ぎます。ProbeRequirement - 指定されたプローブが実行された場合にtrueと評価されます。PropertyRequirement - 指定された分析済みプロパティが事前定義された値を持つ場合にtrueと評価されます。値はコンストラクタパラメータとして提供するか、TestResults.TRUEとTestResults.FALSEの省略形としてPropertyTrueRequirementとPropertyFalseRequirementを使用できます。PropertyComparatorRequirement - 分析済みプロパティのコレクション結果が定数値より小さい、等しい、または大きい場合にtrueと評価されます。ProtocolRequirement - 特定のプロトコルバージョンがサポートされている場合にtrueと評価されます。ExtensionRequirement - 特定の拡張機能がリモートピアによってサポートされている場合にtrueと評価されます。OptionsRequirement - 追加のCLIフラグが設定されている場合にtrueと評価されます。現在、一部のクライアントプローブ(ALPN、SNI、セッション再開)で使用されています。WorkingConfigRequirement - 動作する設定が見つかった場合にtrueと評価されます。これらの事前定義された要件とは別に、getRequirementsメソッド内でRequirementクラスを匿名で拡張することもできます。何も必要ない場合は、常にtrueと評価されるFulfilledRequirementを返すことができます。
要件の使用方法の例は、tls-client-scannerとtls-server-scannerのprobeパッケージにあります。
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}