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:

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

$ mvn clean package -DskipTests=true

Wenn Sie TLS-Scanner als Bibliothek verwenden möchten, müssen Sie es mit dem folgenden Befehl installieren:

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

$ 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/ 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:

{
    "probes": {
        "de.rub.nds.tlsscanner.core.constants.TlsProbeType": ["PROTOCOL_VERSION", "CIPHER_SUITE"]
    }
}

quic.json (im selben Verzeichnis wie 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

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:

$ 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", ... ]
}