क्या सर्वर प्रमाणपत्र श्रृंखला क्लाइंट के ट्रस स्टोर को बायपास कर सकती है?

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

सत्यापन क्लाइंट पर चलता है, क्लाइंट के एंकरों के साथ

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

इसलिए पूरी श्रृंखला सिद्ध करती है कि सर्वर के पास टुकड़े हैं। यह सिद्ध नहीं करती कि क्लाइंट उन्हें स्वीकार करेगा।

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

TLS निरीक्षण वास्तव में क्या बदलता है

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

व्यवस्था जानबूझकर और स्थानीय है। मूल सर्वर की श्रृंखला में कुछ भी अन-प्रबंधित ब्राउज़र को प्रतिस्थापित पहचान स्वीकार करने के लिए बाध्य नहीं कर सकता, और इसमें कुछ भी प्रबंधित उपकरण को ऐसा करने से नहीं रोकता।

VPN समाप्ति HTTPS डिक्रिप्शन नहीं है

VPN परत क्लाइंट और गेटवे के बीच पैकेट ले जाती है। उसे हटाना, या उसका कॉन्फ़िगरेशन पढ़ना, अंदर का HTTPS पेलोड उजागर नहीं करता।

TLS सत्र अभी भी ब्राउज़र और वेब सर्वर के बीच, उन्हीं सत्यापन नियमों के साथ चलता है, जब तक कुछ उसे स्पष्ट रूप से समाप्त न करे। दोनों परतों को मिलाना VPN व्यवस्थापक से प्रमाणपत्र देने का अनुरोध पैदा करता है, जबकि विचाराधीन प्रमाणपत्र किसी निरीक्षण प्रॉक्सी या साइट का ही होता है। कोई भी ट्रस स्टोर बदलने से पहले पूछें कि कौन-सा घटक प्रमाणपत्र प्रस्तुत कर रहा है।

जिस घटक को आप नियंत्रित करते हैं उसमें अपेक्षाएँ तय करें

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

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

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