के सर्भर प्रमाणपत्र शृंखलाले ग्राहकको ट्रस्ट स्टोर अतिक्रमण गर्न सक्छ?

ब्राउजरले शृंखला पूर्ण भएको साइटमा प्रमाणपत्र चेतावनी देखाउँछ, र पहिलो प्रवृत्ति सर्भर सुधार्ने हुन्छ। सामान्यतया सर्भरले ठ्याक्कै गर्नुपर्ने कुरा प्रस्तुत गरिरहेको हुन्छ। ग्राहकले कुन एङ्कर स्वीकार्ने भनेर निर्णय गर्छ, र मध्यस्थ प्रमाणपत्रको कुनै पनि व्यवस्थाले जडानको अर्को छेउबाट त्यो निर्णय बदल्न सक्दैन। प्रमाणपत्र समस्या जस्तो देखिने धेरैजसो कुरा यही सीमाले व्याख्या गर्छ।

प्रमाणीकरण ग्राहकमा चल्छ, ग्राहकका एङ्करसँग

पथ प्रमाणीकरणले प्रस्तुत प्रमाणपत्रहरू लिन्छ र प्रमाणीकरण प्रणालीसँग पहिले नै भएको विश्वास एङ्करसम्म शृंखला बनाउँछ। RFC 5280 ले त्यो मोडेल वर्णन गर्छ, र एङ्कर छनोट सर्भरमा नभई स्थानीय कार्यान्वयनमा राख्छ। एप्लिकेसनले त्यसमाथि आफ्नै नीति थप्न सक्छ: पिन गरिएको कुञ्जी, उद्यम ट्रस्ट स्टोर, वा अझ कडा पहिचान जाँच। सर्भरले पठाउने प्रमाणपत्र सूची त्यो प्रक्रियालाई दिइएको प्रमाण हो, उसलाई कहिल्यै निर्देशन होइन।

त्यसैले पूर्ण शृंखलाले सर्भरसँग टुक्राहरू छन् भनी प्रमाणित गर्छ। ग्राहकले ती स्वीकार्नेछ भनी प्रमाणित गर्दैन।

सर्भरले वास्तवमा के पठाउँछ हेर्न, यो चलाउनुहोस् openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts र आउटपुटमा प्रमाणपत्रहरू गन्नुहोस्। त्यहाँ अपूर्ण शृंखला सर्भर-पक्षको सुधार हो। पूर्ण शृंखलाले प्रश्न ग्राहक र उसका एङ्करकहाँ सार्छ, जहाँ सर्भरको मत छैन।

TLS निरीक्षणले वास्तवमा के बदल्छ

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

व्यवस्था जानाजान र स्थानीय हो। मूल सर्भरको शृंखलामा केही पनि अव्यवस्थित ब्राउजरलाई वैकल्पिक पहिचान स्वीकार्न बाध्य पार्न सक्दैन, र त्यसमा केही पनि व्यवस्थित यन्त्रलाई त्यसो गर्नबाट रोक्दैन।

VPN अन्त्य HTTPS डिक्रिप्शन होइन

VPN तहले ग्राहक र गेटवेबीच प्याकेट बोक्छ। यसलाई हटाउनु, वा यसको कन्फिगरेसन पढ्नु, भित्रको HTTPS पेलोड खोल्दैन।

TLS सत्र अझै ब्राउजर र वेब सर्भरबीच, त्यही प्रमाणीकरण नियमसँग चल्छ, जबसम्म केहीले यसलाई स्पष्ट रूपमा अन्त्य गर्दैन। दुई तह मिसाउँदा VPN प्रशासकसँग प्रमाणपत्र उपलब्ध गराउन अनुरोध उत्पन्न हुन्छ, जबकि विचाराधीन प्रमाणपत्र निरीक्षण प्रोक्सीको वा साइटकै हुन्छ। कुनै पनि ट्रस्ट स्टोर बदल्नुअघि कुन घटकले प्रमाणपत्र प्रस्तुत गरिरहेको छ सोध्नुहोस्।

तपाईंले नियन्त्रण गर्ने घटकमा अपेक्षाहरू तय गर्नुहोस्

यदि तपाईं एप्लिकेसन र यसको ग्राहक सञ्चालन गर्नुहुन्छ भने, अपेक्षित सेवा पहिचान, स्वीकृत जारीकर्ता र कुनै पनि पिनिङ वा ग्राहक प्रमाणीकरण आवश्यकता सँगै परिभाषित गर्नुहोस्। वैध प्रमाणपत्र परिवर्तन अवरोध नहोस् भनेर नवीकरण र पुनर्प्राप्तिको योजना बनाउनुहोस्। यदि तपाईं केवल सार्वजनिक सर्भर सञ्चालन गर्नुहुन्छ भने, कुन प्रमाणीकरण आवश्यक छ र कुन ग्राहक वातावरण समर्थन गर्नुहुन्छ कागजात गर्नुहोस्। मनपर्ने शृंखला पठाउनु अपरिचितको यन्त्र प्रमाणित गर्दैन।

व्यवस्थित उपकरणमा, असंगतिलाई एप्लिकेसन र नेटवर्क मालिकमार्फत समाधान गर्नुहोस्। प्रमाणीकरण बन्द गर्नु, अव्याख्यायित मूल थप्नु, वा निरीक्षण नीति उछिन्ने प्रयास गर्नुले इच्छित समकक्ष सम्बन्ध स्थापित गर्दैन।

नतिजा सफा ग्राहक प्रोफाइलमा परीक्षण गर्नुहोस्, पहिले नै अपवाद थपिएको मेसिनमा होइन। नयाँ यन्त्रले के अनुभव गर्नेछ भनी देखाउने यही एक मात्र जाँच हो।