dtls-fuzzer هي أداة ‎Java‎ تقوم بتنفيذ اختبارات الحالة البروتوكولية (protocol state fuzzing) لخوادم DTLS . بشكل أكثر تحديدًا، فهي تدعم الوظائف التالية:

1. بالنظر إلى مجموعة حروف (alphabet)، يمكنها إنشاء نموذج لتطبيق خادم DTLS محلي تلقائيًا؛
2. بالنظر إلى اختبار (تسلسل من المدخلات) ومجموعة حروف، يمكنها تنفيذ الاختبار على تطبيق خادم DTLS؛
3. يمكنها تشغيل مهمة تعلم جماعي، تتضمن عمليات تعلم متعددة.

يستخدم dtls-fuzzer TLS-Attacker لإنشاء/تحليل رسائل DTLS وكذلك للحفاظ على الحالة.
لتحقيق ذلك، تم توسيع TLS-Attacker لدعم DTLS.
يعتمد dtls-fuzzer على الإصدار 3.0b من TLS-Attacker، وهو إصدار يطبق تحسين DTLS.

محتويات القطعة الأثرية (Artifact)

تحتوي القطعة الأثرية على:

1. وصف لهيكل الملفات لـ dtls-fuzzer، بما في ذلك الكود المصدري والبيانات التجريبية المتوافقة مع ما هو معروض في الورقة البحثية؛
2. دليل إرشادي لتقييم dtls-fuzzer على SUT محدد (النظام قيد الاختبار) / تطبيق خادم DTLS.

هيكل ملفات dtls-fuzzer

المجلدات الأكثر أهمية في الدليل الجذر لـ dtls-fuzzer هي:

1. 'src'، الدليل الذي يحتوي على كود Java المصدري لـ dtls-fuzzer؛
2. 'examples'، الدليل الذي يحتوي على أمثلة لمجموعات الحروف، والاختبارات، والمواصفات (أي النماذج)، وملفات الوسائط التي يمكن توفيرها لـ dtls-fuzzer لبدء تجارب التعلم. تُستخدم الملفات في هذا الدليل كمدخلات لتجارب التعلم؛
3. 'experiments'، الدليل الذي يحتوي على بيانات تتعلق بالتجارب. بعض هذه البيانات تعمل أيضًا كمدخلات لتجارب التعلم. المجلدات الأكثر بروزًا هي:
   1. 'suts'، مع ملفات ثنائية لـ SUTs بلغة Java. هذه الـ SUTs هي برامج خادم DTLS مصنوعة خصيصًا وكودها المصدري متاح للعموم؛
   2. 'patches'، التصحيحات التي تم تطبيقها على بعض الـ SUTs (خاصة على الأدوات المساعدة) قبل تجميع الكود المصدري. الغرض الأساسي من هذه التصحيحات هو منع السلوك الناتج عن التوقيت أثناء التعلم، وتمكين/تعطيل الوظائف في الـ SUT، وتهيئة المعلمات مثل المفتاح المشترك مسبقًا؛
   3. 'keystore'، المواد الأساسية للمفاتيح (مثل أزواج المفاتيح العامة-الخاصة، مخازن المفاتيح بلغة Java) المستخدمة أثناء التعلم؛
   4. 'results'، النتائج التجريبية.

النتائج التجريبية

يحتوي 'experiments/results' على النتائج التجريبية، وهي المخرجات الرئيسية للعمل. على وجه الخصوص:

• 'all_ciphers' يحتوي على مجلدات المخرجات لجميع التجارب التي تم تشغيلها؛
  • 'mapper' يحتوي على نتائج تجريبية تساعد في تبرير بعض قرارات المخطط (انظر القسم 5.2)
• 'included' يحتوي على مجلدات المخرجات للتجارب المتقاربة (التقارب يعني أن التعلم ينتج نموذجًا بنجاح).
  • لاحظ أنه ليست كل التجارب في 'all_ciphers' كانت ناجحة / انتهت بنموذج نهائي (نقول في مثل هذه الحالات أن التعلم لم يتقارب)

مجلدات المخرجات

يتم تسمية مجلدات المخرجات بناءً على تكوين التجربة، أي:

• الـ SUT / التطبيق المختبر؛
• مجموعة الحروف المستخدمة، من حيث خوارزميات تبادل المفاتيح المغطاة، حيث يشير 'all' إلى استخدام جميع خوارزميات تبادل المفاتيح الأربعة؛
• حيثما ينطبق، ما إذا كانت شهادة العميل مطلوبة (req)، اختيارية (nreq) أو معطلة (none)؛
• خوارزمية الاختبار: المشي العشوائي (rwalk) أو تكييف له (stests)؛
  • لم يتم تضمين التجارب التي تستخدم التكييف في الورقة البحثية
• اختياريًا، ما إذا كانت عمليات إعادة الإرسال مضمنة في / مستبعدة من المخرجات (incl أو excl).
  • تم تضمين عمليات إعادة الإرسال افتراضيًا

كمثال، يشير اسم المجلد 'jsse-12_rsa_cert_none_rwalk_incl' إلى تجربة على تطبيق JSSE 12 لـ DTLS، باستخدام مجموعة حروف تشمل مدخلات لإجراء مصافحات RSA، ومصادقة شهادة العميل معطلة، وخوارزمية الاختبار هي المشي العشوائي وعمليات إعادة الإرسال مضمنة.

يحتوي مجلد المخرجات على:

• 'alphabet.xml'، مجموعة الحروف المدخلة؛
• 'command.args'، ملف الوسائط المستخدم الذي يحتوي على معلمات التجربة المختلفة، وأبرزها:
  • queries، الحد الأقصى لعدد اختبارات المشي العشوائي التي يجب أن تمر لاعتبار الفرضية نهائية
  • equivalenceAlgorithms، خوارزميات الاختبار المعتمدة على النموذج المستخدمة
  • runWait و timeout، مهلة البداية ومهلة الاستجابة على التوالي (سنذكرها لاحقًا)
• 'sul.config'، تكوين يعتمد على الـ SUT لـ TLS-Attacker، يمكن استخدام نفس التكوين لتنفيذ آثار سير العمل على الـ SUT باستخدام TLS-Attacker وحده؛
• 'hyp[0-9]+.dot'، الفرضيات الوسيطة؛
• 'statistics.txt'، إحصائيات التجربة مثل العدد الإجمالي للاختبارات، وقت التعلم؛
  • يعرض الجدول 4 هذه البيانات
• 'nondet.log'، سجلات السلوك غير الحتمي الذي تم مواجهته؛
• 'learnedModel.dot'، في حالة تقارب التعلم، النموذج المتعلم (أي الفرضية النهائية)؛
• 'error.msg'، رسالة خطأ تم إنشاؤها في حالة فشل التجربة / توقف التعلم وبالتالي، لم يتقارب إلى نموذج نهائي.
  • السبب الرئيسي هو عدم الحتمية المتعلقة بالوقت (نفس المدخلات تؤدي إلى نتائج مختلفة).

يمكن للمقيّم التحقق (على سبيل المثال) من أن النتائج التجريبية في 'included' تتوافق مع تلك المعروضة في الجدول 4، أو أن التكوينات التي تم اختبارها في الجدول 2 تظهر أيضًا في 'all_ciphers'. لاحظ أن النماذج التي تظهر في الورقة البحثية كانت نتيجة تقليم / تشذيب كبير، بينما النماذج التي تظهر في مجلدات المخرجات غير معدلة.

خطوات تقييم dtls-fuzzer

لغرض تقييم dtls-fuzzer من الضروري تنفيذ الخطوات التالية:

1. التأكد من استيفاء المتطلبات الأساسية
2. تثبيت dtls-fuzzer
3. إعداد الـ SUT
4. استخدام dtls-fuzzer لإنشاء نماذج للـ SUT
5. تحليل النتائج

يتبع هذا القسم الخاص بالتقييم دليل حول استخدام dtls-fuzzer يقدم حالات الاستخدام الرئيسية له.

التأكد من المتطلبات الأساسية

تم اختبار dtls-fuzzer على توزيعات Ubuntu 18.04 و Debian 9 من Linux. يجب أن يعمل على أي توزيعة Linux حديثة. لم يتم اختبار الدعم للمنصات الأخرى. يفترض هذا الدليل استخدام توزيعة قائمة على Debian (والتي تحتوي على 'apt-get').

يلزم وجود جهاز افتراضي (VM) Java 8 JDK (Java Development Kit). الإصدار المستخدم لتشغيل التجارب هو 1.8.0_222، على الرغم من أن الإصدارات الأحدث من Java 8 يجب أن تعمل أيضًا. لاحظ أن الأداة لا تُبنى على Java 9 أو أحدث. نعتمد أيضًا على maven (أداة 'mvn') لإدارة التبعيات / النشر.

نوصي باستخدام جهاز قوي بما فيه الكفاية، وإلا قد تصبح معلمات التوقيت الحساسة مثل وقت انتظار الاستجابة منخفضة جدًا، مما يسبب مخرجات مختلفة عن تلك التي تم الحصول عليها في الورقة البحثية. والأسوأ من ذلك، يمكن أن تتسبب في فشل تجارب التعلم. تم تشغيل التجارب الأصلية على خادم متعدد النوى، ومع ذلك، نتوقع (على الرغم من أننا لم نختبر بدقة) أن التعلم يجب أن يكون ممكنًا على جهاز مكتبي بمعالج i7. التعلم ممكن أيضًا على الأنظمة الأضعف إذا تم ضبط معلمات التوقيت وفقًا لذلك. أخيرًا، تتطلب تصور نماذج .dot عن طريق تصديرها إلى .pdf تثبيت مكتبة graphviz. من المفترض أن تكون أداة 'dot' التي توفرها graphviz موجودة في PATH النظام.

باختصار، المتطلبات الأساسية الموصى بها هي:

• توزيعة Linux حديثة، ويفضل أن تكون قائمة على Debian
• جهاز مكتبي / خادم لإعادة إنتاج التجارب / تعلم موثوق
• (>=) 4 GB RAM
• Java 8 JDK
• maven
• graphviz

إعداد البيئة

Java 8 JDK

يتطلب dtls-fuzzer Java 8 JDK (Java Development Kit). إذا لم يكن Java مثبتًا، نقوم بتثبيت تطبيق OpenJDK (عبر 'apt-get' على Ubuntu)، ويمكننا تخطي بقية هذا القسم الفرعي.

> sudo apt-get install openjdk-8-jdk

إذا كان إصدار java مثبتًا، يمكننا التحقق من الإصدار عن طريق تشغيل:

> java -version

يجب أن يبدأ رمز الإصدار بـ 1.8 (مثل 1.8.0_242)، ويجب أن يكون الجهاز الافتراضي "Server VM" (مما يشير إلى أن JDK الكامل مثبت، وليس فقط بيئة التشغيل). إذا كان الأمر كذلك، فقد انتهينا من Java. إذا لم يكن كذلك، يمكننا التحقق مما إذا كان Java 8 JDK مثبتًا على منصتنا ولكن غير محدد حاليًا، عن طريق سرد أجهزة Java الافتراضية المثبتة عبر:

> update-java-alternatives --list

إذا ظهر Java 8 JDK، يمكننا استخدام نفس الأمر لتكوين Java 8 JDK ليكون تطبيق Java الافتراضي.

> sudo update-java-alternatives --set java-1.8.0-openjdk-amd64

خلاف ذلك، نحتاج إلى إجراء التثبيت الكامل كما هو موضح في البداية. لسوء الحظ، لا ينجح 'update-java-alternatives' أحيانًا، كما تشير رسائل "error". إذا نشأت مثل هذه الحالة، يمكننا استخدام 'update-alternatives' لتكوين أي جهاز Java افتراضي يتم تحديده بواسطة 'java' (المفسر) و 'javac' (المترجم) بشكل تفاعلي.

> sudo update-alternatives --config java
> sudo update-alternatives --config javac

أخرى

مع ضبط Java 8، ننتقل إلى تثبيت التبعيات الأخرى، maven، graphviz بالإضافة إلى بعض تبعيات SUT الشائعة. ثم نستنسخ مستودع dtls-fuzzer إلى مجلد من اختيارنا، مع التحقق من فرع القطعة الأثرية. للإنهاء، نجعل هذا المجلد هو الدليل الحالي لدينا.

> 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

تثبيت dtls-fuzzer

نقوم أولاً بتشغيل البرنامج النصي 'prepare.sh' الذي يقوم بتثبيت المكتبات التي يعتمد عليها dtls-fuzzer، وهما ملفا .jar محليان و TLS-Attacker 3.0b. ثم نقوم بتثبيت الأداة نفسها. ستكون الأوامر الناتجة على نظام POSIX كما يلي:

> bash prepare.sh
> mvn clean install

بعد هذه الخطوات، يجب أن يكون قد تم إنشاء دليل باسم 'target' يحتوي على 'dtls-fuzzer.jar'. هذه هي مكتبتنا القابلة للتنفيذ. من هذه النقطة فصاعدًا، يُفترض أن يتم تشغيل الأوامر من الدليل الجذر لـ dtls-fuzzer.

التشغيل السريع (Quickrun)

لنفترض أننا نريد إنشاء نموذج لـ OpenSSL 1.1.1b باستخدام PSK فقط (المفاتيح المشتركة مسبقًا). يتم التشغيل السريع لـ dtls-fuzzer على النحو التالي.

أولاً نقوم بإعداد الـ SUT، والذي يتم تلقائيًا بواسطة برنامج نصي 'setup_sut.sh'.

> bash setup_sut.sh openssl-1.1.1b

ثم نختار ملف وسائط من مجلد 'args/openssl-1.1.1b'. نلاحظ أن هناك العديد من ملفات الوسائط للاختيار من بينها، وهي:

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

ملف الوسائط المهم هو 'learn_openssl-1.1.1b_psk_rwalk_incl'، حيث يشير اسم الملف إلى PSK. نختاره بالتالي، ونشغل المختبر عليه. نضيف أيضًا حدًا لعدد الاختبارات إلى 200، لتقصير وقت التعلم. أخيرًا، بالنسبة لـ OpenSSL، يجب تعيين LD_LIBRARY_PATH إلى دليل التطبيق ('suts/openssl-1.1.1b/'). قبل تشغيل التعلم، قد نرغب في تنفيذ اختبار بسيط للتحقق من أن الإعداد يعمل بشكل صحيح. الاختبار الجيد هو مجرد إكمال مصافحة. نقوم بتوفير ملف الوسائط، بالإضافة إلى اختبار مقابل من 'examples/tests' كمعامل. نحصل على:

>  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

إذا سارت الأمور على ما يرام، يجب أن يكون الخادم قد طبع "هذه رسالة ترحيب"، وهي رسالة نرسلها بعد إكمال المصافحة. بمعرفة أن الإعداد يعمل، يمكننا الآن بدء التعلم عن طريق تشغيل:

> 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

نلاحظ أنه تم إنشاء دليل مخرجات، 'output/openssl-1.1.1b_psk_rwalk_incl/' للتجربة. يمكننا استخدام الأمر 'ls' لهذا الدليل للتحقق من الحالة الحالية للتجربة (عدد الفرضيات التي تم إنشاؤها...).

> ls output/openssl-1.1.1b_psk_rwalk_incl/

عندما تسير الأمور بشكل صحيح

إذا سارت الأمور على ما يرام، بعد 20-30 دقيقة، يجب أن يحتوي دليل المخرجات على ملف 'learnedModel.dot'. يمكننا عرض الملف باستخدام أداة graphviz 'dot'، عن طريق التصدير إلى .pdf وفتح ملف .pdf باستخدام عارض .pdf المفضل لدينا.

> 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

أخيرًا، يمكننا استخدام 'trim_model.sh' لإنشاء نسخة أفضل / أكثر تشذيبًا من النموذج. يمكن القيام بذلك على النحو التالي:

> 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

يمكننا الآن تحديد امتثال النظام عن طريق التحقق من النموذج مقابل المواصفات...

عندما تسير الأمور بشكل خاطئ

عند استخدام الأمر 'ls' على دليل المخرجات قد نجد ملف 'error.msg'. هذه علامة على فشل التجربة وانتهاء التعلم بشكل مفاجئ. في مثل هذه الحالات، يكشف عرض المحتويات عن سبب الفشل.

> cat output/openssl-1.1.1b_psk_rwalk_incl/error.msg

لاحظ أنه لا يزال من الممكن التحقق من الامتثال على آخر فرضية تم إنشاؤها، طالما تم التحقق من النتائج المحتملة مقابل النظام (كما ينبغي أن تكون على أي حال).

إعداد الـ SUT

نوفر برنامجًا نصيًا لإعداد الـ SUT. يقوم هذا البرنامج النصي بتنزيل ملفات المصدر، وتثبيت بعض التبعيات (jvm) وبناء الـ SUT. لعرض الـ SUTs التي يتم توفير الإعداد التلقائي لها، قم بتشغيل:

> bash setup_sut.sh

لإعداد، على سبيل المثال، تطبيق tinydtls الخاص بـ Contiki-NG، قم بتشغيل:

> bash setup_sut.sh ctinydtls

سينشئ البرنامج النصي مجلدين في الدليل الجذر لـ dtls-fuzzer.

• 'suts'، حيث يتم نشر ملفات SUT الثنائية
• 'modules'، حيث يتم نشر أي تبعيات

لسوء الحظ، فإن أتمتة إعداد SUT هي عملية معقدة، لذلك نتخذ الاختصارات التالية. بالنسبة لـ SUTs بلغة Java (JSSE, Scandium) لا نقوم ببناء التطبيقات، بدلاً من ذلك نستخدم ملفات .jar المجمعة من دليل 'experiments/suts'. لاحظ أن الكود المصدري لتطبيقات Java هذه (تطبيقات الخادم) متاح للعموم عبر الإنترنت، انظر Scandium و JSSE، وهو أيضًا الحال بالنسبة لـ PionDTLS. قد يطالب التثبيت التلقائي للتبعيات بالوصول إلى 'sudo'. يحدث هذا لـ GnuTLS الذي يعتمد على مكتبات خارجية مثل nettle، و Eclipse's TinyDTLS، الذي يعتمد على autoconf. أخيرًا، لا نقدم إعدادًا تلقائيًا / ملفات وسائط لـ NSS و PionDTLS بسبب تعقيد إعداد هذه الأنظمة.

استكشاف الأخطاء وإصلاحها

إذا توقفت الأمور في عملية الإعداد عن العمل، فقد يؤدي حذف مجلد 'suts' (أو مجلد 'suts/SUT' الخاص بـ SUT) وإعادة تشغيل البرنامج النصي للإعداد إلى حل المشكلة. أيضًا، في حالة فشل البناء، يجب أن يظل الكود المصدري للتطبيق قد تم تنزيله إلى دليل 'suts'. الحل البديل هو بناء التطبيق يدويًا. طالما تم بناء التطبيق، يجب أن يعمل الإعداد لدينا.

نقدم هنا شجرة غير كاملة للتبعيات التي تمتلكها SUTs المختلفة. تلك المائلة هي تبعيات يحاول 'setup_sut.sh' تثبيتها باستخدام الوصول إلى 'sudo'.

• GnuTLS:
  • m4
  • pkg-config
  • nettle
• Eclipse's TinyDTLS
  • m4
  • autoconf
• WolfSSL
  • m4
  • autoconf
  • libtool
• nettle
  • m4
  • pkg-config
• autoconf
  • aclocal
    • automake
    • autotools-dev

تعلم تكوين SUT

نحن الآن جاهزون لتعلم تكوين SUT. يتم توفير ملفات وسائط لتكوينات SUT المختلفة في دليل 'args' الموجود في الدليل الرئيسي لـ dtls-fuzzer. يصف اسم كل ملف وسائط إعداد التجربة (SUT، مجموعة الحروف، المصادقة) كما هو موصوف بواسطة أسماء مجلدات المخرجات في 'experiments/results/'. لبدء التعلم لـ SUT باستخدام ملف وسائط، قم بتشغيل:

> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file

سيتم تخزين مجلد المخرجات في دليل 'output' تم إنشاؤه.

تعديلات المعلمات

حد الاختبار

مقارنة بتجارب الورقة البحثية، قمنا بزيادة مهلة الاستجابة لعدة SUTs كتكيف مع أجهزة أقل قوة. لتقصير وقت التعلم، نقترح تقليل حد الاختبار لخوارزمية المشي العشوائي من 20000 إلى 5000. يمكن القيام بذلك عن طريق:

> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -queries 5000

سيؤدي هذا إلى الكتابة فوق إعداد الحد في ملف الوسائط. بصرف النظر عن GnuTLS و PionDTLS و JSSE، نتوقع أن ينتج التعلم نفس النماذج لهذا الحد الأدنى.

معلمات التوقيت

يمكن أن يصبح التوقيت مشكلة، مما يتسبب في عدم الحتمية، يليه إنهاء مفاجئ مع ملف 'error.msg' إعلامي. في مثل هذه الحالات، هناك مقبضان يمكن ضبطهما:

1. مهلة الاستجابة (الوقت المنتظر لكل استجابة قبل استنتاج أن الخادم صامت)؛
2. مهلة البداية (الوقت المنتظر لبدء تشغيل الخادم).

يمكن تعديل هذه المعلمات عن طريق الكتابة فوق (على الأرجح بقيمة أعلى) الإعدادات المقابلة في ملف الوسائط:

> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -timeout new_response_timeout -runWait new_start_timeout

لتجنب المشكلات المتعلقة بالتوقيت، نقترح تشغيل التجارب على جهاز قوي بما فيه الكفاية. السبب الرئيسي لعدم الحتمية هو أن الـ SUT يستغرق وقتًا طويلاً للبدء أو لتوليد استجابة. تقل هذه الاحتمالية مع زيادة قوة الحوسبة.

وقت التعلم

قد نرغب في إنهاء التجارب تلقائيًا بعد فترة معينة، خاصة التجارب التي لا يُتوقع أن تنتهي أبدًا. يعد تعيين هذه الفترة ممكنًا عبر معلمة الحد الزمني التي يتم تعيينها على الحد الأقصى للمدة المسموح بها للتجربة. يتم توفير هذه المدة بتنسيق ISO 8601. لتحديد وقت تنفيذ تجربة بـ 60 دقيقة، سنقوم بتشغيل:

> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -timeLimit "PT60M"

التجارب المتزامنة وتعارض المنافذ

من الممكن تشغيل تجارب متعددة في وقت واحد بشرط أن تكون الخوادم مهيأة للاستماع إلى منافذ مختلفة. يمكننا اختيار تشغيل كل تجربة في محطة منفصلة. بدلاً من ذلك، يمكننا تشغيل التجارب في محطة واحدة باستخدام أداة 'disown':

> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk 1>/dev/null 2>&1 & disown

ومع ذلك، فإن تشغيل أكثر من عدد قليل (>2) يضع عبئًا إضافيًا على الجهاز. كما أنه يزيد من فرصة فشل التعلم بسبب تعارض المنافذ العرضي. في معظم التكوينات، يتم تكوين الخوادم للاستماع إلى بعض المنافذ المبرمجة عبر localhost، وتستخدم التكوينات المقدمة في 'args' منافذ مبرمجة متميزة. بالنسبة لتكوينات JSSE و Scandium، يختلف الإعداد. في كل اختبار، يقوم الـ SUT بتشغيل خادم يستمع إلى منفذ يتم اختياره ديناميكيًا ويتواصل مع المنفذ عبر مآخذ TCP إلى dtls-fuzzer. هذا له ميزة إعلام dtls-fuzzer عندما يكون الخادم جاهزًا لاستقبال الحزم (بدون ذلك، سيتعين على dtls-fuzzer الانتظار بشكل أعمى لمدة زمنية عشوائية حتى يبدأ الخادم). الجانب السلبي هو أن المنفذ المخصص قد يكون هو نفسه بعض المنافذ المبرمجة لتجربة مختلفة، حيث تم إيقاف خيط خادم مؤخرًا ولم يبدأ خيط جديد بعد (مما يعني أنه يمكن استخدام المنفذ المبرمج في التخصيص الديناميكي). لتجنب هذا النوع من التعارض، ننصح بتشغيل تجارب Scandium و JSSE بشكل منفصل عن جميع التجارب الأخرى.

التكوينات المقترحة

نقترح التكوينات التالية التي يكون فيها البناء التلقائي موثوقًا، ويكون التعلم أسرع أو تم العثور على أخطاء مثيرة للاهتمام. تأكد من إعداد الـ SUT قبل تشغيل الأمر المقدم. ستلاحظ أننا نركز على تكوينات PSK حيثما أمكن. ذلك لأن PSK مع كلمات مرور صغيرة يتطلب وقت معالجة أقل بكثير من أي آلية تشفير أخرى.### OpenSSL 1.1.1b يمكن تجربة أي إعداد لـ openssl-1.1.1b (على سبيل المثال 'args/openssl-1.1.1b/learn_openssl-1.1.1b_all_cert_req_rwalk_incl'). تنتهي التجارب بسرعة (أقل من يوم)، مع ممارسة جميع خوارزميات تبادل المفاتيح. الأمر لتكوين شهادة العميل المطلوبة باستخدام جميع خوارزميات تبادل المفاتيح (PSK, RSA, ECDH, DH):

> 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

ملاحظة، عند تعلم OpenSSL من الضروري توجيه متغير LD_LIBRARY_PATH إلى دليل التثبيت.

MbedTLS 2.16.1

يمكن استخدام أي إعداد لـ mbedtls-2.16.1 لنفس أسباب OpenSSL. تستغرق التجارب وقتًا أطول لإكمالها لأن SUT أبطأ. الأمر لتكوين تعطيل مصادقة شهادة العميل باستخدام جميع خوارزميات تبادل المفاتيح:

> java -jar target/dtls-fuzzer.jar @args/mbedtls-2.16.1/learn_mbedtls_all_cert_none_rwalk_incl -queries 5000

Contiki-NG TinyDTLS باستخدام PSK

تظهر نسخة منقحة من النموذج الذي تم الحصول عليه لهذا التكوين في الملحق. يمكننا استخدام حد اختبار منخفض قدره 2000 نظرًا لأن الأبجدية المدخلة صغيرة، مما يجعل الاختبار أسهل.

> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk -queries 2000

WolfSSL 4.0.0 باستخدام PSK

بالنسبة لـ WolfSSL نقدم تكوين PSK حيث يجب أن ينتهي التعلم بسرعة نسبية.

> java -jar target/dtls-fuzzer.jar @args/wolfssl-4.0.0/learn_wolfssl-4.0.0_psk_rwalk -queries 2000

GnuTLS 3.6.7 مع تعطيل مصادقة العميل

أنتج إصدار GnuTLS الأحدث الذي قمنا بتحليله نماذج جميلة ومدمجة. للأسف، أدى تمكين مصادقة العميل إلى زيادة حادة في عدد الاختبارات المطلوبة. نقترح تكوينًا يعطلها لتقصير وقت التعلم:

> java -jar target/dtls-fuzzer.jar @args/gnutls-3.6.7/learn_gnutls-3.6.7_all_cert_none_rwalk_incl -queries 2000

Scandium PSK (قبل إصلاحات الأخطاء)

تظهر نسخة منقحة من النموذج الذي تم الحصول عليه لهذا التكوين في الورقة البحثية. يكشف النموذج عن أخطاء مهمة، لكن للأسف، التجربة طويلة. لا ينبغي تشغيل التجربة بالتوازي مع تجارب لا تتضمن Scandium أو JSSE. الأمر:

> java -jar target/dtls-fuzzer.jar @args/scandium-2.0.0/learn_scandium-2.0.0_psk_rwalk -queries 2000

JSSE 12.0.2 مع المصادقة المطلوبة

تظهر نسخة منقحة من النموذج الذي تم الحصول عليه لهذا التكوين في الورقة البحثية. يكشف النموذج عن أخطاء مهمة. لا ينبغي تشغيل التجربة بالتوازي مع تجارب لا تتضمن Scandium أو JSSE. لاحظ أن التعلم لـ JSSE لا ينتهي / لا يتقارب، مما يبني فرضيات مع المزيد والمزيد من الحالات. لذا قمنا بتكوين تجارب JSSE لتنتهي تلقائيًا بعد يوم واحد (يومين في الورقة البحثية). الأمر لتبادل مفاتيح RSA:

> java -jar target/dtls-fuzzer.jar @args/jsse-12/learn_jsse-12_rsa_cert_req_rwalk_incl 

بدلاً من التعلم الشاق، قد نرغب ببساطة في اختبار ما إذا كان يمكن إتمام المصافحة في هذا الإعداد دون إرسال أي رسائل شهادة. يمكن القيام بذلك عن طريق تشغيل:

> java -jar target/dtls-fuzzer.jar @args/jsse-12/learn_jsse-12_rsa_cert_req_rwalk_incl -test examples/tests/rsa

تحليل النتائج

بمجرد الانتهاء من التعلم، الأشياء التي يجب تحليلها في دليل الإخراج هي:

• 'statistics.txt'، إحصائيات التجربة مثل العدد الإجمالي للاختبارات، وقت التعلم؛
• 'nondet.log'، سجلات السلوك غير الحتمي الذي تم مواجهته، إذا سار كل شيء على ما يرام يجب أن يكون هذا فارغًا؛
• 'learnedModel.dot'، النموذج المُتعلم (أو الفرضية النهائية) الذي تم إنشاؤه عند الإنهاء الناجح؛
• 'hyp[0-9]+.dot'، فرضيات وسيطة؛
• 'error.msg'، في حالة حدوث شيء سيء تسبب في توقف التعلم. يتم إنشاؤه أيضًا إذا انتهت مهلة تجربة التعلم.

تصور النموذج

يمكن تصور النموذج المُتعلم بصيغة .dot باستخدام مكتبة graphviz، عن طريق التحويل إلى .pdf:

> dot -Tpdf learnedModel.dot  > learnedModel.pdf

لسوء الحظ، مع نمو النماذج في الحجم، تصبح ملفات .pdf التي تم إنشاؤها باستخدام هذه الطريقة صعبة القراءة بشكل متزايد. لذلك قمنا بتطوير / استخدام / استيراد نصوص برمجية للتقليم يتم الوصول إليها بواسطة 'trim_model.sh'. يوفر البرنامج النصي معلومات الاستخدام عن طريق تشغيل:

> bash trim_model.sh

ننصح باستخدام البرنامج النصي في أبسط صوره، وهو:

> bash trim_model.sh learnedModel.dot 

يقوم البرنامج النصي بما يلي:

1. ضغط تسميات الحالات والمدخلات / المخرجات
2. تلوين المسارات المؤدية إلى إتمام المصافحة
   • يجب على المستخدم بعد ذلك تحديد ما إذا كانت المصافحات قانونية بالنظر إلى التكوين
3. دمج مجموعات من 3 انتقالات أو أكثر تربط نفس حالات الحالة، ولها نفس المخرجات ولكن مدخلات مختلفة، تحت المدخل "Other"
4. (اختياريًا) تقليم الحالات التي لم يعد من الممكن إتمام المصافحة منها (مفيد بشكل خاص لـ JSSE)
5. (اختياريًا) وضع الانتقالات التي تربط نفس الحالات على حافة واحدة

تتطلب (5) تثبيت مكتبة mypydot Python 3 المخصصة الموجودة في 'experiments\scripts'. تستخدم جميع الخطوات الأخرى 'sed' العادي بالإضافة إلى مكتبة dot-trimmer Java. يتم تضمين ملف .jar لهذه المكتبة في 'experiments\scripts'.

دليل عام لـ dtls-fuzzer

عرض صفحة المساعدة

قم بتشغيل:

> java -jar target/dtls-fuzzer.jar -help

تعلم تطبيقات DTLS

قد يكون عدد الخيارات مربكًا. لتعلم تطبيق خادم DTLS، يحتاج المرء فقط إلى تحديد عدد قليل من الخيارات، وهي "-connect ip_address:port" وهو العنوان الذي يستمع إليه خادم DTLS قيد التشغيل. يتم تعيين جميع الخيارات الأخرى إلى قيم افتراضية، بما في ذلك الأبجدية.

تشغيل تعلم واحد

لتشغيل تعلم لخادم محلي موجود مثلاً يستمع على المنفذ 20000، قم بتشغيل:

> java -jar target/dtls-fuzzer.jar -connect localhost:20000

من المحتمل أن تكون هناك مشكلات مع هذا النوع من التعلم. يتطلب التعلم القدرة على إعادة تعيين الخادم بعد كل اختبار. بعض الخوادم تحمل بعض الحالة من اختبار إلى آخر. قد يؤدي هذا إلى عدم الحتمية أثناء التعلم، وبالتالي فإن النهج الأفضل هو تشغيل مؤشر ترابط خادم جديد في كل اختبار باستخدام أمر محدد. يتم قتل مؤشر ترابط الخادم بمجرد تشغيل الاختبار، مما يضمن إعادة تعيين صحيحة. مثال لـ OpenSSL:

> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -cmd "openssl s_server -accept 20000 -dtls1_2"

مع وجود العديد من المعلمات، يمكن أن تصبح الأوامر طويلة جدًا. يستخدم dtls-fuzzer JCommander لتحليل الوسائط، والذي يمكنه أيضًا قراءة المعلمات من ملف. انتقل إلى 'experiments/args' للحصول على أمثلة على الوسائط. لتزويد dtls-fuzzer بملف وسائط، قم بتوفيره كمعامل مسبوق بـ "@". يمكنك أيضًا إضافة وسائط صريحة أخرى إلى الأوامر (والتي ستستبدل تلك الموجودة في ملف الوسائط)

> java -jar target/dtls-fuzzer.jar @arg_file ...وسائط مستبدلة...

دفعة التعلم

لتشغيل دفعة من عمليات التعلم، يمكن استخدام البرنامج النصي 'launcher.py' في 'experiments/scripts'. بشرط وجود دليل يحتوي على ملفات وسائط، ستقوم الأداة بتشغيل عملية تعلم لكل ملف وسائط.

> python3 experiments/scripts/launcher.py --jar target/dtls-fuzzer.jar --args args_folder

تشغيل مجموعة اختبار

قبل تشغيل تجارب التعلم، من المفيد التحقق من صحة ضبط الوسائط، خاصة معلمات التوقيت. لتحقيق هذه الغاية، يمكن لـ dtls-fuzzerr تنفيذ مجموعة اختبار مخصصة (مجموعة من الاختبارات) على SUT، وتقديم ملخص للمخرجات. يمكن أيضًا استخدام هذه الوظيفة عند تشخيص تجارب التعلم الفاشلة، أي معرفة الخطأ الذي حدث.

لتشغيل مجموعة الاختبار على خادم باستخدام الأبجدية الافتراضية، يمكنك تشغيل:

> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file

للحصول على أمثلة على ملفات الاختبار، انتقل إلى 'examples/tests'. يتكون ملف الاختبار من قائمة مدخلات مفصولة بأسطر جديدة. يتم فصل الاختبارات بأسطر جديدة فارغة. نهاية كل اختبار هي إما نهاية الملف، أو سطر جديد فارغ. يتم استخدام "#" للتعليق على سطر.

إذا كان لديك نموذج / مواصفة، يمكنك أيضًا تشغيل مجموعة الاختبار ومقارنة المخرجات مع تلك الموجودة في المواصفة.

> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file -specification model

عدد مرات تشغيل الاختبارات قابل للتكوين بواسطة المعلمة '-times'، والتي تكون قيمتها الافتراضية 1. يساعد ضبطها على رقم مرتفع في اكتشاف عدم الحتمية في تكوينات التعلم، من خلال مقارنة مخرجات كل اختبار.

> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file -times 10

أخيرًا، إذا كان لديك ملف وسائط لتجربة تعلم، يمكنك استخدامها لتشغيل الاختبارات على SUT المعني عن طريق إضافة وسائط الاختبار اللازمة:

> java -jar target/dtls-fuzzer.jar @learning_arg_file -test test_file