TLS-Scanner

GitHub release (latest by date)

TLS-Scanner est un outil destiné à aider les pentesters et les chercheurs en sécurité dans l'évaluation des configurations de serveurs et de clients TLS.

Veuillez noter : TLS-Scanner est un outil de recherche destiné aux développeurs TLS, pentesters, administrateurs et chercheurs. Il n'y a pas d'interface graphique. Il s'agit de la première version et elle peut contenir quelques bugs.

Compilation

Pour compiler et utiliser TLS-Scanner, vous devez exécuter :

$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package

Alternativement, si vous êtes pressé, vous pouvez ignorer les tests en utilisant :

$ mvn clean package -DskipTests=true

Si vous souhaitez utiliser TLS-Scanner comme bibliothèque, vous devez l'installer avec la commande suivante :

$ mvn clean install

Exécution

Pour exécuter TLS-Scanner, vous devez lancer l'un des fichiers jar présents dans le dossier apps/. Ceux-ci peuvent être obtenus en compilant l'application vous-même ou en téléchargeant les fichiers jar publiés depuis GitHub.

$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433

TLS-Scanner évaluera le serveur spécifié (ici localhost sur le port 4433), et affichera un rapport à la fin. Le rapport utilise des couleurs pour transmettre la gravité des résultats :

Vert : Un bon résultat.
Jaune : Un avertissement, qui peut être un problème potentiel.
Fond jaune : Résultats pour lesquels le scanner n'est pas sûr que la cible soit vulnérable.
Rouge : Un problème grave, qui devrait être corrigé.
Couleur par défaut (selon votre terminal, probablement noir ou blanc) : Un résultat neutre, qui n'est ni bon ni mauvais. Cela inclut les résultats informatifs.
Bleu : Le scanner n'a pas pu analyser le serveur pour ce test spécifique. Cela est probablement dû au fait qu'un prérequis pour ce test n'est pas pris en charge.
Violet : Le scanner a rencontré une erreur lors de l'analyse du serveur pour ce test spécifique. Cela peut être le résultat d'un bug dans le scanner, mais aussi du fait que le serveur ne prend pas en charge une fonctionnalité requise.
Cyan : Utilisé pour structurer le rapport (titres, ...).

Paramètres importants

Vous devez spécifier un hôte que vous souhaitez analyser avec le paramètre -connect.

Si vous souhaitez améliorer les performances de l'analyse, vous pouvez utiliser le paramètre -threads pour augmenter le nombre de threads utilisés.

Un autre paramètre important pour des raisons de performance est le paramètre -scanDetail, qui peut être utilisé pour configurer le niveau de détail de l'analyse. Les valeurs possibles, allant de rapide à très détaillé, sont : QUICK, NORMAL, DETAILED, ALL.

Le niveau de détail de la sortie peut être configuré avec le paramètre -reportDetail. Pour voir plus de détails sur les Guidelines, utilisez -reportDetail ALL.

Par défaut, les résultats sont écrits uniquement dans la console. Si vous souhaitez une sortie lisible par machine, vous pouvez utiliser -outputFile output.json pour écrire automatiquement les résultats dans un fichier JSON.

Cas d'utilisation

Les paramètres les plus importants à modifier sont -scanDetail et -reportDetail. Dans ce qui suit, nous expliquons quelques cas d'utilisation pour ces paramètres.

Analyse par défaut

Dans la plupart des cas, nos paramètres par défaut sont suffisants. Cela effectue une analyse avec les deux niveaux de détail définis sur NORMAL.

Analyse rapide

Si vous souhaitez effectuer une analyse rapide et obtenir un aperçu rapide de votre système, nous recommandons d'utiliser les deux niveaux de détail définis sur QUICK. Cela limite l'étendue de certaines sondes exécutées pour réduire le temps d'exécution et limite le niveau de détail du rapport pour ne pas inclure d'informations très détaillées et techniques.

Analyse détaillée

Si vous souhaitez évaluer pleinement votre système et exécuter tout ce que nous avons, nous recommandons d'utiliser les deux niveaux de détail définis sur ALL. Cela exécute entièrement toutes les sondes existantes et affiche des informations très détaillées pour une analyse et une évaluation plus approfondies.

Profils d'analyse

Au lieu de (ou en plus de) définir des paramètres comme -scanDetail individuellement, vous pouvez regrouper les sondes à exécuter et les paramètres à utiliser dans un profil d'analyse JSON réutilisable avec le paramètre -profile <path/to/profile.json>. Il est disponible à la fois sur TlsServerScanner et TlsClientScanner.

Un profil est un fichier JSON avec :

inheritedFromProfiles : chemins vers d'autres profils dont combiner les sondes, résolus relativement au répertoire du fichier de profil qui les déclare (un chemin absolu est utilisé tel quel).
probes : les sondes à exécuter, sous forme de map du nom pleinement qualifié d'une classe d'énumération ProbeType vers la liste de ses noms de constantes à exécuter. Cela regroupe les sondes par type au lieu de répéter le type pour chaque sonde individuelle, tandis qu'un seul profil peut toujours combiner librement des sondes de différentes implémentations de ProbeType, par exemple TlsProbeType et QuicProbeType. Chaque liste par type accepte également "*" (toutes les constantes de ce type) et "!CONSTANT_NAME" (supprimer une constante précédemment ajoutée par nom ou par "*"), traitées dans l'ordre — voir Everything.json et demo.json dans scan-profiles/ pour des exemples.
settings (optionnel) : remplacements pour des paramètres comme -scanDetail, -reportDetail, -postAnalysisDetail, -noColor, -outputFile, -probeTimeout, -parallelProbes, et -threads. Tout champ omis conserve sa valeur par défaut normale (ou ce qui a été passé sur la ligne de commande). Contrairement à probes, les settings ne sont pas hérités — seuls les settings déclarés directement sur le profil vers lequel vous pointez -profile s'appliquent, même s'il hérite de sondes d'autres profils.

Seules les sondes résolues à partir du profil actif (et de tout ce dont il hérite) sont exécutées ; tout le reste est ignoré.

Exemple, combinant les sondes d'un profil de base avec les vôtres et ajustant le niveau de détail de l'analyse :

base.json :

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

quic.json (dans le même répertoire que 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

Cela exécute PROTOCOL_VERSION, CIPHER_SUITE, et SUPPORTED_VERSIONS avec -scanDetail QUICK.

Pour voir toutes les sondes disponibles pour un scanner (sans se connecter à une cible), utilisez -listProbes. Il les affiche regroupées par classe ProbeType dans la syntaxe JSON exacte attendue par le champ probes d'un profil, afin que vous puissiez les copier-coller directement dans un profil :

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

TLS-Scanner v7.0.0-rtc