tls-attacker/tls-scannerAutomatisierter TLS-Server- und Client-Konfigurationsscanner für Pentester und Forscher. Bewertet Cipher-Suiten, Protokollversionen und Sicherheitsrichtlinien mit anpassbarer Scan-Tiefe und maschinenlesbarer Ausgabe.
# TLS-Scanner
[](https://hydrogen.cloud.nds.rub.de/job/TLS-Scanner/)
TLS-Scanner ist ein Werkzeug, das Pentester und Sicherheitsforscher bei der Bewertung von TLS-Server- und Client-Konfigurationen unterstützt.
**Bitte beachten:** *TLS-Scanner ist ein Forschungswerkzeug, das für TLS-Entwickler, Pentester, Administratoren und Forscher gedacht ist. Es gibt keine GUI. Es befindet sich in der ersten Version und kann einige Fehler enthalten.*
# Kompilieren
Um TLS-Scanner zu kompilieren und zu verwenden, müssen Sie Folgendes ausführen:
```bash
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
```
Alternativ können Sie, wenn Sie es eilig haben, die Tests überspringen, indem Sie Folgendes verwenden:
```bash
$ mvn clean package -DskipTests=true
```
Wenn Sie TLS-Scanner als Bibliothek verwenden möchten, müssen Sie es mit dem folgenden Befehl installieren:
```bash
$ mvn clean install
```
# Ausführen
Um TLS-Scanner auszuführen, müssen Sie eine der JAR-Dateien im Ordner apps/ ausführen.
Diese können Sie erhalten, indem Sie die App selbst kompilieren oder
[veröffentlichte JAR-Dateien von GitHub herunterladen](https://github.com/tls-attacker/TLS-Scanner/releases).
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433
```
TLS-Scanner bewertet den angegebenen Server (hier `localhost` auf Port `4433`) und gibt am Ende einen Bericht aus.
Der Bericht verwendet Farben, um die Schwere der Ergebnisse zu vermitteln:
- Grün: Ein gutes Ergebnis.
- Gelb: Eine Warnung, die ein potenzielles Problem darstellen kann.
- Gelber Hintergrund: Ergebnisse, bei denen der Scanner unsicher ist, ob das Ziel verwundbar ist.
- Rot: Ein schwerwiegendes Problem, das behoben werden sollte.
- Standardfarbe (abhängig von Ihrem Terminal, wahrscheinlich Schwarz oder Weiß): Ein neutrales Ergebnis, das weder gut noch schlecht ist. Dies umfasst informative Ergebnisse.
- Blau: Der Scanner konnte den Server für diesen spezifischen Test nicht scannen. Dies liegt wahrscheinlich daran, dass eine Voraussetzung für diesen Test nicht unterstützt wird.
- Violett: Der Scanner ist beim Scannen des Servers für diesen spezifischen Test auf einen Fehler gestoßen. Dies kann das Ergebnis eines Fehlers im Scanner sein, aber auch daran liegen, dass der Server eine erforderliche Funktion nicht unterstützt.
- Cyan: Wird zur Strukturierung des Berichts verwendet (Überschriften, ...).
## Wichtige Parameter
Sie müssen einen Host angeben, den Sie scannen möchten, und zwar mit dem Parameter -connect.
Wenn Sie die Leistung des Scans verbessern möchten, können Sie den Parameter `-threads` verwenden, um die Anzahl der verwendeten Threads zu erhöhen.
Ein weiterer wichtiger Parameter aus Leistungsgründen ist der Parameter `-scanDetail`, mit dem konfiguriert werden kann, wie detailliert gescannt werden soll. Mögliche Werte von schnell bis sehr detailliert sind: QUICK, NORMAL, DETAILED, ALL.
Die Detailtiefe der Ausgabe kann mit dem Parameter `-reportDetail` konfiguriert werden. Um mehr Details zu den Guidelines zu sehen, verwenden Sie `-reportDetail ALL`.
Standardmäßig werden die Ergebnisse nur auf der Konsole ausgegeben. Wenn Sie maschinenlesbare Ausgabe wünschen, können Sie `-outputFile output.json` verwenden, um die Ergebnisse automatisch in eine JSON-Datei zu schreiben.
## Anwendungsfälle
Die wichtigsten Parameter, die geändert werden sollten, sind `-scanDetail` und `-reportDetail`. Im Folgenden erläutern wir einige Anwendungsfälle für diese Parameter.
### Standard-Scan
In den meisten Fällen sind unsere Standardparametereinstellungen ausreichend. Dies führt einen Scan mit beiden Detailstufen auf `NORMAL` durch.
### Schneller Scan
Wenn Sie einen schnellen Scan durchführen und einen schnellen Überblick über Ihr System erhalten möchten, empfehlen wir, beide Detailstufen auf `QUICK` zu setzen. Dies begrenzt den Umfang einiger ausgeführter Probes, um die Laufzeit zu verringern, und begrenzt die Berichtsdetails, sodass keine sehr detaillierten und technischen Informationen enthalten sind.
### Detaillierter Scan
Wenn Sie Ihr System vollständig bewerten und alles ausführen möchten, was wir haben, empfehlen wir, beide Detailstufen auf `ALL` zu setzen. Dies führt alle vorhandenen Probes vollständig aus und gibt sehr detaillierte Informationen für weitere Analysen und Bewertungen aus.
## Scan-Profile
Anstatt (oder zusätzlich dazu) Parameter wie `-scanDetail` einzeln festzulegen, können Sie
bündeln, welche Probes ausgeführt werden sollen und welche dieser Parameter verwendet werden sollen, in einem wiederverwendbaren JSON-Scan-Profil mit
dem Parameter `-profile <path/to/profile.json>`. Es ist sowohl auf `TlsServerScanner` als auch auf
`TlsClientScanner` verfügbar.
Ein Profil ist eine JSON-Datei mit:
- `inheritedFromProfiles`: Pfade zu anderen Profilen, deren Probes kombiniert werden sollen, aufgelöst relativ zum
Verzeichnis der Profildatei, die sie deklariert (ein absoluter Pfad wird unverändert verwendet).
- `probes`: die auszuführenden Probes als Map vom vollqualifizierten Namen einer `ProbeType`-Enum-Klasse
auf die Liste ihrer auszuführenden Konstantennamen. Dies gruppiert Probes nach Typ, anstatt den
Typ für jede einzelne Probe zu wiederholen, während ein einzelnes Profil weiterhin frei Probes aus
verschiedenen `ProbeType`-Implementierungen kombinieren kann, z. B. `TlsProbeType` und `QuicProbeType`. Jede typspezifische
Liste akzeptiert auch `"*"` (alle Konstanten dieses Typs) und `"!CONSTANT_NAME"` (eine zuvor per Name oder per `"*"` hinzugefügte Konstante entfernen), in der angegebenen Reihenfolge verarbeitet — siehe `Everything.json` und
`demo.json` in [`scan-profiles/`](https://github.com/tls-attacker/tls-scanner/blob/main/scan-profiles) für Beispiele.
- `settings` (optional): Überschreibungen für Parameter wie `-scanDetail`, `-reportDetail`,
`-postAnalysisDetail`, `-noColor`, `-outputFile`, `-probeTimeout`, `-parallelProbes` und
`-threads`. Jedes ausgelassene Feld behält seinen normalen Standardwert (oder den Wert, der auf der Kommandozeile
übergeben wurde). **Anders als `probes` werden `settings` nicht vererbt** — nur die Einstellungen, die direkt im
Profil deklariert sind, auf das Sie `-profile` zeigen, gelten, selbst wenn es Probes von anderen Profilen erbt.
Nur die Probes, die aus dem aktiven Profil (und allem, wovon es erbt) aufgelöst werden, werden ausgeführt;
alles andere wird übersprungen.
Beispiel, das die Probes eines Basisprofils mit Ihren eigenen kombiniert und die Scan-Detailtiefe anpasst:
`base.json`:
```json
{
"probes": {
"de.rub.nds.tlsscanner.core.constants.TlsProbeType": ["PROTOCOL_VERSION", "CIPHER_SUITE"]
}
}
```
`quic.json` (im selben Verzeichnis wie `base.json`):
```json
{
"inheritedFromProfiles": ["base.json"],
"settings": {
"scanDetail": "QUICK"
},
"probes": {
"de.rub.nds.tlsscanner.core.constants.QuicProbeType": ["SUPPORTED_VERSIONS"]
}
}
```
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433 -profile quic.json
```
Dies führt `PROTOCOL_VERSION`, `CIPHER_SUITE` und `SUPPORTED_VERSIONS` mit `-scanDetail QUICK` aus.
Um alle für einen Scanner verfügbaren Probes anzuzeigen (ohne sich mit einem Ziel zu verbinden), verwenden Sie `-listProbes`.
Es gibt sie gruppiert nach `ProbeType`-Klasse in genau der JSON-Syntax aus, die das `probes`-Feld eines Profils
erwartet, sodass Sie sie direkt in ein Profil kopieren können:
```bash
$ 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", ... ]
}
```
## Alle Parameter
Um detaillierte Informationen über alle möglichen Parameter zu erhalten, verwenden Sie den Parameter `-help` oder führen Sie die JAR-Datei ohne gesetzte Parameter aus.
# Docker
Wir stellen vorgefertigte Docker-Images für die einfache Verwendung des TLS-Server-Scanners bereit.
```bash
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
```
Das Image ist für das Server-Scanning gedacht, enthält aber auch die anderen JAR-Dateien.
Auf diese kann durch Ändern des Entrypoints zugegriffen werden.
```bash
$ docker run -it --network host --entrypoint java ghcr.io/tls-attacker/tlsscanner -jar TLS-Client-Scanner.jar
```
Wir stellen Ihnen auch ein Dockerfile zur Verfügung, um den Container selbst zu erstellen:
```bash
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
```
**Bitte beachten:** *Ich bin keineswegs mit den Docker-Best Practices vertraut. Wenn Sie wissen, wie man das Dockerfile verbessern kann,
zögern Sie nicht, einen Pull Request einzureichen*
# Anforderungssystem
(TLS-)Probes haben manchmal Voraussetzungen, die für die Ausführung dieser spezifischen Probe erforderlich sind. Das Anforderungssystem ermöglicht es Ihnen, Mengen solcher Anforderungen zu definieren, die erfüllt sein müssen, damit die Probe ausgeführt wird.
Jede Anforderung bietet eine `evaluate`-Funktion, die einen booleschen Wert zurückgibt, der angibt, ob die Anforderung erfüllt wurde.
Anforderungen können auf verschiedene Weise mit bekannten logischen Operationen verkettet werden. Jede Anforderung bietet `and`-, `or`-, `not`- und `xor`-
Instanzmethoden, um mehrere Anforderungen zu verketten. Die folgenden Probes sind derzeit implementiert und können direkt verwendet werden:
- `FulfilledRequirement` - Ergibt immer `true`, nützlich, um anzuzeigen, dass keine Anforderung besteht.
- `UnfulfillableRequirement` - Ergibt immer `false`, verhindert die Ausführung von Probes.
- `ProbeRequirement` - Ergibt `true`, wenn die angegebene(n) Probe(n) ausgeführt wurde(n).
- `PropertyRequirement` - Ergibt `true`, wenn die angegebenen analysierten Eigenschaften einen vordefinierten Wert haben. Der Wert kann entweder als Konstruktorparameter angegeben werden, oder man kann `PropertyTrueRequirement` und `PropertyFalseRequirement` als Kurzform für `TestResults.TRUE` und `TestResults.FALSE` verwenden.
- `PropertyComparatorRequirement` - Ergibt `true`, wenn das Sammlungsergebnis einer analysierten Eigenschaft kleiner, gleich oder größer als ein konstanter Wert ist.
- `ProtocolRequirement` - Ergibt `true`, wenn bestimmte Protokollversionen unterstützt werden.
- `ExtensionRequirement` - Ergibt `true`, wenn bestimmte Erweiterungen vom Remote-Peer unterstützt werden.
- `OptionsRequirement` - Ergibt `true`, wenn zusätzliche CLI-Flags gesetzt sind. Wird derzeit in einigen Client-Probes verwendet (ALPN, SNI, Session Resumption).
- `WorkingConfigRequirement` - Ergibt `true`, wenn eine funktionierende Konfiguration gefunden wurde.
Abgesehen von diesen vordefinierten Anforderungen kann man auch die `Requirement`-Klasse anonym innerhalb der `getRequirements`-Methode erweitern. Wenn nichts erforderlich ist, können Sie ein `FulfilledRequirement` zurückgeben, das immer true ergibt.
Beispiele für die Verwendung von Anforderungen finden Sie in den `probe`-Paketen des `tls-client-scanner` und `tls-server-scanner`.
```java
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}
```