
dtls-fuzzer DTLS सर्वर कार्यान्वयन के लिए एक प्रोटोकॉल-स्टेट-फज़र है।
dtls-fuzzer एक Java उपकरण है जो DTLS सर्वरों का प्रोटोकॉल स्थिति फज़िंग करता है। अधिक ठोस रूप से, यह निम्नलिखित कार्यक्षमता का समर्थन करता है:
dtls-fuzzer DTLS संदेशों को उत्पन्न/पार्स करने और स्थिति बनाए रखने के लिए TLS-Attacker का उपयोग करता है। इसके लिए, TLS-Attacker को DTLS के लिए समर्थन के साथ विस्तारित किया गया है। dtls-fuzzer TLS-Attacker के संस्करण 3.0b पर निर्भर करता है, जो DTLS संवर्धन को लागू करने वाला एक संस्करण है।
आर्टिफैक्ट में शामिल है:
dtls-fuzzer की रूट निर्देशिका में सबसे महत्वपूर्ण फ़ोल्डर हैं:
'experiments/results' में प्रायोगिक परिणाम शामिल हैं, जो कार्य का मुख्य आउटपुट हैं। विशेष रूप से
आउटपुट फ़ोल्डरों का नाम प्रयोग कॉन्फ़िगरेशन के आधार पर रखा गया है, अर्थात:
एक उदाहरण के रूप में, फ़ोल्डर का नाम 'jsse-12_rsa_cert_none_rwalk_incl' DTLS के JSSE 12 कार्यान्वयन पर एक प्रयोग को इंगित करता है, जिसमें RSA हैंडशेक करने के लिए इनपुट शामिल वर्णमाला का उपयोग किया गया है, क्लाइंट प्रमाणपत्र प्रमाणीकरण अक्षम है, परीक्षण एल्गोरिदम रैंडम वॉक है और पुनर्प्रेषण शामिल हैं।
एक आउटपुट फ़ोल्डर में शामिल है:
मूल्यांकनकर्ता जाँच सकता है (उदाहरण के लिए) कि 'included' में प्रायोगिक परिणाम तालिका 4 में प्रदर्शित के अनुरूप हैं, या तालिका 2 में परीक्षण किए गए कॉन्फ़िगरेशन भी 'all_ciphers' में दिखाई देते हैं। ध्यान दें कि पेपर में दिखाई देने वाले मॉडल महत्वपूर्ण छंटाई/ट्रिमिंग का परिणाम थे, जबकि आउटपुट फ़ोल्डरों में दिखाई देने वाले मॉडल अपरिवर्तित हैं।
dtls-fuzzer का मूल्यांकन करने के उद्देश्य के लिए निम्नलिखित चरणों का पालन करना आवश्यक है:
इस मूल्यांकन अनुभाग के बाद dtls-fuzzer का उपयोग करने पर एक मार्गदर्शिका दी गई है जो इसके मुख्य उपयोग मामलों का परिचय देती है।
dtls-fuzzer का परीक्षण Ubuntu 18.04 और Debian 9 Linux वितरणों पर किया गया है। यह किसी भी हाल के Linux वितरण पर काम करना चाहिए। अन्य प्लेटफार्मों के लिए समर्थन का परीक्षण नहीं किया गया है। यह मार्गदर्शिका एक Debian-आधारित वितरण (जिसमें 'apt-get' है) का उपयोग करने की मानती है।
एक Java 8 JDK (जावा डेवलपमेंट किट) वर्चुअल मशीन (VM) की आवश्यकता है। प्रयोग चलाने के लिए उपयोग किया गया संस्करण 1.8.0_222 है, हालाँकि बाद के Java 8 संस्करणों को भी काम करना चाहिए। ध्यान दें कि उपकरण Java 9 या बाद के संस्करणों पर नहीं बनता है। हम निर्भरता प्रबंधन/तैनाती के लिए maven ('mvn' उपयोगिता) पर भी निर्भर हैं।
हम पर्याप्त रूप से शक्तिशाली मशीन का उपयोग करने की सलाह देते हैं, अन्यथा संवेदनशील समय पैरामीटर जैसे प्रतिक्रिया प्रतीक्षा समय, बहुत कम हो सकते हैं, जिससे पेपर में प्राप्त से भिन्न आउटपुट प्राप्त हो सकते हैं। इससे भी बदतर, वे लर्निंग प्रयोगों को विफल कर सकते हैं। मूल प्रयोग एक मल्टी-कोर सर्वर पर चलाए गए थे, हालाँकि, हम उम्मीद करते हैं (हालाँकि पूरी तरह से परीक्षण नहीं किया गया है) कि i7 प्रोसेसर वाले डेस्कटॉप पर लर्निंग संभव होनी चाहिए। समय मापदंडों को तदनुसार ट्यून करने पर कमजोर सिस्टम पर भी लर्निंग संभव है। अंत में, .dot मॉडल को .pdf में निर्यात करके विज़ुअलाइज़ करने के लिए graphviz लाइब्रेरी स्थापित करने की आवश्यकता है। यह माना जाता है कि graphviz द्वारा प्रदान की गई 'dot' उपयोगिता सिस्टम PATH में स्थित है।
संक्षेप में, सलाह दी गई पूर्वापेक्षाएँ हैं:
dtls-fuzzer को Java 8 JDK (जावा डेवलपमेंट किट) की आवश्यकता है। यदि Java स्थापित नहीं है, तो हम OpenJDK कार्यान्वयन स्थापित करते हैं (Ubuntu पर 'apt-get' के माध्यम से), और इस उपधारा के शेष भाग को छोड़ सकते हैं।
> sudo apt-get install openjdk-8-jdk
यदि java का कोई संस्करण स्थापित है, तो हम चला कर जाँच सकते हैं कि यह कौन सा संस्करण है:
> java -version
संस्करण कोड 1.8 से शुरू होना चाहिए (जैसे 1.8.0_242), और वर्चुअल मशीन "Server VM" होनी चाहिए (यह दर्शाता है कि केवल रनटाइम वातावरण के बजाय पूर्ण JDK स्थापित है)। यदि ऐसा है, तो हम Java के साथ समाप्त हैं। यदि ऐसा नहीं है, तो हम जाँच सकते हैं कि Java 8 JDK हमारे प्लेटफ़ॉर्म पर स्थापित है लेकिन वर्तमान में चयनित नहीं है, चलाकर:
> 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' (इंटरप्रेटर) और 'javac' (कंपाइलर) द्वारा कौन सी Java VM चुनी गई है।
> 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
हम पहले 'prepare.sh' स्क्रिप्ट चलाते हैं जो dtls-fuzzer पर निर्भर लाइब्रेरीज़ स्थापित करती है, अर्थात् दो स्थानीय .jars और TLS-Attacker 3.0b। फिर हम उपकरण स्वयं स्थापित करते हैं। POSIX सिस्टम पर परिणामी कमांड होंगे:
> bash prepare.sh
> mvn clean install
इन चरणों का पालन करने पर, 'target' नामक एक निर्देशिका बनाई जानी चाहिए जिसमें 'dtls-fuzzer.jar' हो। यह हमारी निष्पादन योग्य लाइब्रेरी है। इस बिंदु से आगे यह माना जाता है कि कमांड dtls-fuzzer की रूट निर्देशिका से चलाए जाते हैं।
मान लीजिए कि हम केवल PSK (पूर्व-साझा कुंजी) का उपयोग करके OpenSSL 1.1.1b के लिए एक मॉडल उत्पन्न करना चाहते हैं। 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
यदि सब कुछ ठीक रहा, तो सर्वर ने "This is a hello message" प्रिंट किया होगा, जो हैंडशेक पूरा करने के बाद हम भेजते हैं। अपने सेटअप को कार्यशील जानते हुए, हम अब लर्निंग शुरू कर सकते हैं चलाकर:
> 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 सेट करने के लिए एक स्क्रिप्ट प्रदान करते हैं। यह स्क्रिप्ट स्रोत फ़ाइलें डाउनलोड करती है, कुछ निर्भरताएँ (jvm) स्थापित करती है और SUT बनाती है। जिन SUTs के लिए स्वचालित सेटअप प्रदान किया गया है, उन्हें देखने के लिए चलाएँ:
> bash setup_sut.sh
सेट अप करने के लिए, उदाहरण के लिए, Contiki-NG के tinydtls कार्यान्वयन को चलाएँ:
> bash setup_sut.sh ctinydtls
स्क्रिप्ट dtls-fuzzer की रूट निर्देशिका में दो फ़ोल्डर उत्पन्न करेगी।
दुर्भाग्य से, SUT सेटअप को स्वचालित करना एक जटिल प्रक्रिया है, इसलिए हम निम्नलिखित शॉर्टकट लेते हैं। Java SUTs (JSSE, Scandium) के लिए हम कार्यान्वयन नहीं बनाते हैं, इसके बजाय हम 'experiments/suts' निर्देशिका से संकलित .jars का उपयोग करते हैं। ध्यान दें कि इन Java SUTs (सर्वर अनुप्रयोगों) का स्रोत कोड सार्वजनिक रूप से ऑनलाइन उपलब्ध है, Scandium और JSSE देखें, जो PionDTLS के लिए भी मामला है। स्वचालित रूप से निर्भरताएँ स्थापित करने से 'sudo' पहुंच का संकेत मिल सकता है। यह GnuTLS के लिए होता है जो बाहरी लाइब्रेरीज़ जैसे nettle पर निर्भर करता है, और Eclipse के TinyDTLS के लिए, जो autoconf पर निर्भर करता है। अंत में, हम NSS और PionDTLS के लिए स्वचालित सेटअप/तर्क फ़ाइलें प्रदान नहीं करते हैं क्योंकि इन प्रणालियों के लिए सेटअप कितना जटिल है।
यदि सेटअप प्रक्रिया में चीजें काम करना बंद कर देती हैं, तो 'suts' फ़ोल्डर (या SUT के लिए विशिष्ट 'suts/SUT' फ़ोल्डर) को हटाना और सेटअप स्क्रिप्ट को फिर से चलाना समस्या को हल कर सकता है। साथ ही, निर्माण विफलता के मामले में, कार्यान्वयन का स्रोत कोड अभी भी 'suts' निर्देशिका में डाउनलोड किया जाना चाहिए। एक समाधान मैन्युअल रूप से कार्यान्वयन का निर्माण करना है। जब तक कार्यान्वयन बनाया गया है, हमारा सेटअप काम करना चाहिए।
हम यहाँ विभिन्न SUTs की निर्भरताओं का एक अपूर्ण वृक्ष देते हैं। इटैलिक में वे निर्भरताएँ हैं जिन्हें 'setup_sut.sh' 'sudo' पहुंच का उपयोग करके स्थापित करने का प्रयास करता है।
अब हम एक SUT कॉन्फ़िगरेशन सीखने के लिए तैयार हैं। विभिन्न SUT कॉन्फ़िगरेशन के लिए तर्क फ़ाइलें dtls-fuzzer की होम निर्देशिका में स्थित 'args' निर्देशिका में प्रदान की गई हैं। प्रत्येक तर्क फ़ाइल का नाम प्रयोग सेटअप (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' फ़ाइल के साथ अचानक समाप्ति हो सकती है। ऐसे मामलों में, दो समायोजन हैं जिन्हें ट्वीक किया जा सकता है:
इन पैरामीटरों को तर्क फ़ाइल में संबंधित सेटिंग्स को अधिलेखित करके समायोजित किया जा सकता है (संभवतः उच्च मान के साथ):
> 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) से अधिक चलाने से मशीन पर अतिरिक्त बोझ पड़ता है। यह आकस्मिक पोर्ट टकराव के कारण लर्निंग विफलता की संभावना भी बढ़ाता है। अधिकांश कॉन्फ़िगरेशन में, सर्वर लोकलहोस्ट पर कुछ हार्ड-कोडेड पोर्ट पर सुनने के लिए कॉन्फ़िगर किए गए हैं, 'args' में प्रदान किए गए कॉन्फ़िगरेशन विशिष्ट हार्ड-कोडेड पोर्ट का उपयोग करते हैं। JSSE और Scandium कॉन्फ़िगरेशन के लिए, सेटअप अलग है। प्रत्येक परीक्षण पर, SUT एक गतिशील रूप से चुने गए पोर्ट पर सुनने वाला एक सर्वर लॉन्च करता है और dtls-fuzzer को TCP सॉकेट पर पोर्ट संचारित करता है। इसका लाभ यह है कि 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 कॉन्फ़िगरेशन का उपयोग OpenSSL के समान कारणों से किया जा सकता है। SUT धीमा होने के कारण प्रयोग पूरा होने में अधिक समय लगता है। सभी कुंजी विनिमय एल्गोरिदम का उपयोग करते हुए क्लाइंट प्रमाणपत्र प्रमाणीकरण अक्षम कॉन्फ़िगरेशन के लिए कमांड:
> java -jar target/dtls-fuzzer.jar @args/mbedtls-2.16.1/learn_mbedtls_all_cert_none_rwalk_incl -queries 5000
इस कॉन्फ़िगरेशन के लिए प्राप्त मॉडल का एक संशोधित संस्करण परिशिष्ट में दिखाई देता है। चूँकि इनपुट वर्णमाला छोटी है, हम 2000 की कम परीक्षण सीमा का उपयोग कर सकते हैं, जिससे परीक्षण आसान हो जाता है।
> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk -queries 2000
WolfSSL के लिए हम एक PSK कॉन्फ़िगरेशन प्रदान करते हैं जिसके लिए सीखना अपेक्षाकृत जल्दी समाप्त होना चाहिए।
> java -jar target/dtls-fuzzer.jar @args/wolfssl-4.0.0/learn_wolfssl-4.0.0_psk_rwalk -queries 2000
हमने जिस अधिक हालिया 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 या JSSE से संबंधित प्रयोगों के समानांतर नहीं चलाया जाना चाहिए। कमांड:
> java -jar target/dtls-fuzzer.jar @args/scandium-2.0.0/learn_scandium-2.0.0_psk_rwalk -queries 2000
इस कॉन्फ़िगरेशन के लिए प्राप्त मॉडल का एक संशोधित संस्करण पेपर में दिखाई देता है। मॉडल महत्वपूर्ण बगों को उजागर करता है। प्रयोग को 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
सीखना पूरा होने के बाद, आउटपुट निर्देशिका में विश्लेषण करने योग्य चीज़ें हैं:
.dot सीखे गए मॉडल को graphviz लाइब्रेरी का उपयोग करके, .pdf में रूपांतरण द्वारा विज़ुअलाइज़ किया जा सकता है:
> dot -Tpdf learnedModel.dot > learnedModel.pdf
दुर्भाग्य से, जैसे-जैसे मॉडल आकार में बढ़ते हैं, इस विधि से उत्पन्न .pdf पढ़ने में कठिन होते जाते हैं। इसलिए हमने प्रूनिंग स्क्रिप्ट विकसित/उपयोग/आयात की हैं जिन्हें 'trim_model.sh' द्वारा एक्सेस किया जाता है। स्क्रिप्ट चलाकर उपयोग की जानकारी प्रदान करती है:
> bash trim_model.sh
हम स्क्रिप्ट को उसके सबसे बुनियादी रूप में उपयोग करने की सलाह देते हैं, जो है:
> bash trim_model.sh learnedModel.dot
स्क्रिप्ट:
(5) के लिए 'experiments\scripts' में पाई जाने वाली कस्टम mypydot Python 3 लाइब्रेरी स्थापित करना आवश्यक है। अन्य सभी चरण सादे 'sed' और dot-trimmer Java लाइब्रेरी का उपयोग करते हैं। इस लाइब्रेरी का .jar 'experiments\scripts' में शामिल है।
चलाएँ:
> java -jar target/dtls-fuzzer.jar -help
विकल्पों की संख्या भारी हो सकती है। 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 ...overwriting params...
सीखने के रनों का एक बैच लॉन्च करने के लिए, 'experiments/scripts' में 'launcher.py' स्क्रिप्ट का उपयोग किया जा सकता है। तर्क फ़ाइलों वाली एक निर्देशिका प्रदान करने पर, उपकरण प्रत्येक तर्क फ़ाइल के लिए एक सीखने की प्रक्रिया लॉन्च करेगा।
> 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