TLS-Scanner

TLS-Scanner 是一款协助渗透测试人员和安全研究人员评估 TLS 服务器和客户端配置的工具。

请注意： TLS-Scanner 是一款面向 TLS 开发者、渗透测试人员、管理员和研究人员的研究工具。它没有图形界面。这是第一个版本，可能包含一些 bug。

编译

要编译并使用 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 将评估指定的服务器（此处为 localhost 的 4433 端口），并在最后打印一份报告。 报告使用颜色来传达发现的严重程度：

• 绿色：良好的结果。
• 黄色：警告，可能是潜在问题。
• 黄色背景：扫描器不确定目标是否存在漏洞的结果。
• 红色：严重问题，应当修复。
• 默认颜色（取决于你的终端，可能是黑色或白色）：中性结果，既不好也不坏。这包括信息性结果。
• 蓝色：扫描器无法针对此特定测试扫描服务器。这很可能是由于该测试的前提条件不受支持。
• 紫色：扫描器在针对此特定测试扫描服务器时遇到错误。这可能是扫描器中的 bug 导致的，也可能是由于服务器不支持所需功能。
• 青色：用于组织报告结构（标题等）。

重要参数

你必须使用 -connect 参数指定要扫描的主机。

如果你想提高扫描性能，可以使用 -threads 参数来增加使用的线程数。

出于性能考虑的另一个重要参数是 -scanDetail 参数，它可用于配置你希望扫描的详细程度。从快速到非常详细的可能值为：QUICK、NORMAL、DETAILED、ALL。

输出的详细程度可以通过 -reportDetail 参数配置。要查看有关 Guidelines 的更多详细信息，请使用 -reportDetail ALL。

默认情况下，结果仅写入控制台。如果你想要机器可读的输出，可以使用 -outputFile output.json 自动将结果写入 JSON 文件。

使用场景

最重要的可更改参数是 -scanDetail 和 -reportDetail。下面我们将解释这些参数的一些使用场景。

默认扫描

在大多数情况下，我们的默认参数设置就足够了。它会执行一次扫描，两个详细级别都设置为 NORMAL。

快速扫描

如果你想执行快速扫描并快速了解你的系统概况，我们建议将两个详细级别都设置为 QUICK。这会限制某些已执行探测的范围以降低运行时间，并限制报告详细程度，使其不包含非常详细和技术性的信息。

详细扫描

如果你想全面评估你的系统并执行我们拥有的所有内容，我们建议将两个详细级别都设置为 ALL。这会完整执行所有现有探测，并打印非常详细的信息以供进一步分析和评估。

扫描配置文件

除了（或作为补充）单独设置诸如 -scanDetail 之类的参数外，你还可以通过 -profile <path/to/profile.json> 参数将要运行的探测以及要使用的这些参数打包到一个可复用的 JSON 扫描配置文件中。 该参数在 TlsServerScanner 和 TlsClientScanner 上都可用。

配置文件是一个 JSON 文件，包含：

• inheritedFromProfiles：要从中组合探测的其他配置文件的路径，相对于声明它们的配置文件所在目录解析（绝对路径按原样使用）。
• probes：要运行的探测，是一个从 ProbeType 枚举类的完全限定名到要运行的常量名列表的映射。这按类型对探测进行分组，而不是为每个探测重复类型，同时单个配置文件仍可自由组合来自不同 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

这会以 -scanDetail QUICK 运行 PROTOCOL_VERSION、CIPHER_SUITE 和 SUPPORTED_VERSIONS。

要查看扫描器可用的所有探测（无需连接到目标），请使用 -listProbes。 它会按 ProbeType 类分组打印它们，采用配置文件的 probes 字段所期望的精确 JSON 语法， 因此你可以直接复制粘贴到配置文件中：

$ 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。

Docker

我们提供预构建的 docker 镜像，以便轻松使用 TLS-Server-Scanner。

$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433

该镜像旨在用于服务器扫描，但也包含其他 jar 文件。 可以通过更改入口点来访问它们。

$ 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， 欢迎提交 pull request

需求系统

(TLS) 探测有时具有执行该特定探测所需的前提条件。需求系统允许你定义必须满足的此类需求集合，以便执行探测。

每个需求都提供一个 evaluate 函数，它返回一个布尔值，指示该需求是否已满足。 需求可以通过众所周知的逻辑运算以多种方式连接。每个需求都提供 and、or、not 和 xor 实例方法，用于链接多个需求。目前实现了以下探测，可以开箱即用：

• FulfilledRequirement - 始终求值为 true，用于表示无需求。
• UnfulfillableRequirement - 始终求值为 false，阻止探测执行。
• ProbeRequirement - 如果指定的探测已执行，则求值为 true。
• PropertyRequirement - 如果指定的已分析属性具有预定义值，则求值为 true。该值既可以作为构造函数参数提供，也可以使用 PropertyTrueRequirement 和 PropertyFalseRequirement 作为 TestResults.TRUE 和 TestResults.FALSE 的简写。
• 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));
}