WSS टनल का एन्क्रिप्शन ऐप में नहीं, TLS टर्मिनेटर पर रुकता है

सुरक्षित WebSocket के अंदर ले जाई गई टनल में ठीक उतना ही एन्क्रिप्शन होता है जितना क्लाइंट ने उसमें डाला हो, इससे ज्यादा नहीं। wss:// स्कीम कहती है कि TLS एक हॉप पर एक कनेक्शन की रक्षा करता है। यह इस बारे में कुछ नहीं कहती कि WebSocket संदेशों के अंदर के बाइट अलग से सुरक्षित हैं या नहीं, और यही अंतर तय करता है कि जब बीच में कुछ TLS खत्म करता है तो आपका ट्रैफ़िक कौन पढ़ सकता है।

दो परतें जो एक जैसी दिखती हैं

सुरक्षित WebSocket वह TLS है जिसके ऊपर WebSocket हैंडशेक किया जाता है, जैसा RFC 6455 अपने कनेक्शन और सुरक्षा अनुभागों में बताता है। TLS परत सर्वर को प्रमाणित करती है और स्ट्रीम को एन्क्रिप्ट करती है, फिर WebSocket परत वह फ्रेम करती है जो एप्लिकेशन भेजने का फैसला करता है।

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

डिज़ाइन A: परिवहन ही एकमात्र एन्क्रिप्शन है

सरल डिज़ाइन में, क्लाइंट कच्चे IP पैकेट लेता है और उन्हें WebSocket संदेशों में लपेट देता है। अंदर कुछ एन्क्रिप्ट नहीं होता, इसलिए TLS सत्र रखने वाला घटक सादा-पाठ पेलोड पढ़ता है। जब वह घटक आपका अपना टनल सर्वर हो, तो यही इच्छित अंतिम बिंदु है और डिज़ाइन सुसंगत है, क्योंकि सर्वर को ट्रैफ़िक हर हाल में दिखना था।

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

डिज़ाइन B: पेलोड अपनी कुंजियाँ ले जाता है

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

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

VPN लेबल, परिचित क्लाइंट आइकन या मार्केटिंग पेज इस बात का प्रमाण नहीं हैं कि यह डिज़ाइन मौजूद है। पेलोड प्रारूप पढ़ना प्रमाण है।

पता लगाएँ कि सादा पाठ वास्तव में कहाँ दिखता है

URL स्कीम आपको एक तथ्य देती है, इसलिए बाकी इंटरफ़ेस से लें। नीचे दी गई जाँचें क्रम से चलाएँ, क्योंकि हर एक अगली को सँकरा करती है:

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

बाहरी कनेक्शन से शुरू करें। TLS पोर्ट पर एक लंबा चलने वाला TCP सत्र वही है जैसा WebSocket वाहक दिखता है, और असंबंधित होस्ट पर दूसरा सत्र गहराई में देखने से पहले व्याख्या का हकदार है। फिर क्लाइंट पर टनल इंटरफ़ेस खोजें, क्योंकि tun या tap डिवाइस बताता है कि क्लाइंट एक एप्लिकेशन स्ट्रीम को प्रॉक्सी करने के बजाय IP पैकेट संभाल रहा है।

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

उस भरोसे की समीक्षा करें जो आपने वास्तव में दिया

स्थापित कॉर्पोरेट रूट प्रमाणपत्र क्लाइंट के भरोसा भंडार के बारे में तथ्य है, यह नहीं कि कोई प्रॉक्सी क्या लॉग करता या निरीक्षण करता है। तैनात नीति और वास्तविक कनेक्शन पथ स्थापित करें, न कि CA की उपस्थिति से व्यवहार का अनुमान लगाएँ।

प्रबंधित उपकरणों पर व्यवस्थापक से पूछें कि कौन-सा घटक TLS खत्म करता है, क्लाइंट पिन किए गए प्रमाणपत्र को सत्यापित करता है या सार्वजनिक को, और पेलोड प्रारूप क्या है। वे तीन जवाब ऐसी खोज देते हैं जिसे आप बाद में उचित ठहरा सकें।

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