pfg666/dtls-fuzzerdtls-fuzzer ist ein Protokoll-Zustands-Fuzzer für DTLS-Server-Implementierungen.
dtls-fuzzer ist ein Java-Tool, das Protokollzustands-Fuzzing von DTLS-Servern durchführt. Konkret unterstützt es die folgenden Funktionen:
dtls-fuzzer verwendet TLS-Attacker, um DTLS-Nachrichten zu generieren/zu parsen sowie den Zustand zu verwalten. Zu diesem Zweck wurde TLS-Attacker um Unterstützung für DTLS erweitert. dtls-fuzzer verwendet Version 3.0b von TLS-Attacker, einer Version, die die DTLS-Erweiterung implementiert.
Das Artefakt enthält:
Die wichtigsten Ordner im Stammverzeichnis von dtls-fuzzer sind:
'experiments/results' enthält experimentelle Ergebnisse, die die Hauptausgabe der Arbeit darstellen. Im Einzelnen
Ausgabeordner werden basierend auf der Experimentkonfiguration benannt, d.h.:
Als Beispiel: Der Ordnername 'jsse-12_rsa_cert_none_rwalk_incl' zeigt ein Experiment mit der JSSE 12-Implementierung von DTLS an, wobei ein Alphabet verwendet wird, das Eingaben zur Durchführung von RSA-Handshakes enthält, die Client-Zertifikatsauthentifizierung deaktiviert ist, der Testalgorithmus Random Walk ist und Wiederholungen enthalten sind.
Ein Ausgabeordner enthält:
Der Evaluator kann (beispielsweise) überprüfen, ob experimentelle Ergebnisse in 'included' mit denen in Tabelle 4 übereinstimmen, oder ob Konfigurationen, die in Tabelle 2 getestet wurden, auch in 'all_ciphers' vorkommen. Beachten Sie, dass Modelle, die im Papier erscheinen, das Ergebnis eines erheblichen Pruning/Trimmens waren, während die Modelle in den Ausgabeordnern unverändert sind.
Zum Zweck der Evaluierung von dtls-fuzzer müssen die folgenden Schritte durchgeführt werden:
Auf diesen Evaluierungsabschnitt folgt ein Leitfaden zur Verwendung von dtls-fuzzer, der seine Hauptanwendungsfälle vorstellt.
dtls-fuzzer wurde auf Ubuntu 18.04 und Debian 9-Distributionen von Linux getestet. Es sollte auf jeder aktuellen Linux-Distribution funktionieren. Unterstützung für andere Plattformen wurde nicht getestet. Diese Anleitung geht von einer Debian-basierten Distribution aus (die 'apt-get' hat).
Eine Java 8 JDK (Java Development Kit) Virtual Machine (VM) wird benötigt. Die Version, die zum Ausführen der Experimente verwendet wurde, ist 1.8.0_222, obwohl spätere Java 8-Versionen ebenfalls funktionieren sollten. Beachten Sie, dass das Tool nicht auf Java 9 oder später gebaut werden kann. Wir verwenden auch Maven (das 'mvn'-Dienstprogramm) für das Abhängigkeitsmanagement/die Bereitstellung.
Wir empfehlen die Verwendung eines ausreichend leistungsfähigen Rechners, da sonst empfindliche Zeitparameter wie die Wartezeit auf Antwort zu niedrig werden könnten, was zu anderen Ausgaben als den im Papier erhaltenen führt. Schlimmer noch, sie können dazu führen, dass Lernversuche fehlschlagen. Die ursprünglichen Experimente wurden auf einem Server mit vielen Kernen durchgeführt, wir erwarten jedoch (obwohl nicht gründlich getestet), dass Lernen auf einem Desktop mit einem i7-Prozessor möglich sein sollte. Lernen ist auch auf schwächeren Systemen möglich, wenn die Zeitparameter entsprechend angepasst werden. Schließlich erfordert das Visualisieren von .dot-Modellen durch Exportieren als .pdf die Installation der graphviz-Bibliothek. Es wird davon ausgegangen, dass das von graphviz bereitgestellte 'dot'-Dienstprogramm im System-PATH liegt.
Kurz gesagt, die empfohlenen Voraussetzungen sind:
dtls-fuzzer benötigt Java 8 JDK (Java Development Kit). Wenn Java nicht installiert ist, installieren wir die OpenJDK-Implementierung (über 'apt-get' auf Ubuntu) und können den Rest dieses Unterabschnitts überspringen.
> sudo apt-get install openjdk-8-jdk
Wenn eine Version von Java installiert ist, können wir überprüfen, welche Version es ist, indem wir ausführen:
> java -version
Der Versionscode sollte mit 1.8 beginnen (z.B. 1.8.0_242), und die Virtual Machine sollte "Server VM" sein (was anzeigt, dass das vollständige JDK installiert ist, nicht nur die Laufzeitumgebung). Wenn das der Fall ist, sind wir mit Java fertig. Wenn nicht, können wir prüfen, ob Java 8 JDK auf unserer Plattform installiert, aber derzeit nicht ausgewählt ist, indem wir die installierten Java-VMs auflisten über:
> update-java-alternatives --list
Wenn Java 8 JDK erscheint, können wir denselben Befehl verwenden, um das Java 8 JDK als Standard-Java-Implementierung zu konfigurieren.
> sudo update-java-alternatives --set java-1.8.0-openjdk-amd64
Andernfalls müssen wir die vollständige Installation wie am Anfang gezeigt durchführen. Leider ist 'update-java-alternatives' manchmal nicht erfolgreich, was durch "error"-Meldungen angezeigt wird. Falls ein solcher Fall eintritt, können wir 'update-alternatives' verwenden, um interaktiv zu konfigurieren, welche Java-VM von 'java' (Interpreter) und 'javac' (Compiler) ausgewählt wird.
> sudo update-alternatives --config java
> sudo update-alternatives --config javac
Mit Java 8 eingerichtet, fahren wir mit der Installation der anderen Abhängigkeiten fort, maven, graphviz plus einige häufige SUT-Abhängigkeiten. Dann klonen wir das Repository von dtls-fuzzer in einen Ordner unserer Wahl und checken den Artifact-Branch aus. Zum Schluss machen wir diesen Ordner zu unserem aktuellen Verzeichnis.
> sudo apt-get install maven graphviz autotools-dev automake libtool
> git clone -b usenix20-artifact https://github.com/assist-project/dtls-fuzzer.git ~/dtls-fuzzer
> cd ~/dtls-fuzzer
Wir führen zunächst das Skript 'prepare.sh' aus, das Bibliotheken installiert, von denen dtls-fuzzer abhängt, nämlich zwei lokale .jars und TLS-Attacker 3.0b. Dann installieren wir das Tool selbst. Die resultierenden Befehle auf einem POSIX-System sind:
> bash prepare.sh
> mvn clean install
Nach diesen Schritten sollte ein Verzeichnis namens 'target' erstellt worden sein, das 'dtls-fuzzer.jar' enthält. Dies ist unsere ausführbare Bibliothek. Von diesem Punkt an wird angenommen, dass Befehle aus dem Stammverzeichnis von dtls-fuzzer ausgeführt werden.
Angenommen, wir möchten ein Modell für OpenSSL 1.1.1b nur mit PSK (Pre-Shared Keys) generieren. Ein Schnellstart von dtls-fuzzer läuft wie folgt ab.
Zuerst richten wir die SUT ein, was automatisch durch ein 'setup_sut.sh'-Skript erfolgt.
> bash setup_sut.sh openssl-1.1.1b
Dann wählen wir eine Argumentdatei aus dem Ordner 'args/openssl-1.1.1b'. Wir sehen, dass es mehrere Argumentdateien zur Auswahl gibt, nämlich:
learn_openssl-1.1.1b_all_cert_none_rwalk_incl
learn_openssl-1.1.1b_all_cert_nreq_rwalk_incl
learn_openssl-1.1.1b_all_cert_req_rwalk_incl
learn_openssl-1.1.1b_psk_rwalk_incl
Die relevante Argumentdatei ist 'learn_openssl-1.1.1b_psk_rwalk_incl', da ihr Dateiname auf PSK hinweist. Wir wählen sie also aus und führen den Fuzzer darauf aus. Zusätzlich begrenzen wir die Anzahl der Tests auf 200, um die Lernzeit zu verkürzen. Schließlich muss für OpenSSL LD_LIBRARY_PATH auf das Implementierungsverzeichnis ('suts/openssl-1.1.1b/') gesetzt werden. Bevor wir mit dem Lernen beginnen, möchten wir vielleicht einen einfachen Test ausführen, um zu überprüfen, ob unser Setup funktioniert. Ein guter Test ist einfach das Abschließen eines Handshakes. Wir liefern die Argumentdatei zusammen mit einem entsprechenden Test aus 'examples/tests' als Parameter. Wir erhalten:
> LD_LIBRARY_PATH=suts/openssl-1.1.1b/ java -jar target/dtls-fuzzer.jar @args/openssl-1.1.1b/learn_openssl-1.1.1b_psk_rwalk_incl -test examples/tests/psk
Wenn alles gut geht, sollte der Server "This is a hello message" ausgegeben haben, eine Nachricht, die wir nach Abschluss des Handshakes senden. Da wir wissen, dass unser Setup funktioniert, können wir nun mit dem Lernen beginnen, indem wir ausführen:
> LD_LIBRARY_PATH=suts/openssl-1.1.1b/ java -jar target/dtls-fuzzer.jar @args/openssl-1.1.1b/learn_openssl-1.1.1b_psk_rwalk_incl -queries 200
Wir bemerken, dass ein Ausgabeverzeichnis 'output/openssl-1.1.1b_psk_rwalk_incl/' für das Experiment erstellt wurde. Wir können mit 'ls' den aktuellen Status des Experiments überprüfen (Anzahl der generierten Hypothesen...).
> ls output/openssl-1.1.1b_psk_rwalk_incl/
Wenn alles gut geht, sollte das Ausgabeverzeichnis nach 20-30 Minuten eine Datei 'learnedModel.dot' enthalten. Wir können die Datei mit dem graphviz 'dot'-Dienstprogramm visualisieren, indem wir sie als .pdf exportieren und die .pdf mit unserem bevorzugten .pdf-Betrachter öffnen.
> dot -Tpdf output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.dot > output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.pdf
> evince output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.pdf
Schließlich können wir 'trim_model.sh' verwenden, um eine bessere/getrimmte Version des Modells zu generieren. Dies kann wie folgt erfolgen:
> bash trim_model.sh --output output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.dot output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.dot
> dot -Tpdf output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.dot > output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.pdf
> evince output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.pdf
Wir können nun die Konformität des Systems bestimmen, indem wir das Modell mit der Spezifikation vergleichen...
Wenn wir das Ausgabeverzeichnis mit 'ls' inspizieren, könnten wir 'error.msg' finden. Das ist ein Zeichen dafür, dass das Experiment fehlgeschlagen ist und das Lernen abrupt beendet wurde. In solchen Fällen zeigt das Anzeigen des Inhalts den Grund für den Fehler auf.
> cat output/openssl-1.1.1b_psk_rwalk_incl/error.msg
Beachten Sie, dass die Konformitätsprüfung dennoch auf der letzten generierten Hypothese durchgeführt werden kann, solange potenzielle Erkenntnisse gegen das System validiert werden (wie sie es ohnehin sollten).
Wir stellen ein Skript zum Einrichten der SUT bereit. Dieses Skript lädt die Quelldateien herunter, installiert einige Abhängigkeiten (jvm) und baut die SUT. Um SUTs anzuzeigen, für die eine automatische Einrichtung bereitgestellt wird, führen Sie aus:
> bash setup_sut.sh
Um beispielsweise Contiki-NGs tinydtls-Implementierung einzurichten, führen Sie aus:
> bash setup_sut.sh ctinydtls
Das Skript erzeugt zwei Ordner im Stammverzeichnis von dtls-fuzzer.
Leider ist die Automatisierung der SUT-Einrichtung ein komplizierter Prozess, daher nehmen wir die folgenden Abkürzungen. Für Java-SUTs (JSSE, Scandium) bauen wir die Implementierungen nicht, sondern verwenden die kompilierten .jars aus dem Verzeichnis 'experiments/suts'. Beachten Sie, dass der Quellcode dieser Java-SUTs (Serveranwendungen) öffentlich online verfügbar ist, siehe Scandium und JSSE, was auch für PionDTLS der Fall ist. Das automatische Installieren von Abhängigkeiten kann 'sudo'-Zugriff erfordern. Dies tritt bei GnuTLS auf, das auf externen Bibliotheken wie nettle basiert, und bei Eclipses TinyDTLS, das auf autoconf basiert. Schließlich stellen wir keine automatische Einrichtung/Argumentdateien für NSS und PionDTLS bereit, da die Einrichtung für diese Systeme zu kompliziert ist.
Wenn während des Einrichtungsprozesses etwas nicht funktioniert, kann das Löschen des 'suts'-Ordners (oder des 'suts/SUT'-Ordners spezifisch für die SUT) und das erneute Ausführen des Einrichtungsskripts das Problem lösen. Auch wenn der Build fehlschlägt, sollte der Quellcode der Implementierung dennoch in das Verzeichnis 'suts' heruntergeladen worden sein. Eine Problemumgehung besteht darin, die Implementierung manuell zu bauen. Solange die Implementierung gebaut ist, sollte unser Setup funktionieren.
Wir geben hiermit einen unvollständigen Abhängigkeitsbaum der verschiedenen SUTs an. Diejenigen in Kursivschrift sind Abhängigkeiten, die 'setup_sut.sh' mit 'sudo'-Zugriff zu installieren versucht.
Wir sind nun bereit, eine SUT-Konfiguration zu lernen. Argumentdateien für verschiedene SUT-Konfigurationen sind im Verzeichnis 'args' im Home-Verzeichnis von dtls-fuzzer vorhanden. Jeder Argumentdateiname beschreibt den Experimentaufbau (SUT, Alphabet, Authentifizierung), wie durch die Ausgabeordnernamen in 'experiments/results/' beschrieben. Um das Lernen für eine SUT mit einer Argumentdatei zu starten, führen Sie aus:
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file
Der Ausgabeordner wird in einem generierten 'output'-Verzeichnis gespeichert.
Im Vergleich zu den Experimenten im Papier haben wir das Antwort-Timeout für mehrere SUTs als Anpassung an weniger leistungsfähige Hardware erhöht. Um die Lernzeit zu verkürzen, empfehlen wir, die Testgrenze des Random-Walk-Algorithmus von 20000 auf 5000 zu reduzieren. Dies kann erfolgen durch:
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -queries 5000
Dies überschreibt die Grenzeneinstellung in der Argumentdatei. Abgesehen von GnuTLS, PionDTLS und JSSE erwarten wir, dass das Lernen bei dieser niedrigeren Grenze dieselben Modelle produziert.
Timing kann ein Problem darstellen, was zu Nichtdeterminismus führt, gefolgt von einem abrupten Ende mit einer informativen 'error.msg'-Datei. In solchen Fällen gibt es zwei Stellschrauben, die angepasst werden können:
Diese Parameter können durch Überschreiben (wahrscheinlich mit einem höheren Wert) der entsprechenden Einstellungen in der Argumentdatei angepasst werden:
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -timeout new_response_timeout -runWait new_start_timeout
Um Probleme mit dem Timing zu vermeiden, empfehlen wir, Experimente auf einem ausreichend leistungsfähigen Rechner durchzuführen. Die Hauptursache für Nichtdeterminismus ist, dass die SUT zu lange zum Starten oder zum Generieren einer Antwort braucht. Diese Wahrscheinlichkeit sinkt, je mehr Rechenleistung zur Verfügung steht.
Wir möchten Experimente möglicherweise automatisch nach einem bestimmten Zeitraum beenden, insbesondere Experimente, von denen nicht erwartet wird, dass sie jemals enden. Das Festlegen dieses Zeitraums ist über den Parameter time limit möglich, dem die maximale Dauer zugewiesen wird, die das Experiment laufen darf. Diese Dauer wird im ISO 8601-Format angegeben. Um die Ausführungszeit eines Experiments auf 60 Minuten zu begrenzen, würden wir ausführen:
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -timeLimit "PT60M"
Es ist möglich, mehrere Experimente gleichzeitig auszuführen, sofern die Server so konfiguriert sind, dass sie auf verschiedenen Ports lauschen. Wir können jedes Experiment in einem separaten Terminal starten. Alternativ können wir Experimente in einem einzigen Terminal mit dem 'disown'-Dienstprogramm starten:
> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk 1>/dev/null 2>&1 & disown
Das Ausführen von mehr als ein paar (>2) Experimenten stellt jedoch eine zusätzliche Belastung für den Rechner dar. Es erhöht auch die Wahrscheinlichkeit eines Lernfehlers aufgrund einer versehentlichen Portkollision. In den meisten Konfigurationen sind die Server so konfiguriert, dass sie auf einem fest codierten Port über localhost lauschen; die in 'args' bereitgestellten Konfigurationen verwenden unterschiedliche fest codierte Ports. Bei JSSE- und Scandium-Konfigurationen ist das Setup anders. Bei jedem Test startet die SUT einen Server, der auf einem dynamisch gewählten Port lauscht, und teilt den Port über TCP-Sockets dtls-fuzzer mit. Dies hat den Vorteil, dass dtls-fuzzer benachrichtigt wird, wenn der Server bereit ist, Pakete zu empfangen (ohne dies müsste dtls-fuzzer blind eine willkürliche Zeit auf den Serverstart warten). Der Nachteil ist, dass der zugewiesene Port derselbe sein könnte wie ein fest codierter Port eines anderen Experiments, bei dem ein Server-Thread kürzlich gestoppt wurde und ein neuer Thread noch nicht gestartet wurde (was bedeutet, dass der fest codierte Port bei der dynamischen Zuweisung verwendet werden könnte). Um diese Art von Kollision zu vermeiden, empfehlen wir, Scandium- und JSSE-Experimente getrennt von allen anderen durchzuführen.
Wir schlagen die folgenden Konfigurationen vor, bei denen der automatisierte Build zuverlässig ist, das Lernen schneller ist oder interessante Fehler gefunden wurden. Stellen Sie sicher, dass Sie die SUT eingerichtet haben, bevor Sie den angegebenen Befehl ausführen. Sie werden feststellen, dass wir uns wo möglich auf PSK-Konfigurationen konzentrieren. Der Grund dafür ist, dass PSK mit kleinen Passwörtern deutlich weniger Rechenzeit erfordert als jeder andere Verschlüsselungsmechanismus.### OpenSSL 1.1.1b Jede OpenSSL-1.1.1b-Konfiguration (z. B. 'args/openssl-1.1.1b/learn_openssl-1.1.1b_all_cert_req_rwalk_incl') kann ausprobiert werden. Experimente enden schnell (weniger als ein Tag) und üben alle Schlüsselaustausch-Algorithmen aus. Befehl für eine Konfiguration mit benötigtem Client-Zertifikat unter Verwendung aller (PSK, RSA, ECDH, DH) Schlüsselaustausch-Algorithmen:
> LD_LIBRARY_PATH=suts/openssl-1.1.1b/ java -jar target/dtls-fuzzer.jar @args/openssl-1.1.1b/learn_openssl-1.1.1b_all_cert_req_rwalk_incl -queries 5000
Hinweis: Beim Lernen von OpenSSL muss die Variable LD_LIBRARY_PATH auf das Installationsverzeichnis gesetzt werden.
Jede mbedtls-2.16.1-Konfiguration kann aus denselben Gründen wie bei OpenSSL verwendet werden. Experimente dauern länger, da das SUT langsamer ist. Befehl für eine Konfiguration mit deaktivierter Client-Zertifikatsauthentifizierung unter Verwendung aller Schlüsselaustausch-Algorithmen:
> java -jar target/dtls-fuzzer.jar @args/mbedtls-2.16.1/learn_mbedtls_all_cert_none_rwalk_incl -queries 5000
Eine redigierte Version des für diese Konfiguration erhaltenen Modells ist im Anhang enthalten. Wir können eine niedrige Testgrenze von 2000 verwenden, da das Eingabealphabet klein ist, was das Testen erleichtert.
> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk -queries 2000
Für WolfSSL stellen wir eine PSK-Konfiguration bereit, bei der das Lernen relativ schnell abgeschlossen sein sollte.
> java -jar target/dtls-fuzzer.jar @args/wolfssl-4.0.0/learn_wolfssl-4.0.0_psk_rwalk -queries 2000
Die neueren von uns analysierten GnuTLS-Versionen lieferten schöne kompakte Modelle. Leider führte die Aktivierung der Client-Authentifizierung zu einem starken Anstieg der erforderlichen Tests. Wir schlagen eine Konfiguration vor, die sie deaktiviert, um die Lernzeit zu verkürzen:
> java -jar target/dtls-fuzzer.jar @args/gnutls-3.6.7/learn_gnutls-3.6.7_all_cert_none_rwalk_incl -queries 2000
Eine redigierte Version des für diese Konfiguration erhaltenen Modells ist im Paper enthalten. Das Modell deckt wichtige Fehler auf, leider ist das Experiment zeitaufwändig. Das Experiment sollte nicht parallel zu Experimenten durchgeführt werden, die nicht Scandium oder JSSE betreffen. Befehl:
> java -jar target/dtls-fuzzer.jar @args/scandium-2.0.0/learn_scandium-2.0.0_psk_rwalk -queries 2000
Eine redigierte Version des für diese Konfiguration erhaltenen Modells ist im Paper enthalten. Das Modell deckt wichtige Fehler auf. Das Experiment sollte nicht parallel zu Experimenten durchgeführt werden, die nicht Scandium oder JSSE betreffen. Beachten Sie, dass das Lernen für JSSE nicht abschließt/konvergiert, sondern Hypothesen mit immer mehr Zuständen erstellt werden. Wir haben daher JSSE-Experimente so konfiguriert, dass sie automatisch nach einem Tag (im Paper zwei Tage) beendet werden. Befehl für RSA-Schlüsselaustausch:
> java -jar target/dtls-fuzzer.jar @args/jsse-12/learn_jsse-12_rsa_cert_req_rwalk_incl
Statt des mühsamen Lernens möchten wir möglicherweise einfach testen, ob in dieser Umgebung ein Handshake abgeschlossen werden kann, ohne Zertifikatsnachrichten zu senden. Dies kann durch Ausführen von:
> java -jar target/dtls-fuzzer.jar @args/jsse-12/learn_jsse-12_rsa_cert_req_rwalk_incl -test examples/tests/rsa
Sobald das Lernen abgeschlossen ist, sind im Ausgabeverzeichnis folgende Dinge zu analysieren:
Das gelernte Modell im .dot-Format kann mit der graphviz-Bibliothek durch Konvertierung in .pdf visualisiert werden:
> dot -Tpdf learnedModel.dot > learnedModel.pdf
Leider werden die mit dieser Methode erstellten .pdfs mit zunehmender Modellgröße immer schwieriger zu lesen. Daher haben wir Bereinigungsskripte entwickelt/verwendet/importiert, die über 'trim_model.sh' aufgerufen werden. Das Skript gibt Nutzungsinformationen durch Ausführen von:
> bash trim_model.sh
Wir empfehlen die Verwendung des Skripts in seiner einfachsten Form:
> bash trim_model.sh learnedModel.dot
Das Skript:
(5) erfordert die Installation der benutzerdefinierten Python 3-Bibliothek mypydot, die sich in 'experiments\scripts' befindet. Alle anderen Schritte verwenden einfaches 'sed' plus die dot-trimmer Java-Bibliothek. Ein .jar für diese Bibliothek ist in 'experiments\scripts' enthalten.
Ausführen:
> java -jar target/dtls-fuzzer.jar -help
Die Anzahl der Optionen mag überwältigend sein. Um eine DTLS-Server-Implementierung zu lernen, muss man nur wenige Optionen angeben, nämlich: "-connect ip_address:port", die Adresse, auf der der laufende DTLS-Server horcht. Alle anderen Optionen sind auf Standardwerte gesetzt, einschließlich des Alphabets.
Um einen Lernlauf für eine existierende, sagen wir lokale Serverimplementierung zu starten, die auf Port 20000 horcht, führen Sie aus:
> java -jar target/dtls-fuzzer.jar -connect localhost:20000
Es wird wahrscheinlich Probleme mit dieser Art des Lernens geben. Das Lernen erfordert, dass man den Server nach jedem Test zurücksetzen kann. Manche Server behalten einen Zustand von einem Test zum nächsten bei. Dies kann zu Nichtdeterminismus während des Lernens führen, daher ist ein besserer Ansatz, bei jedem Test einen neuen Server-Thread mit einem bereitgestellten Befehl zu starten. Der Server-Thread wird beendet, sobald der Test durchgeführt ist, was ein ordnungsgemäßes Zurücksetzen gewährleistet. Beispiel für OpenSSL:
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -cmd "openssl s_server -accept 20000 -dtls1_2"
Bei so vielen Parametern können Befehle sehr lang werden. dtls-fuzzer verwendet JCommander zum Parsen von Argumenten, die auch Parameter aus einer Datei lesen kann. Gehen Sie zu 'experiments/args' für Beispiele von Argumenten. Um eine Argumentdatei an dtls-fuzzer zu übergeben, geben Sie sie als Parameter mit vorangestelltem "@" an. Sie können auch andere explizite Argumente zu Befehlen hinzufügen (die die in der Argumentdatei überschreiben):
> java -jar target/dtls-fuzzer.jar @arg_file ...überschreibende Parameter...
Um eine Reihe von Lernläufen zu starten, kann das Skript 'launcher.py' in 'experiments/scripts' verwendet werden. Wenn ein Verzeichnis mit Argumentdateien bereitgestellt wird, startet das Tool für jede Argumentdatei einen Lernprozess.
> python3 experiments/scripts/launcher.py --jar target/dtls-fuzzer.jar --args args_folder
Bevor Sie Lern-Experimente starten, ist es hilfreich zu überprüfen, ob die Argumente richtig gesetzt sind, insbesondere die Timing-Parameter. Zu diesem Zweck kann dtls-fuzzer eine benutzerdefinierte Testsuite (Sammlung von Tests) auf dem SUT ausführen und eine Zusammenfassung der Ausgaben liefern. Diese Funktionalität kann auch verwendet werden, um fehlgeschlagene Lern-Experimente zu diagnostizieren, d.h. herauszufinden, was schiefgelaufen ist.
Um die Testsuite auf einem Server mit dem Standardalphabet auszuführen, können Sie Folgendes ausführen:
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file
Beispiele für Testdateien finden Sie unter 'examples/tests'. Eine Testdatei besteht aus einer durch Zeilenumbrüche getrennten Liste von Eingaben. Tests werden durch leere Zeilen getrennt. Das Ende jedes Tests ist entweder das Ende der Datei oder eine leere Zeile. "#" wird verwendet, um eine Zeile auszukommentieren.
Wenn Sie ein Modell/eine Spezifikation haben, können Sie auch die Testsuite ausführen und die Ausgabe mit der in einer Spezifikation vergleichen.
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file -specification model
Die Anzahl der Testausführungen ist über den Parameter '-times' konfigurierbar, der standardmäßig auf 1 gesetzt ist. Ein hoher Wert hilft, Nichtdeterminismus in Lernkonfigurationen zu erkennen, indem die Ausgabe jedes Tests verglichen wird.
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file -times 10
Wenn Sie schließlich die Argumentdatei für ein Lern-Experiment haben, können Sie diese verwenden, um Tests auf dem beteiligten SUT durchzuführen, indem Sie einfach die erforderlichen Test-Argumente hinzufügen:
> java -jar target/dtls-fuzzer.jar @learning_arg_file -test test_file