सर्व्हर प्रमाणपत्र शृंखला क्लायंटचे ट्रस्ट स्टोअर ओलांडू शकते का?

ब्राउझर अशा साइटवर प्रमाणपत्र चेतावणी दाखवतो जिची शृंखला पूर्ण आहे, आणि पहिली प्रवृत्ती सर्व्हर दुरुस्त करण्याची असते. सहसा सर्व्हर जे असावे तेच सादर करत असतो. क्लायंट कोणते अँकर स्वीकारायचे हे ठरवतो, आणि मध्यस्थ प्रमाणपत्रांची कोणतीही मांडणी जोडणीच्या दुसऱ्या टोकावरून हा निर्णय बदलू शकत नाही. प्रमाणपत्राची समस्या वाटणाऱ्या बहुतेक गोष्टी या सीमेमुळे समजतात.

प्रमाणीकरण क्लायंटवर चालते, क्लायंटच्या अँकरसह

मार्ग प्रमाणीकरण सादर केलेली प्रमाणपत्रे घेते आणि प्रमाणीकरण प्रणालीकडे आधीच असलेल्या विश्वास अँकरपर्यंत शृंखला तयार करते. RFC 5280 हे मॉडेल वर्णन करते, आणि अँकरची निवड सर्व्हरकडे नाही तर स्थानिक अंमलबजावणीकडे ठेवते. एखादे अनुप्रयोग त्यावर स्वतःचे धोरण जोडू शकते: पिन केलेली किल्ली, एंटरप्राइझ ट्रस्ट स्टोअर, किंवा अधिक कडक ओळख तपासणी. सर्व्हर पाठवतो ती प्रमाणपत्र यादी त्या प्रक्रियेला दिलेला पुरावा आहे, तिला कधीही सूचना नाही.

म्हणून पूर्ण शृंखला सिद्ध करते की सर्व्हरकडे तुकडे आहेत. क्लायंट ते स्वीकारेल हे ती सिद्ध करत नाही.

सर्व्हर प्रत्यक्षात काय पाठवतो हे पाहण्यासाठी, हे चालवा openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts आणि आउटपुटमधील प्रमाणपत्रे मोजा. तिथे अपूर्ण शृंखला ही सर्व्हरच्या बाजूची दुरुस्ती आहे. पूर्ण शृंखला प्रश्न क्लायंट आणि त्याच्या अँकरकडे हलवते, जिथे सर्व्हरला मत नाही.

TLS तपासणी प्रत्यक्षात काय बदलते

तपासणी उपकरण क्लायंटच्या बाजूचे TLS सत्र संपवते आणि खऱ्या सेवेसाठी वेगळे सत्र उघडते. नंतर क्लायंट उपकरणाचे प्रमाणपत्र प्रमाणित करतो, जे क्लायंट विश्वास ठेवतो त्या अँकरपर्यंत शृंखलाबद्ध असले पाहिजे. म्हणूनच व्यवस्थापित उपकरणांना उपकरण व्यवस्थापनाद्वारे तपासणी मूळ मिळते, आणि म्हणूनच ते नसलेले वैयक्तिक उपकरण चेतावणी दाखवते.

ही मांडणी जाणीवपूर्वक आणि स्थानिक आहे. मूळ सर्व्हरच्या शृंखलेत काहीही अ-व्यवस्थापित ब्राउझरला पर्यायी ओळख स्वीकारण्यास भाग पाडू शकत नाही, आणि त्यात काहीही व्यवस्थापित उपकरणाला तसे करण्यापासून रोखत नाही.

VPN समाप्ती म्हणजे HTTPS डिक्रिप्शन नाही

VPN स्तर क्लायंट आणि गेटवे दरम्यान पॅकेट नेतो. तो काढून टाकणे, किंवा त्याचे कॉन्फिगरेशन वाचणे, आतला HTTPS पेलोड उघड करत नाही.

TLS सत्र अजूनही ब्राउझर आणि वेब सर्व्हर दरम्यान, त्याच प्रमाणीकरण नियमांसह चालते, जोपर्यंत काही ते स्पष्टपणे संपवत नाही. दोन स्तर एकत्र करणे VPN प्रशासकाकडे प्रमाणपत्र पुरवण्याची विनंती निर्माण करते, तर विचाराधीन प्रमाणपत्र तपासणी प्रॉक्सीचे किंवा साइटचेच असते. कोणतेही ट्रस्ट स्टोअर बदलण्यापूर्वी कोणता घटक प्रमाणपत्र सादर करत आहे ते विचारा.

तुम्ही नियंत्रित करता त्या घटकात अपेक्षा ठेवा

तुम्ही अनुप्रयोग आणि त्याचा क्लायंट चालवत असाल, तर अपेक्षित सेवा ओळख, स्वीकारलेले जारीकर्ते आणि कोणतीही पिनिंग किंवा क्लायंट प्रमाणीकरणाची आवश्यकता एकत्र ठरवा. वैध प्रमाणपत्र बदल व्यत्यय होऊ नये म्हणून नूतनीकरण आणि पुनर्प्राप्तीची योजना करा. तुम्ही फक्त सार्वजनिक सर्व्हर चालवत असाल, तर कोणते प्रमाणीकरण आवश्यक आहे आणि कोणत्या क्लायंट वातावरणांना आधार देता ते दस्तऐवज करा. पसंतीची शृंखला पाठवणे अनोळखी व्यक्तीच्या उपकरणाचे प्रमाणन करत नाही.

व्यवस्थापित उपकरणांवर, विसंगती अनुप्रयोग आणि नेटवर्क मालकांमार्फत सोडवा. पडताळणी बंद करणे, अस्पष्ट मूळ जोडणे, किंवा तपासणी धोरण मागे टाकण्याचा प्रयत्न करणे हे इच्छित समवयस्क संबंध प्रस्थापित करत नाही.

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