TLS नियंत्रण चैनल के भीतर चलता है, पूरी सुरंग में नहीं

किसी VPN विवरण में TLS शब्द देखकर यह निष्कर्ष निकालना कि कोई वेब प्रॉक्सी इस ट्रैफ़िक को समझ लेगी, एक आम शॉर्टकट है। इस प्रोटोकॉल के भीतर सहकर्मी अपने स्वयं के पैकेट का आदान-प्रदान करते हैं, और TLS उस आदान-प्रदान के भीतर एक चैनल के हिस्से के रूप में चलता है। उपयोगकर्ता के लिए महत्वपूर्ण पेलोड एक अलग संदेश प्रारूप में जाता है, इसलिए दोनों कभी सामान्य HTTPS सत्र से मेल नहीं खाते।

लिफ़ाफ़ा पहले आता है

हर सुरंग पैकेट प्रोटोकॉल के अपने हेडर से शुरू होता है: संदेश प्रकार, एक कुंजी पहचानकर्ता और बाइट-स्ट्रीम परिवहन पर एक लंबाई उपसर्ग जो बताता है कि पैकेट कहाँ समाप्त होता है। जो पाठक उस लिफ़ाफ़े का विश्लेषण नहीं करता, वह नहीं जान सकता कि अगला फ़ील्ड कहाँ शुरू होता है।

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

वह रेखाचित्र एक नक्शा है, बाइट तालिका नहीं, क्योंकि सटीक फ़ील्ड संदेश प्रकार पर निर्भर करते हैं, हालाँकि पहला ऑक्टेट हमेशा ऑपकोड और कुंजी पहचानकर्ता को साथ में पैक करता है। पोर्ट नंबर से संदेश प्रकार का अनुमान लगाना ही वह तरीका है जिससे डिकोडर जो देखते हैं उसका गलत नामकरण करते हैं। निदान के लिए क्रम महत्वपूर्ण है: परिवहन, फिर प्रोटोकॉल लिफ़ाफ़ा, फिर दो प्रकार के काम में से एक। इससे आगे क्या आता है, इस पर कोई राय बनाने से पहले लिफ़ाफ़ा पढ़ें। गलत जगह से शुरू करने वाला डिकोडर आत्मविश्वासपूर्ण बकवास पैदा करता है।

विश्वसनीयता परत प्रोटोकॉल की ही है

नियंत्रण संदेशों को क्रमबद्ध, स्वीकृत डिलीवरी चाहिए, और प्रोटोकॉल इसे स्वयं स्वीकृतियों और पुनःप्रेषणों से प्रदान करता है। स्वीकृति अपने अलग संदेश के रूप में आ सकती है या किसी अन्य नियंत्रण संदेश के साथ यात्रा कर सकती है, जिससे एक साफ़ आदान-प्रदान की अपेक्षा करने वाले को ट्रेस अनियमित दिखते हैं।

लाभ यह है कि TLS हैंडशेक को विश्वसनीय वाहक मिलता है, भले ही बाहरी परिवहन UDP हो। लागत यह है कि एक डेटाग्राम उस बातचीत का केवल एक हिस्सा रख सकता है, इसलिए उसे स्वतंत्र TLS रिकॉर्ड मानने से बकवास पैदा होता है। पुनःसंयोजन प्रोटोकॉल परत पर ही होना चाहिए। इसीलिए कैप्चर किया गया पैकेट शायद ही कभी पूर्ण हैंडशेक चरण जैसा दिखता है।

बाहरी परिवहन को TCP में बदलने से यह परत हटती नहीं। विश्वसनीय परिवहन का अर्थ है प्रोटोकॉल स्तर पर कम पुनःप्रेषण, यह नहीं कि फ़्रेमिंग गायब हो जाए या ट्रैफ़िक HTTP बन जाए।

डेटा पैकेट अलग प्रारूप का उपयोग करते हैं

सत्र बनने के बाद उपयोगी पेलोड डेटा संदेशों के रूप में आता है जो आंतरिक IP पैकेट या Ethernet फ़्रेम ले जाते हैं। वे अपनी कुंजियों और अपनी प्रोसेसिंग से सुरक्षित होते हैं, और TLS लाइब्रेरी जिस किसी अर्थ में स्वीकार करे, वे TLS अनुप्रयोग रिकॉर्ड नहीं हैं।

यह अलगाव कॉन्फ़िगरेशन में दिखता है: नियंत्रण चैनल और डेटा चैनल की अलग सिफ़र सेटिंग्स होती हैं, इसलिए एक का नाम लेने वाली लॉग पंक्ति दूसरे के बारे में कुछ नहीं बताती। मज़बूत नियंत्रण सिफ़र को मज़बूत डेटा सिफ़र का प्रमाण मानना एक आम रिपोर्टिंग त्रुटि है।

संबंधित भ्रांति को भी स्पष्टीकरण से बाहर रखें। TLS सममित डेटा चैनल के बगल में बैठा सार्वजनिक-कुंजी चैनल नहीं है, क्योंकि कुंजियाँ स्थापित होने के बाद TLS स्वयं अपने रिकॉर्ड की सममित रूप से रक्षा करता है। असली अंतर भूमिका और पैकेट प्रारूप का है, यह नहीं कि हर पक्ष किस प्रकार का क्रिप्टोग्राफ़ी उपयोग करता है।

HTTPS प्रॉक्सी मदद क्यों नहीं कर सकती

जो प्रॉक्सी TLS समाप्त करती है, वह TLS रिकॉर्ड स्ट्रीम और फिर उसके भीतर अनुप्रयोग प्रोटोकॉल की अपेक्षा करती है। इस प्रोटोकॉल का नियंत्रण चैनल अपनी स्वयं की फ़्रेमिंग के भीतर, चारों ओर विश्वसनीयता परत के साथ ले जाया जाता है, इसलिए समाप्त करने वाली प्रॉक्सी उस फ़्रेमिंग को दूषित इनपुट के रूप में पढ़ती है।

एक पारदर्शी फ़ॉरवर्डर जो बाइट या डेटाग्राम को बिना व्याख्या किए आगे भेजता है, काम कर सकता है, बशर्ते वह स्ट्रीम को फिर से न लिखे या पुनःसंयोजित न करे। किसी भी मध्यस्थ के बारे में पूछा जाने वाला प्रश्न यह है कि क्या वह वास्तविक परिवहन और फ़्रेमिंग आगे भेजता है, न कि क्या वह कहीं TLS का समर्थन करता है। प्रॉक्सी नियमों पर एक शाम बिताने से पहले यह पूछें। यहाँ अधिकांश विफलताएँ वास्तुशिल्पीय हैं, कोई गुम सेटिंग नहीं।

किसी ट्रेस को सही ढंग से पढ़ना

पहले नियंत्रण आदान-प्रदान की अपेक्षा करें, फिर बहुत अधिक संख्या में डेटा संदेशों की, दोनों एक ही परिवहन साझा करते हैं। यदि नियंत्रण चरण पूरा हो जाए और डेटा चरण रुक जाए, तो दोष हैंडशेक का नहीं बल्कि कुंजियों, रूटिंग या डेटा पथ की फ़िल्टरिंग का है। कुछ डेटा संदेश कैप्चर करें और जाँचें कि वे क्लाइंट से निकलते भी हैं या नहीं। वह एक अवलोकन खोज को आधा कर देता है।

ऐतिहासिक कुंजी-विधि विवरण प्रोटोकॉल दस्तावेज़ में यह नहीं दर्शाते कि कोई दिया गया संस्करण अभी भी हर पुराने प्रारूप का समर्थन करता है। जिस संस्करण को आप चलाते हैं उसे जाँचें, फिर उस अनुच्छेद पर अपेक्षा न बनाएँ जो बताता है कि चीज़ें पहले कैसे काम करती थीं।