स्व-हस्ताक्षरित VPN प्रमाणपत्र: इसका क्या अर्थ है और यह किस पर भरोसा करता है

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

प्रमाणपत्र भरोसे का स्टोर नहीं है

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

स्वीकृति कहीं और से आती है: एक CA फ़ाइल जिसकी ओर आप क्लाइंट को निर्देशित करते हैं, एक फिंगरप्रिंट जिसे आप हाथ से मिलाते हैं, या एक रूट जो पहले से उस स्टोर में बैठा है जिसे क्लाइंट पढ़ता है। परिनियोजन पूरी तरह स्वस्थ हो सकता है जबकि उसका प्रमाणपत्र हर सार्वजनिक परीक्षण में विफल होगा। सिस्टम बंडल के विरुद्ध openssl verify अज्ञात जारीकर्ता की रिपोर्ट करेगा, और वह रिपोर्ट सही है, कोई खराबी नहीं।

OpenVPN का ca विकल्प ऐप-सीमित भरोसे का सबसे स्पष्ट मामला है। वह फ़ाइल उन एंकरों के नाम देती है जिन्हें क्लाइंट स्वीकार करेगा, और इसमें एक निजी CA हो सकता है या छोटे परिनियोजन में सर्वर का अपना स्व-हस्ताक्षरित प्रमाणपत्र हो सकता है। संस्करण 2.6 CA फ़ाइल वितरित करने के बजाय SHA-256 फिंगरप्रिंट पिन करने के लिए --peer-fingerprint भी स्वीकार करता है। WireGuard और भी दूर है: इसमें कोई प्रमाणपत्र ही नहीं है, केवल प्रत्येक सहकर्मी के लिए एक स्थिर सार्वजनिक कुंजी, इसलिए स्व-हस्ताक्षर का प्रश्न इस पर लागू नहीं होता।

आप भरोसा कहाँ स्थापित करते हैं यह तय करता है कि उसे कौन विरासत में पाएगा

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

Debian या Ubuntu पर, /usr/local/share/ca-certificates/ में फ़ाइल डालना और update-ca-certificates चलाना सिस्टम-व्यापी बंडल बदल देता है। Windows पर, certutil -addstore -f Root मशीन स्टोर में लिखता है और उन्नत प्रॉम्प्ट चाहता है, जबकि -user जोड़ना इसके बजाय वर्तमान उपयोगकर्ता के स्टोर को लक्षित करता है; दोनों विनिमेय नहीं हैं। Firefox अपना NSS डेटाबेस रखता है, इसलिए OS-स्तर का आयात वहाँ कभी नहीं दिख सकता।

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

आप अभी भी सार्वजनिक CA के बिना एन्क्रिप्ट कर रहे हैं

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

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

जारीकर्ता पर भरोसा करना नाम की जाँच को नहीं छोड़ता

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

OpenVPN विभाजन को दृश्य बनाता है। verify-x509-name अपेक्षित विषय को name, name-prefix या subject मिलान के माध्यम से पिन करता है। remote-cert-tls server आवश्यक करता है कि सहकर्मी का प्रमाणपत्र सर्वर प्रमाणपत्र के रूप में उपयोगी हो, जो केवल-क्लाइंट प्रमाणपत्र को अस्वीकार करता है, भले ही जारीकर्ता पर भरोसा हो। दोनों में से कोई भी सेटिंग CA फ़ाइल भेजने से प्रतिस्थापित नहीं होती।

कुछ भी तय करने से पहले प्रमाणपत्र की जाँच करें:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName दिखाता है कि किसने इसे जारी किया, किन नामों के लिए और कब तक।
• openssl verify -CAfile ca.crt server.crt जाँचता है कि आप जो श्रृंखला भेजने की सोच रहे हैं वह वास्तव में पत्ते को मान्य करती है।
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error वेब पोर्टल जैसे TLS अंतिम बिंदुओं के लिए काम करता है; 1194 पर OpenVPN प्रोटोकॉल सादा TLS प्रवाह नहीं है, इसलिए वह परीक्षण वहाँ लागू नहीं होता।

समाप्त तिथि वाला, उस नाम के लिए subjectAltName के बिना जिससे आप जुड़ते हैं, या serverAuth उपयोग के बिना प्रमाणपत्र इस बात की परवाह किए बिना विफल होता है कि एंकर कितनी सावधानी से स्थापित किया गया था।

एक स्वीकार करने से पहले पाँच जाँच

फिंगरप्रिंट की तुलना ऐसे चैनल पर करें जो वह कनेक्शन न हो जिसे आप ठीक करने की कोशिश कर रहे हैं: एक कंसोल, आपके पास पहले से मौजूद इंस्टॉलर, एक हस्ताक्षरित कॉन्फ़िगरेशन फ़ाइल। सर्वर पर openssl x509 -in server.crt -noout -fingerprint -sha256 और क्लाइंट लॉग में वही मान यह जानने के लिए पर्याप्त हैं कि आप एक ही वस्तु देख रहे हैं।

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

अंत में, बदलाव की योजना बनाएँ। पिन किया गया प्रमाणपत्र या फिंगरप्रिंट प्रमाणपत्र बदलने पर उसी भरोसेमंद चैनल से अद्यतन होना चाहिए, और निजी CA का अपना जारी और निरस्तीकरण जीवनचक्र है। यदि निजी कुंजी लीक हो जाए, तो उसी प्रमाणपत्र की प्रति पर फिर से भरोसा करना कुछ ठीक नहीं करता; पहचान बदलनी ही होगी।

यदि कोई चेतावनी पाँचों जाँचों से बच निकले, तो उपयोगी प्रश्न यह नहीं है कि कौन सा बटन उसे शांत करता है, बल्कि यह है कि क्लाइंट वास्तव में कौन सा स्टोर पढ़ता है और वह रूट कहाँ से आया। उसका उत्तर दें, और आप जो आयात करने वाले हैं वह प्रतिक्रिया के बजाय निर्णय बन जाएगा।