dtls-fuzzer est un outil Java qui effectue du fuzzing d'état de protocole de serveurs DTLS. Plus concrètement, il supporte les fonctionnalités suivantes :

1. étant donné un alphabet, il peut automatiquement générer un modèle d'une implémentation locale de serveur DTLS ;
2. étant donné un test (séquence d'entrées) et un alphabet, il peut exécuter le test sur une implémentation de serveur DTLS ;
3. il peut exécuter une tâche d'apprentissage par lots, impliquant plusieurs cycles d'apprentissage.

dtls-fuzzer utilise [TLS-Attacker][tlsattacker] pour générer/analyser les messages DTLS ainsi que pour maintenir l'état. À cette fin, TLS-Attacker a été étendu avec le support de DTLS. dtls-fuzzer repose sur la [version 3.0b][tlsattackerver] de TLS-Attacker, une version implémentant l'amélioration DTLS.

Contenu de l'artefact

L'artefact contient :

1. une description de la structure de fichiers de dtls-fuzzer, incluant le code source et les données expérimentales conformes à celles présentées dans l'article ;
2. un guide pour évaluer dtls-fuzzer sur un SUT (System Under Test) / une implémentation de serveur DTLS choisie.

Structure des fichiers de dtls-fuzzer

Les dossiers les plus importants dans le répertoire racine de dtls-fuzzer sont :

1. 'src', répertoire contenant le code source Java de dtls-fuzzer ;
2. 'examples', répertoire contenant des exemples d'alphabets, de tests, de spécifications (c'est-à-dire de modèles) et de fichiers d'arguments qui peuvent être fournis à dtls-fuzzer pour lancer des expériences d'apprentissage. Les fichiers de ce répertoire sont utilisés comme entrées pour les expériences d'apprentissage ;
3. 'experiments', répertoire contenant les données relatives aux expériences. Certaines de ces données servent également d'entrée pour les expériences d'apprentissage. Les dossiers les plus notables sont :
   1. 'suts', avec des binaires pour les SUT Java. Ces SUT sont des programmes serveur DTLS sur mesure dont le code source est disponible publiquement ;
   2. 'patches', correctifs qui ont été appliqués à certains SUT (notamment aux utilitaires) avant la compilation du code source. Le but principal de ces correctifs était d'empêcher un comportement induit par le timing pendant l'apprentissage, d'activer/désactiver des fonctionnalités dans le SUT et de configurer des paramètres tels que la clé pré-partagée ;
   3. 'keystore', matériel de clé (par exemple, paires de clés publique-privée, keystores Java) utilisé pendant l'apprentissage ;
   4. 'results', résultats expérimentaux.

Résultats expérimentaux

'experiments/results' contient les résultats expérimentaux, qui sont la principale production du travail. En particulier :

• 'all_ciphers' contient les dossiers de sortie pour toutes les expériences exécutées ;
  • 'mapper' contient les résultats expérimentaux qui aident à justifier certaines des décisions du mapper (voir Section 5.2)
• 'included' contient les dossiers de sortie pour les expériences convergentes (convergent signifie que l'apprentissage génère avec succès un modèle).
  • notez que toutes les expériences dans 'all_ciphers' n'ont pas réussi/terminé avec un modèle final (nous disons dans ces cas que l'apprentissage n'a pas convergé)

Dossiers de sortie

Les dossiers de sortie sont nommés en fonction de la configuration de l'expérience, c'est-à-dire :

• le SUT/implémentation testé ;
• l'alphabet utilisé, en termes d'algorithmes d'échange de clés couverts, où 'all' indique que les 4 algorithmes d'échange de clés ont été utilisés ;
• le cas échéant, si la certification client était requise (req), optionnelle (nreq) ou désactivée (none) ;
• l'algorithme de test : random walk (rwalk) ou une adaptation de celui-ci (stests) ;
  • les expériences utilisant l'adaptation n'ont pas été incluses dans l'article
• optionnellement, si les retransmissions étaient incluses/exclues des sorties (incl ou excl).
  • les retransmissions étaient incluses par défaut

Par exemple, le nom de dossier 'jsse-12_rsa_cert_none_rwalk_incl' indique une expérience sur l'implémentation JSSE 12 de DTLS, utilisant un alphabet incluant des entrées pour effectuer des handshakes RSA, l'authentification par certificat client est désactivée, l'algorithme de test est random walk et les retransmissions sont incluses.

Un dossier de sortie contient :

• 'alphabet.xml', l'alphabet d'entrée ;
• 'command.args', le fichier d'arguments utilisé contenant divers paramètres de l'expérience, notamment :
  • queries, la limite sur le nombre de tests random walk qui doivent réussir pour qu'une hypothèse soit considérée comme finale
  • equivalenceAlgorithms, les algorithmes de test basés sur des modèles employés
  • runWait et timeout, respectivement le délai d'attente de démarrage et le délai d'attente de réponse (nous y reviendrons plus tard)
• 'sul.config', configuration dépendante du SUT pour TLS-Attacker ; la même configuration peut être utilisée pour exécuter des traces de workflow sur le SUT en utilisant TLS-Attacker seul ;
• 'hyp[0-9]+.dot', hypothèses intermédiaires ;
• 'statistics.txt', statistiques de l'expérience telles que le nombre total de tests, le temps d'apprentissage ;
  • le Tableau 4 affiche ces données
• 'nondet.log', journaux des comportements non déterministes rencontrés ;
• 'learnedModel.dot', en cas de convergence de l'apprentissage, le modèle appris (c'est-à-dire l'hypothèse finale) ;
• 'error.msg', un message d'erreur généré en cas d'échec de l'expérience/arrêt de l'apprentissage et donc absence de convergence vers un modèle final.
  • le principal responsable est le non-déterminisme lié au temps (les mêmes entrées conduisent à des résultats différents).

L'évaluateur peut vérifier (par exemple) que les résultats expérimentaux dans 'included' correspondent à ceux affichés dans le Tableau 4, ou que les configurations testées dans le Tableau 2 apparaissent également dans 'all_ciphers'. Notez que les modèles apparaissant dans l'article sont le résultat d'un élagage/trimming significatif, tandis que les modèles apparaissant dans les dossiers de sortie sont inchangés.

Étapes d'évaluation de dtls-fuzzer

Pour l'évaluation de dtls-fuzzer, il est nécessaire d'effectuer les étapes suivantes :

1. S'assurer que les prérequis sont satisfaits
2. Installer dtls-fuzzer
3. Configurer le SUT
4. Utiliser dtls-fuzzer pour générer des modèles pour le SUT
5. Analyser les résultats

Cette section d'évaluation est suivie d'un guide sur l'utilisation de dtls-fuzzer qui présente ses principaux cas d'utilisation.

Assurer les prérequis

dtls-fuzzer a été testé sur les distributions Linux Ubuntu 18.04 et Debian 9. Il devrait fonctionner sur toute distribution Linux récente. Le support pour d'autres plateformes n'a pas été testé. Ce guide suppose qu'une distribution basée sur Debian est utilisée (qui dispose de 'apt-get').

Un JDK (Java Development Kit) Java 8 est requis. La version utilisée pour exécuter les expériences est 1.8.0_222, bien que les versions ultérieures de Java 8 devraient également fonctionner. Notez que l'outil ne compile pas sur Java 9 ou ultérieur. Nous utilisons également maven (l'utilitaire 'mvn') pour la gestion des dépendances / le déploiement.