HTTPS ट्रैफ़िक डिटेक्शन पर Wehe की कमियों को समझना

लेखक: (1) विनोद एस. खांडकर और मंजेश के. हनवाल, औद्योगिक इंजीनियरिंग और परिचालन अनुसंधान भारतीय प्रौद्योगिकी संस्थान बॉम्बे, मुंबई, भारत और {vinod.khandkar, mhanawal}@iitb.ac.in. लिंक की तालिका सार एवं परिचय संबंधित कार्य और पृष्ठभूमि टीडी डिटेक्शन माप सेटअप विकास में चुनौतियाँ केस स्टडी : Wehe - मोबाइल वातावरण के लिए TD डिटेक्शन टूल HTTPS ट्रैफ़िक पर Wehe की कमी HTTPS ट्रैफ़िक का TD पता लगाना निष्कर्ष एवं संदर्भ V. HTTPS ट्रैफ़िक पर WEHE की कमी हमारा अध्ययन विभिन्न नेटवर्क कॉन्फ़िगरेशन में रीप्ले किए गए ट्रैफ़िक स्ट्रीम, टीडी डिटेक्शन और परिचालन व्यवहार्यता के लिए नेटवर्क प्रतिक्रियाओं को मान्य करने पर केंद्रित है। जबकि परिचालन व्यवहार्यता को Google Playstore पर सार्वजनिक रूप से उपलब्ध "Wehe" Android ऐप का उपयोग करके मान्य किया जाता है, TD डिटेक्शन परिदृश्यों को सैद्धांतिक तर्कों का उपयोग करके मान्य किया जाता है। नेटवर्क प्रतिक्रियाओं के सत्यापन के लिए प्राप्त ट्रैफ़िक स्ट्रीम के बैंडविड्थ विश्लेषण की आवश्यकता होती है। इस विश्लेषण के लिए सत्यापन परिदृश्य के अनुसार किए गए विशिष्ट रीप्ले के लिए नेटवर्क लॉग की आवश्यकता होती है। डिवाइस और कई अन्य स्ट्रीमिंग पर किया गया रीप्ले चित्र 6. पुनः चलाए गए YouTube ट्रैफ़िक का ट्रैफ़िक वर्गीकरण समानांतर में चलने वाली सेवाएँ एक ऐसा ही परिदृश्य है। Wehe ऐप परीक्षण पूरा होने के बाद रिप्ले के लिए तुरंत ऐसे नेटवर्क लॉग प्रदान नहीं करता है। इसलिए, हमने उपयोगकर्ता-क्लाइंट और सर्वर को लागू किया जो Wehe टूल के व्यवहार की नकल करता है। हम Wehe को मान्य करने के लिए चित्र 3 में दिखाए गए सेटअप के समान क्लाइंट-सर्वर सेटअप का उपयोग करते हैं। वर्तमान सेटअप में, हमने मूल सेवा के सर्वर को रीप्ले सर्वर से बदल दिया है। उपयोगकर्ता क्लाइंट और रीप्ले सर्वर एक वाणिज्यिक ट्रैफ़िक शेपर के माध्यम से जुड़े हुए हैं। इसके अलावा, हमारे सेटअप में समानांतर रूप से कई रीप्ले करने का प्रावधान है। हमारे सत्यापन सेटअप को प्रशासनिक चैनलों और ओवरहेड्स, जैसे साइड-चैनल की आवश्यकता नहीं है। हमारे सर्वर को हमेशा एकल-उपयोगकर्ता क्लाइंट का समर्थन करने की आवश्यकता होती है। कई क्लाइंट वाले परिदृश्यों का सत्यापन संबंधित ट्रैफ़िक विश्लेषण की आवश्यकता न होने के कारण सीधे Wehe ऐप का उपयोग करता है। इस अनुभाग का अनुस्मारक सत्यापन के परिणामों का वर्णन करता है। A. मूल सेवा का ट्रैफ़िक अनुकरण नेटवर्क प्रतिक्रियाएँ नेटवर्क मिडिल-बॉक्स द्वारा सही जांच ट्रैफ़िक वर्गीकरण के आधार पर नेटवर्क नीतियों के अनुप्रयोग पर निर्भर हैं जैसा कि सेक्शन III-A में उल्लेख किया गया है। हमने एक वाणिज्यिक ट्रैफ़िक शेपर का उपयोग करके वेहे के अनुकरणीय ट्रैफ़िक के वर्गीकरण को मान्य किया। अनुकरणीय ट्रैफ़िक का वर्गीकरण वाणिज्यिक ट्रैफ़िक शेपर के उपयोगकर्ता इंटरफ़ेस का उपयोग करके देखा जाता है। प्रयोग करने के लिए, YouTube एप्लिकेशन डेटा को कमर्शियल ट्रैफ़िक शेपर के माध्यम से रीप्ले सर्वर से उपयोगकर्ता-क्लाइंट तक रीप्ले किया जाता है। डेटा ट्रांसफर के दौरान, कमर्शियल ट्रैफ़िक शेपर की उपयोगकर्ता-इंटरफ़ेस विंडो में YouTube ट्रैफ़िक की मौजूदगी देखी जाती है। हमने इंटरनेट ब्राउज़र का उपयोग करके YouTube ट्रैफ़िक को भी एक्सेस किया और ट्रैफ़िक शेपर के वर्गीकरण परिणाम को हमारे ट्रैफ़िक वर्गीकरण अवलोकनों को आधार बनाने के लिए देखा। चित्र 6 में ट्रैफ़िक वर्गीकरण परिणाम दिखाया गया है, जैसा कि YouTube सर्वर से इंटरनेट ब्राउज़र का उपयोग करके सीधे एक्सेस किए गए ट्रैफ़िक के लिए कमर्शियल ट्रैफ़िक शेपर की उपयोगकर्ता-इंटरफ़ेस विंडो द्वारा दिखाया गया है। यह बाईं विंडो में इंटरनेट गतिविधि और दाईं विंडो में संबंधित ट्रैफ़िक का वर्गीकरण दिखाता है। चित्र 6(ए) दर्शाता है कि इंटरनेट ब्राउज़र का उपयोग करके एक्सेस किया गया ट्रैफ़िक सही ढंग से YouTube के रूप में वर्गीकृत किया गया है। यह वाणिज्यिक ट्रैफ़िक शेपर के इच्छित व्यवहार के अनुरूप है। चित्र 6(बी) उपयोगकर्ता-क्लाइंट का उपयोग करके एक्सेस किए गए ट्रैफ़िक के लिए ट्रैफ़िक वर्गीकरण परिणाम दिखाता है। यह संचार लिंक पर YouTube ट्रैफ़िक के किसी भी हस्तांतरण का सबूत दिखाता है। इसके अलावा, यह HTTPS ट्रैफ़िक के समान ट्रैफ़िक को वर्गीकृत करता है। इस प्रयोग के परिणाम से पता चलता है कि सभी नेटवर्क मिडलबॉक्स वेहे के रिप्ले किए गए ट्रैफ़िक को सही ढंग से वर्गीकृत नहीं कर सकते हैं। बी. रिप्ले स्क्रिप्ट में डेटा दर का प्रभाव जांच ट्रैफ़िक जनरेशन नेटवर्क प्रतिक्रिया को प्रभावित करता है जैसा कि टीडी डिटेक्शन एल्गोरिदम द्वारा अपेक्षित है। हम मूल सेवा से ट्रैफ़िक ट्रेस का उपयोग रीप्ले स्क्रिप्ट बनाने के लिए करते हैं जो एप्लिकेशन डेटा और उसके समय संबंध को संरक्षित करते हैं। इस रीप्ले स्क्रिप्ट का उपयोग मूल नेटवर्क पर और उन नेटवर्क पर भी किया जाता है जो अलग-अलग भौगोलिक रूप से स्थित हैं। चूंकि ट्रैफ़िक शेपिंग दर एक ही सेवा के लिए नेटवर्क में भिन्न होती है (जैसा कि [32] में उल्लेख किया गया है), रीप्ले स्क्रिप्ट में संरक्षित ट्रैफ़िक दर वर्तमान में विचार किए गए नेटवर्क की ट्रैफ़िक शेपिंग दर से भिन्न हो सकती है। रीप्ले ट्रैफ़िक दर ट्रैफ़िक शेपिंग दर से कम हो सकती है। यदि रीप्ले स्क्रिप्ट की ट्रैफ़िक दर नेटवर्क की शेपिंग दर से कम है, तो वेहे कार्यप्रणाली ट्रैफ़िक विभेदन का पता नहीं लगाती है क्योंकि यह ट्रैफ़िक स्ट्रीम को प्रभावित नहीं करती है। ऐसी रीप्ले स्क्रिप्ट ऐसे नेटवर्क पर ट्रैफ़िक शेपिंग का कभी पता नहीं लगा सकती हैं। इस प्रकार वेहे टूल की टीडी पहचान क्षमता रीप्ले स्क्रिप्ट की जांच ट्रैफ़िक दर द्वारा सीमित है। C. पोर्ट संख्या 80 का उपयोग नेटवर्क प्रतिक्रियाएँ जांच ट्रैफ़िक के बारे में नेटवर्क मध्य-बक्से की धारणा से प्रेरित होती हैं (अनुभाग III-A देखें)। रीप्ले स्क्रिप्ट अनुप्रयोगों के मूल नेटवर्क ट्रेस में डेटा को सुरक्षित रखती है। मूल अनुप्रयोग सर्वर सादे-पाठ डेटा के लिए पोर्ट 80 और एन्क्रिप्टेड डेटा स्थानांतरण के लिए पोर्ट 443 का उपयोग करते हैं। Wehe रीप्ले स्क्रिप्ट सीधे अनुप्रयोग के नेटवर्क ट्रेस से एन्क्रिप्टेड डेटा का उपयोग करती है और इसे पोर्ट 80 पर संचारित करती है। ऐसे मामलों में, Wehe को उम्मीद है कि एन्क्रिप्टेड अनुप्रयोग डेटा का उपयोग करके नेटवर्क उपकरणों द्वारा इसकी मूल रीप्ले ट्रैफ़िक स्ट्रीम को सही ढंग से वर्गीकृत किया जाएगा। पोर्ट 80 पर ऐसे डेटा का होना असंभव है क्योंकि एन्क्रिप्टेड ट्रैफ़िक डेटा नेटवर्क डिवाइस के सामने अपनी पहचान उजागर नहीं कर सकता है। D. ट्रैफ़िक लोड नियंत्रित नेटवर्क व्यवहार ध्यान दें कि संसाधनों की कमी नेटवर्क को कुछ नेटवर्क ट्रैफ़िक प्रबंधन लागू करने के लिए प्रेरित करती है, विशेष रूप से भारी नेटवर्क लोड परिदृश्यों में, जो इसके नेटवर्क पर सभी सक्रिय सेवाओं के लिए फायदेमंद होते हैं, जैसे, QoS-आधारित ट्रैफ़िक प्रबंधन (अनुभाग III-A देखें)। हमने ऐसे ट्रैफ़िक प्रबंधन के प्रभाव को मान्य किया चित्र 7. वेहे के ट्रैफ़िक स्ट्रीम प्रदर्शन पर नेटवर्क लोड का प्रभाव नियंत्रण और मूल रिप्ले दोनों के प्रदर्शन पर। सत्यापन सत्यापन के लिए निम्नलिखित तीन परिदृश्यों का उपयोग करता है, • नेटवर्क पर किसी भी लोड के बिना केवल वेहे की दो ट्रैफ़िक धाराओं को पुनः चलाना (चित्र 7 (ए)) • समानांतर रूप से चलने वाली एक अतिरिक्त स्ट्रीमिंग सेवा के साथ वेहे की तीन ट्रैफ़िक धाराओं को पुनः चलाना (चित्र 7(बी)) • समानांतर रूप से चलने वाली 2 अतिरिक्त स्ट्रीमिंग सेवाओं के साथ वेहे की तीन ट्रैफ़िक धाराओं को पुनः चलाना (चित्र 7 (सी)) चित्र 7(ए) में प्रदर्शन दर्शाते हैं कि वीहे उपकरण द्वारा उत्पन्न ट्रैफ़िक स्ट्रीम का प्रदर्शन बिना किसी अतिरिक्त नेटवर्क लोड स्थितियों के समान है। जैसे-जैसे नेटवर्क लोड बढ़ता है, नियंत्रण रीप्ले का प्रदर्शन मूल रीप्ले से और उच्च स्तर पर विचलित होता है (चित्र 7(बी))। जबकि नियंत्रण रीप्ले का प्रदर्शन निचले स्तर पर मूल रीप्ले से और भी विचलित होता है, दो मूल रीप्ले अभी भी समान प्रदर्शन दिखाते हैं जैसा कि चित्र 7(सी) में दिखाया गया है। यह वीहे उपकरण की नियंत्रण रीप्ले के विभेदित न होने की अपेक्षा को अमान्य करता है। यह कुल बैंडविड्थ के कारण टीडी का पता लगाने के उपकरण के दावे को भी अमान्य करता है। ई. हम एक ही सब-नेट के भीतर कई डिवाइसों से परीक्षण करते हैं साइड-चैनल को एक साथ कई उपयोगकर्ता ग्राहकों का समर्थन करने के लिए वेहे डिज़ाइन में पेश किया गया है। साइड चैनल उपयोगकर्ता-क्लाइंट और आईपी पते और बंदरगाहों के संयोजन के बीच मैपिंग की पहचान करने में भी सहायता करते हैं। यह NAT [33] का उपयोग करने वाले नेटवर्क के मामले में उपयोगी है। हमने दो अलग-अलग परीक्षणों का उपयोग करके कई ग्राहकों और NAT-सक्षम नेटवर्कों के लिए वेहे के समर्थन को मान्य किया। सबसे पहले, हमने एक ही सबनेट के भीतर से दो उपयोगकर्ता-ग्राहकों को जोड़ा, यानी, एक ही सार्वजनिक आईपी पते को साझा करने वाले क्लाइंट। एक परीक्षण में, वेहे उपकरण दोनों डिवाइसों पर एक ही सेवा का परीक्षण करता है, उदाहरण के लिए, दोनों डिवाइसों पर वेहे ऐप यूट्यूब के लिए परीक्षण करता है। परिणाम से पता चलता है कि वेहे परीक्षण केवल एक डिवाइस पर समाप्त हो गया, जबकि वेहे ऐप अचानक दूसरे डिवाइस पर बंद हो गया। हमने पाया कि एक डिवाइस पर Wehe परीक्षण ठीक से पूरा हो जाता है, जबकि दूसरे डिवाइस पर Wehe परीक्षण स्क्रीन पर एक त्रुटि फेंकता है, जो उपयोगकर्ता को सूचित करता है कि एक अन्य क्लाइंट पहले से ही परीक्षण कर रहा है, जैसा कि Fig. 9 में दिखाया गया है। ये परीक्षण दिखाते हैं कि यदि वे समान IP पता साझा करते हैं तो Wehe कई डिवाइस का समर्थन नहीं करता है। जबकि एक साइड-चैनल सीधे Wehe रिप्ले सर्वर से जुड़े उपयोगकर्ता-क्लाइंट से प्रत्येक रिप्ले को पहचानने के लिए उपयोगी है, यह NAT उपकरणों का उपयोग करने वाले नेटवर्क में उपयोगी नहीं है। NAT के मामले में कई उपयोगकर्ता एक ही IP पता साझा करते हैं। ऐसे मामलों में, साइड चैनल प्रत्येक रिप्ले रन को किसी क्लाइंट के लिए विशिष्ट रूप से मैप नहीं कर सकता है। यह प्रति रिप्ले सर्वर और ISP और एप्लिकेशन प्रति Wehe के उपयोग को केवल एक सक्रिय क्लाइंट तक सीमित करता है। F. टीडी डिटेक्शन पर डिवाइस नेटवर्क लोड का प्रभाव वेहे का रीप्ले सर्वर एप्लिकेशन डेटा ट्रांसफ़र के बीच उसी समय का उपयोग करता है जो मूल एप्लिकेशन ट्रैफ़िक के लिए होता है। ऐसी ट्रांसमिशन रणनीति से उपलब्ध बैंडविड्थ को समाप्त नहीं करने की उम्मीद की जाती है। इसलिए उपलब्ध बैंडविड्थ से ऊपर ट्रैफ़िक दर के ओवरशूटिंग के कारण स्रोत दर मॉड्यूलेशन का प्रभाव असंभव है। यह बनाता है, मूल और नियंत्रण रीप्ले समान ट्रैफ़िक प्रदर्शन दिखाते हैं जब तक कि नेटवर्क नीतियों यानी टीडी द्वारा जानबूझकर संशोधित न किया जाए। फिर भी, यह अपेक्षा हमेशा पूरी नहीं होती है क्योंकि ट्रैफ़िक डेटा दर को वीहे परीक्षण करते समय उपयोगकर्ता डिवाइस पर नेटवर्क लोड द्वारा मॉड्यूलेट किया जाता है। इस तरह की गड़बड़ी विसंगति पैदा करती है क्योंकि जांच ट्रैफ़िक पर समय-भिन्न वर्तमान नेटवर्क लोड का प्रभाव भी समय-भिन्न होता है और हमेशा एक जैसा नहीं हो सकता है। वीहे की बैक-टू-बैक रीप्ले रणनीति यह सुनिश्चित करती है कि दोनों (मूल और नियंत्रण रीप्ले) जांच ट्रैफ़िक स्ट्रीम वर्तमान नेटवर्क लोड से अलग-अलग प्रभावित होती हैं। डिवाइस की तरफ़ ऐसे नेटवर्क लोड के तहत, सेवाओं द्वारा उपलब्ध बैंडविड्थ को समाप्त न करने की धारणा टीडी डिटेक्शन के लिए इसके लाभों के साथ-साथ मौजूद नहीं रहती है। टीडी डिटेक्शन से पहले ऐसे भ्रामक कारकों को सामान्य करना आवश्यक है (धारा III-B देखें)। यह पेपर CC 4.0 लाइसेंस के अंतर्गत है। arxiv पर उपलब्ध