OpenVPN मा dh none सँग RSA प्रमाणपत्रले काम गर्न सक्छ?

यहाँ RSA भनेको प्रमाणपत्रको छेउमा dh none भन्ने सर्भर कन्फिगरेसन छ, साथै यीमध्ये एउटा पक्कै गलत हुनुपर्छ भन्ने पिरलो शङ्का। केही पनि गलत छैन। प्रमाणपत्रले हस्ताक्षर गर्छ र प्रमाणित गर्छ; कुञ्जी-आदानप्रदानले साझा रहस्य स्थापना गर्छ। यी एउटै ह्यान्डशेकका दुई फरक काम हुन्, र TLS ले RSA प्रमाणपत्रलाई अस्थायी दीर्घवृत्तीय-वक्र सम्झौता प्रयोग गर्ने ह्यान्डशेक प्रमाणित गर्न दिन्छ।

भ्रम सामान्यतया माइग्रेसन मार्गदर्शिकासँग आउँछ। त्यसले DH प्यारामिटर फाइललाई dh none ले बदल्न भन्छ, पाठकले प्रमाणपत्र दीर्घवृत्तीय-वक्र प्रमाणपत्र नभएको देख्छ, र दुवै तथ्यलाई विरोधाभास मानिन्छ।

दुई सेटिङ किन सम्बन्धित देखिन्छन्

OpenVPN को पुरानो कन्फिगरेसनले DH प्यारामिटर फाइल माग्थ्यो किनभने सीमित-क्षेत्र Diffie-Hellman लाई दुवै पक्ष सहमत हुने डोमेन प्यारामिटर चाहिन्छ। dh निर्देशले त्यो फाइलतर्फ देखाउँथ्यो। जब तैनाती ECDH मा जान्छ, प्यारामिटरहरू त्यसको सट्टा नाम दिइएको वक्रबाट आउँछन्, र फाइल अब आवश्यक पर्दैन, जुन dh none ले व्यक्त गर्छ।

प्रमाणपत्रहरू छुट्टै अक्ष हुन्। तिनीहरूले सर्भरको पहिचान प्रमाणित गर्ने सार्वजनिक कुञ्जी र हस्ताक्षर बोक्छन्, र त्यो कुञ्जी सत्र कुञ्जी कसरी सहमत हुन्छ भन्ने कुराबाट स्वतन्त्र रूपमा RSA वा दीर्घवृत्तीय वक्र हुन सक्छ। कुञ्जी सम्झौताका लागि ECDHE र प्रमाणीकरणका लागि RSA प्रयोग गर्ने ह्यान्डशेक सामान्य र व्यापक रूपमा तैनात छ।

नामकरणले अतिव्यापनलाई अझ बिगार्छ। दीर्घवृत्तीय वक्र ECDHE र ECDSA दुवै सूट नाममा देखिन्छ, त्यसैले वक्र उल्लेख गर्ने कुनै पनि जडानमा वक्र प्रमाणपत्र हुनैपर्छ भन्ने अनुमान गर्न सजिलो छ। त्यस्तो होइन।

TLS 1.2 सूट नाम सही रूपमा पढ्ने

ECDHE-RSA-AES256-GCM-SHA384 लिनुहोस्। पहिलो टोकन कुञ्जी-आदानप्रदान परिवार हो: अस्थायी दीर्घवृत्तीय-वक्र Diffie-Hellman। दोस्रो प्रमाणीकरण परिवार हो: RSA। बाँकीले रेकर्ड संरक्षण र ह्यान्डशेकमा प्रयोग हुने ह्यास वर्णन गर्छ।

ECDHE-ECDSA सूटले त्यही कुञ्जी-आदानप्रदान परिवार फरक प्रमाणीकरण विधिसँग प्रयोग गर्छ, त्यसैले यसलाई दीर्घवृत्तीय-वक्र प्रमाणपत्र चाहिन्छ। DHE-RSA सूटले RSA प्रमाणीकरणसँग सीमित-क्षेत्र अस्थायी Diffie-Hellman प्रयोग गर्छ, र त्यसलाई साँच्चै DH प्यारामिटर चाहिन्छ।

सूट नाम बायाँबाट दायाँ पढ्नुहोस् र प्रत्येक भागलाई त्यसको काममा तोक्नुहोस्। टोकनहरू अलग भएपछि प्रश्न «मेरो प्रमाणपत्र dh none सँग मिल्छ?» बाट «मेरो सर्भरले कुञ्जी-आदानप्रदानमा DH फाइल नचाहिने सूटलाई अनुमति दिन्छ?» मा बदलिन्छ।

dh none ले वास्तवमा के अक्षम गर्छ

dh none सर्भरलाई सीमित-क्षेत्र DH प्यारामिटर फाइल लोड नगर्न भन्छ। यसले प्रमाणीकरण, प्रमाणपत्र प्रमाणीकरण वा TLS आफैं अक्षम गर्दैन। तर यसले सहमत कुञ्जी-आदानप्रदान ती प्यारामिटर नचाहिने हुनुपर्ने माग गर्छ, जसको व्यवहारमा अर्थ ECDHE सूट वा TLS 1.3 ह्यान्डशेक हो।

यही मागबाट बिग्रन आउँछ। यदि सर्भरको TLS सिफर नीति DHE सूटमा सीमित छ, वा क्लाइन्टले ती मात्र दिन्छ, प्यारामिटर फाइल हटाउँदा कुनै उपयोगी कुञ्जी-आदानप्रदान विधि बाँकी रहँदैन र ह्यान्डशेक असफल हुन्छ। त्रुटि सामान्यतया नियन्त्रण-च्यानल ह्यान्डशेकका क्रममा, कुनै पनि प्रयोगकर्ता प्रमाणीकरणअघि देखिन्छ। हराएको फाइललाई दोष दिनुअघि सिफर सूची पढ्नुहोस्।

दीर्घवृत्तीय-वक्र पक्षमा, वक्र सर्भरको TLS कन्फिगरेसनले छान्छ, र OpenVPN पुराना शाखामा यसलाई छान्ने विकल्प दिन्छ। TLS 1.3 ले समूह वार्तालापलाई प्रोटोकलभित्रै सम्हाल्छ र DH फाइललाई पटक्कै हेर्दैन।

dh none आफैंमा सुरक्षा घटुवा होइन। आदानप्रदानको बल त्यसपछि वास्तवमा सहमत वक्र र सूटमा निर्भर हुन्छ, त्यसैले अर्को कदम हराएको फाइल होइन, पक्षहरूले के छाने भन्ने हेर्नु हो।

सम्पादनअघि वार्तालाप पुष्टि गर्ने

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

यदि त्यसले TLS 1.2 सँग ECDHE-RSA सूट र RSA प्रमाणपत्र देखाउँछ भने, संयोजन ठ्याक्कै dh none ले अपेक्षा गरेको हो, र सुधार्न केही छैन। यदि त्यसले DHE सूट वा साझा सिफर बिनाको ह्यान्डशेक असफलता देखाउँछ भने, समाधान सिफर नीति वा क्लाइन्टको क्षमतामा छ, प्रमाणपत्रमा होइन।

तपाईंले समर्थन गर्न चाहनुभएको सबैभन्दा पुरानो क्लाइन्ट परीक्षण गर्नुहोस्, किनभने हालको क्लाइन्टले TLS 1.3 मा सहमत हुन सक्छ जबकि पुरानो TLS 1.2 सूटमा सीमित हुन्छ। यदि सबैभन्दा पुरानो क्लाइन्टमा कुनै अतिव्यापन छैन भने, अनुमति दिइएका सूट विस्तार गर्नुहोस् वा त्यो अन्त्य बिन्दु अपग्रेड गर्नुहोस्।

ह्यान्डशेक असफलता छल्न प्रमाणपत्र प्रमाणीकरण बन्द नगर्नुहोस्। असफलताले पक्षहरू कुञ्जी-आदानप्रदानमा सहमत हुन नसकेको बताउँछ, र प्रमाणीकरण बन्द गर्दा सम्झौता नसमाधान गरी पहिचानको ग्यारेन्टी हट्छ।

जाँचसूची: प्रमाणपत्र RSA हो, ECDHE सूटलाई अनुमति छ, लगले त्यो सूट देखाउँछ, र समर्थित सबैभन्दा पुरानो क्लाइन्टले पनि त्यसमा सहमत हुन्छ? चारै हो भने, dh none आफ्नो काम गरिरहेको छ।