tls-attacker/tls-scannerScanner automatisé de configuration serveur et client TLS pour pentesteurs et chercheurs. Évalue les suites de chiffrement, les versions de protocole et les directives de sécurité avec une profondeur de scan personnalisable et une sortie lisible par machine.
# TLS-Scanner
[](https://hydrogen.cloud.nds.rub.de/job/TLS-Scanner/)
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 :
```bash
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
```
Alternativement, si vous êtes pressé, vous pouvez ignorer les tests en utilisant :
```bash
$ mvn clean package -DskipTests=true
```
Si vous souhaitez utiliser TLS-Scanner comme bibliothèque, vous devez l'installer avec la commande suivante :
```bash
$ 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](https://github.com/tls-attacker/TLS-Scanner/releases).
```bash
$ 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/`](https://github.com/tls-attacker/tls-scanner/blob/main/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` :
```json
{
"probes": {
"de.rub.nds.tlsscanner.core.constants.TlsProbeType": ["PROTOCOL_VERSION", "CIPHER_SUITE"]
}
}
```
`quic.json` (dans le même répertoire que `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
```
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 :
```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", ... ]
}
```
## Tous les paramètres
Pour obtenir des informations détaillées sur tous les paramètres possibles, utilisez le paramètre `-help` ou exécutez le jar sans aucun paramètre défini.
# Docker
Nous fournissons des images Docker préconstruites pour une utilisation facile du TLS-Server-Scanner.
```bash
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
```
L'image est conçue pour être utilisée pour l'analyse de serveurs mais contient également les autres fichiers jar.
Ils peuvent être accessibles en modifiant le point d'entrée.
```bash
$ docker run -it --network host --entrypoint java ghcr.io/tls-attacker/tlsscanner -jar TLS-Client-Scanner.jar
```
Nous vous fournissons également un Dockerfile, pour construire le conteneur vous-même :
```bash
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
```
**Veuillez noter :** *Je ne connais en aucun cas les bonnes pratiques Docker. Si vous savez comment améliorer le Dockerfile
n'hésitez pas à soumettre une pull request*
# Système de prérequis
Les sondes (TLS) ont parfois des prérequis nécessaires à l'exécution de cette sonde spécifique. Le système de prérequis vous permet de définir des ensembles de tels prérequis qui doivent être satisfaits pour que la sonde soit exécutée.
Chaque prérequis offre une fonction `evaluate` qui renvoie une valeur booléenne indiquant si le prérequis a été rempli.
Les prérequis peuvent être concaténés de plusieurs manières à l'aide d'opérations logiques bien connues. Chaque prérequis offre les méthodes d'instance `and`, `or`, `not`, et `xor`
pour chaîner plusieurs prérequis. Les sondes suivantes sont actuellement implémentées et peuvent être utilisées directement :
- `FulfilledRequirement` - S'évalue toujours à `true`, utile pour indiquer l'absence de prérequis.
- `UnfulfillableRequirement` - S'évalue toujours à `false`, empêche l'exécution des sondes.
- `ProbeRequirement` - S'évalue à `true` si la ou les sondes spécifiées ont été exécutées.
- `PropertyRequirement` - S'évalue à `true` si les propriétés analysées spécifiées ont une valeur prédéfinie. La valeur peut être fournie comme paramètre de constructeur ou l'on peut utiliser `PropertyTrueRequirement` et `PropertyFalseRequirement` comme raccourcis pour `TestResults.TRUE` et `TestResults.FALSE`.
- `PropertyComparatorRequirement` - S'évalue à `true` si le résultat de collection d'une propriété analysée est inférieur, égal ou supérieur à une valeur constante.
- `ProtocolRequirement` - S'évalue à `true` si certaines versions de protocole sont prises en charge.
- `ExtensionRequirement` - S'évalue à `true` si certaines extensions sont prises en charge par le pair distant.
- `OptionsRequirement` - S'évalue à `true` si des flags cli supplémentaires sont définis. Actuellement utilisé dans certaines sondes client (ALPN, SNI, reprise de session).
- `WorkingConfigRequirement` - S'évalue à `true` si une configuration fonctionnelle a été trouvée.
En dehors de ces prérequis prédéfinis, on peut également étendre la classe `Requirement` de manière anonyme dans la méthode `getRequirements`. Si rien n'est requis, vous pouvez renvoyer un `FulfilledRequirement` qui s'évalue toujours à true.
Des exemples d'utilisation des prérequis se trouvent dans les packages `probe` de `tls-client-scanner` et `tls-server-scanner`.
```java
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}
```