WSS सुरुङको इन्क्रिप्सन एपमा नभई TLS टर्मिनेटरमा रोकिन्छ
एउटा wss:// URL ले एउटा हपमा TLS भएको प्रमाण दिन्छ। पेलोडको आफ्नै इन्क्रिप्सन छ कि छैन भन्ने क्लाइन्टले भित्र के राख्छ र त्यो 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 सुरक्षित छन्" टिक्दैन।