यहाँ सबैभन्दा बढी हानि दुई विश्वासले गर्छन्: स्व-हस्ताक्षरित 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 को आफ्नै जारी र रद्द गर्ने जीवनचक्र हुन्छ। निजी कुञ्जी चुहिएमा त्यही प्रमाणपत्रको प्रतिलाई फेरि विश्वास गर्दा केही पनि सुधार हुँदैन; पहिचान बदल्नुपर्छ।

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

सम्बन्धित लेखहरू