
Automatisierter 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 ist ein Tool, das Pentestern und Sicherheitsforschern bei der Bewertung von TLS-Server- und Client-Konfigurationen hilft.
Bitte beachten: TLS-Scanner ist ein Forschungstool, das für TLS-Entwickler, Pentester, Administratoren und Forscher gedacht ist. Es gibt keine grafische Benutzeroberfläche. Es ist in der ersten Version und kann einige Fehler enthalten.
Um TLS-Scanner zu kompilieren und zu verwenden, führen Sie Folgendes aus:
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
Alternativ, wenn Sie es eilig haben, können Sie die Tests überspringen mit:
$ mvn clean package -DskipTests=true
Wenn Sie TLS-Scanner als Bibliothek verwenden möchten, müssen Sie es mit folgendem Befehl installieren:
$ mvn clean install
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 Anwendung selbst kompilieren oder indem Sie
heruntergeladene JAR-Dateien von GitHub verwenden.
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433
Sie müssen einen Host angeben, den Sie scannen möchten, 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 für die Leistung ist der Parameter -scanDetail, mit dem konfiguriert werden kann, wie detailliert Sie scannen möchten. Mögliche Werte von schnell bis sehr detailliert: QUICK, NORMAL, DETAILED, ALL.
Der Detailgrad der Ausgabe kann mit dem Parameter -reportDetail konfiguriert werden. Um weitere Details zu den Richtlinien zu sehen, verwenden Sie -reportDetail ALL.
Standardmäßig werden die Ergebnisse nur auf der Konsole ausgegeben. Wenn Sie eine maschinenlesbare Ausgabe wünschen, können Sie -outputFile output.json verwenden, um die Ergebnisse automatisch in eine JSON-Datei zu schreiben.
Die wichtigsten Parameter zum Ändern sind -scanDetail und -reportDetail. Im Folgenden erklären wir einige Anwendungsfälle für diese Parameter.
Für die meisten Fälle sind unsere Standardparametereinstellungen ausreichend. Dies führt einen Scan mit beiden Detailstufen auf NORMAL durch.
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 Proben, um die Laufzeit zu verkürzen, und schränkt den Berichtsdetailgrad ein, um keine sehr detaillierten und technischen Informationen zu enthalten.
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 Proben vollständig aus und druckt sehr detaillierte Informationen für weitere Analysen und Auswertungen.
Um detaillierte Informationen zu allen möglichen Parametern zu erhalten, verwenden Sie den Parameter -help oder führen Sie die JAR-Datei ohne Parameter aus.
Wir stellen vorgefertigte Docker-Images für die einfache Verwendung des TLS-Server-Scanners bereit.
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
Das Image ist für die Server-Scannung konzipiert, enthält aber auch die anderen JAR-Dateien. Sie können durch Ändern des Entrypoints darauf zugreifen.
$ 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 bauen:
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
Bitte beachten: Ich bin keineswegs mit Docker-Best-Practices vertraut. Wenn Sie wissen, wie man das Dockerfile verbessern kann, können Sie gerne einen Pull Request einreichen.
(TLS)-Proben haben manchmal Voraussetzungen, die erfüllt sein müssen, um diese spezifische Probe auszuführen. Das Anforderungssystem ermöglicht es Ihnen, Sätze solcher Anforderungen zu definieren, die erfüllt sein müssen, damit die Probe ausgeführt werden kann.
Jede Anforderung bietet eine evaluate-Funktion, die einen booleschen Wert zurückgibt, der angibt, ob die Anforderung erfüllt ist.
Anforderungen können auf verschiedene Weise mit bekannten logischen Operationen verknüpft werden. Jede Anforderung bietet and-, or-, not- und xor-Instanzmethoden, um mehrere Anforderungen zu verketten. Die folgenden Proben sind derzeit implementiert und können direkt verwendet werden:
FulfilledRequirement - Wertet immer zu true aus, nützlich um keine Anforderung anzugeben.UnfulfillableRequirement - Wertet immer zu false aus, verhindert die Ausführung von Proben.ProbeRequirement - Wertet zu true aus, wenn die angegebene(n) Probe(n) ausgeführt wurde(n).PropertyRequirement - Wertet zu true aus, wenn die angegebenen analysierten Eigenschaften einen vordefinierten Wert haben. Der Wert kann entweder als Konstruktorparameter übergeben werden oder man kann PropertyTrueRequirement und PropertyFalseRequirement als Abkürzung für TestResults.TRUE bzw. TestResults.FALSE verwenden.PropertyComparatorRequirement - Wertet zu aus, wenn das Sammlungsergebnis einer analysierten Eigenschaft kleiner, gleich oder größer als ein konstanter Wert ist.Abgesehen von diesen vordefinierten Anforderungen kann man auch die Requirement-Klasse anonym innerhalb der getRequirements-Methode erweitern. Wenn nichts benötigt wird, kann man ein FulfilledRequirement zurückgeben, das immer zu true auswertet.
Beispiele zur Verwendung von Anforderungen finden Sie in den probe-Paketen von tls-client-scanner und tls-server-scanner.
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}
trueProtocolRequirement - Wertet zu true aus, wenn bestimmte Protokollversionen unterstützt werden.ExtensionRequirement - Wertet zu true aus, wenn bestimmte Erweiterungen vom entfernten Peer unterstützt werden.OptionsRequirement - Wertet zu true aus, wenn zusätzliche CLI-Flags gesetzt sind. Wird derzeit in einigen Client-Proben verwendet (ALPN, SNI, Sitzungswiederaufnahme).WorkingConfigRequirement - Wertet zu true aus, wenn eine funktionierende Konfiguration gefunden wurde.