dtls-fuzzer es una herramienta Java que realiza pruebas de estado de protocolo mediante fuzzing en servidores DTLS. Más concretamente, soporta las siguientes funcionalidades:

1. dado un alfabeto, puede generar automáticamente un modelo de una implementación local de servidor DTLS;
2. dada una prueba (secuencia de entradas) y un alfabeto, puede ejecutar la prueba en una implementación de servidor DTLS;
3. puede ejecutar una tarea de aprendizaje por lotes, que involucra múltiples ejecuciones de aprendizaje.

dtls-fuzzer utiliza [TLS-Attacker][tlsattacker] para generar/analizar mensajes DTLS, así como para mantener el estado. Con ese fin, TLS-Attacker ha sido extendido con soporte para DTLS. dtls-fuzzer se basa en la [versión 3.0b][tlsattackerver] de TLS-Attacker, una versión que implementa la mejora de DTLS.

Contenido del artefacto

El artefacto contiene:

1. una descripción de la estructura de archivos de dtls-fuzzer, incluyendo código fuente y datos experimentales consistentes con lo mostrado en el artículo;
2. un tutorial para evaluar dtls-fuzzer en un SUT (Sistema Bajo Prueba) / implementación de servidor DTLS elegido.

Estructura de archivos de dtls-fuzzer

Las carpetas más importantes en el directorio raíz de dtls-fuzzer son:

1. 'src', directorio que contiene el código fuente Java de dtls-fuzzer;
2. 'examples', directorio que contiene ejemplos de alfabetos, pruebas, especificaciones (es decir, modelos) y archivos de argumentos que se pueden proporcionar a dtls-fuzzer para lanzar experimentos de aprendizaje. Los archivos en este directorio se utilizan como entradas para experimentos de aprendizaje;
3. 'experiments', directorio que contiene datos relacionados con experimentos. Parte de estos datos también sirven como entrada para experimentos de aprendizaje. Las carpetas más notables son:
   1. 'suts', con binarios para SUTs Java. Estos SUTs son programas de servidor DTLS hechos a medida cuyo código fuente está disponible públicamente;
   2. 'patches', parches que se aplicaron a algunos SUTs (particularmente a utilidades) antes de que se compilara el código fuente. El propósito principal de estos parches fue prevenir comportamientos inducidos por tiempos durante el aprendizaje, habilitar/deshabilitar funcionalidades en el SUT y configurar parámetros como la clave precompartida;
   3. 'keystore', material de claves (por ejemplo, pares de clave pública-privada, almacenes de claves Java) utilizado durante el aprendizaje;
   4. 'results', resultados experimentales.

Resultados experimentales

‘experiments/results’ contiene los resultados experimentales, que son la salida principal del trabajo. En particular:

• ‘all_ciphers’ contiene carpetas de salida para todos los experimentos ejecutados;
  • ‘mapper’ contiene resultados experimentales que ayudan a justificar algunas de las decisiones del mapper tomadas (ver Sección 5.2)
• ‘included’ contiene carpetas de salida para experimentos que convergen (converger significa que el aprendizaje genera exitosamente un modelo).
  • Tenga en cuenta que no todos los experimentos en ‘all_ciphers’ fueron exitosos/terminaron con un modelo final (decimos en tales casos que el aprendizaje no convergió)

Carpetas de salida

Las carpetas de salida se nombran según la configuración del experimento, es decir:

• el SUT/implementación probado;
• el alfabeto utilizado, en términos de algoritmos de intercambio de claves cubiertos, donde ‘all’ indica que se utilizaron los 4 algoritmos de intercambio de claves;
• cuando corresponda, si se requirió certificación del cliente (req), opcional (nreq) o deshabilitada (none);
• el algoritmo de prueba: recorrido aleatorio (rwalk) o una adaptación del mismo (stests);
  • los experimentos que utilizan la adaptación no se han incluido en el artículo
• opcionalmente, si las retransmisiones se incluyeron/excluyeron de las salidas (incl o excl).
  • las retransmisiones se incluyeron por defecto

Como ejemplo, el nombre de carpeta ‘jsse-12_rsa_cert_none_rwalk_incl’ indica un experimento en la implementación JSSE 12 de DTLS, utilizando un alfabeto que incluye entradas para realizar handshakes RSA, la autenticación de certificado del cliente está deshabilitada, el algoritmo de prueba es recorrido aleatorio y las retransmisiones están incluidas.

Una carpeta de salida contiene:

• ‘alphabet.xml’, el alfabeto de entrada;
• ‘command.args’, el archivo de argumentos utilizado que contiene varios parámetros del experimento, más notablemente:
  • queries, el límite en el número de pruebas de recorrido aleatorio que deben pasar para que una hipótesis se considere final
  • equivalenceAlgorithms, algoritmos de prueba basados en modelos empleados
  • runWait y timeout, el tiempo de espera de inicio y de respuesta respectivamente (los abordaremos más adelante)
• ‘sul.config’, configuración dependiente del SUT para TLS-Attacker, la misma configuración se puede usar para ejecutar trazas de flujo de trabajo en el SUT usando solo TLS-Attacker;
• ‘hyp[0-9]+.dot’, hipótesis intermedias;
• ‘statistics.txt’, estadísticas del experimento como el número total de pruebas, tiempo de aprendizaje;
  • La Tabla 4 muestra estos datos
• ‘nondet.log’, registros de comportamiento no determinista encontrados;
• ‘learnedModel.dot’, en caso de que el aprendizaje haya convergido, el modelo aprendido (es decir, hipótesis final);
• ‘error.msg’, un mensaje de error generado en caso de que el experimento haya fallado/el aprendizaje se haya detenido y, por lo tanto, no haya convergido a un modelo final.
  • el principal culpable es el no determinismo relacionado con el tiempo (las mismas entradas llevan a resultados diferentes).

El evaluador puede verificar (por ejemplo) que los resultados experimentales en ‘included’ correspondan a los mostrados en la Tabla 4, o que las configuraciones probadas en la Tabla 2 también aparezcan en ‘all_ciphers’. Tenga en cuenta que los modelos que aparecen en el artículo fueron el resultado de una poda/recorte significativo, mientras que los modelos que aparecen en las carpetas de salida no están alterados.

Pasos de evaluación de dtls-fuzzer

Con el propósito de evaluar dtls-fuzzer es necesario realizar los siguientes pasos:

1. Asegurar que se cumplen los prerrequisitos
2. Instalar dtls-fuzzer
3. Configurar el SUT
4. Usar dtls-fuzzer para generar modelos para el SUT
5. Analizar resultados

Esta sección de evaluación es seguida por una guía sobre el uso de dtls-fuzzer que introduce sus principales casos de uso.

Asegurar los prerrequisitos

dtls-fuzzer ha sido probado en Ubuntu 18.04 y Debian 9 distribuciones de Linux. Debería funcionar en cualquier distribución reciente de Linux. No se ha probado el soporte para otras plataformas. Esta guía asume que se utiliza una distribución basada en Debian (que tiene 'apt-get').

Se requiere una Máquina Virtual (VM) Java 8 JDK (Kit de Desarrollo Java). La versión utilizada para ejecutar experimentos es 1.8.0_222, aunque versiones posteriores de Java 8 también deberían funcionar. Tenga en cuenta que la herramienta no compila en Java 9 o posterior. También confiamos en maven (la utilidad 'mvn') para la gestión/implementación de dependencias.