OpenVPN मध्ये dh none सह RSA प्रमाणपत्र कार्य करू शकते का?
प्रमाणपत्राचा प्रकार आणि की-एक्स्चेंज गट हे TLS चे दोन वेगळे पर्याय आहेत. RSA प्रमाणपत्र ECDHE हँडशेक प्रमाणित करू शकते, म्हणून dh none ला EC प्रमाणपत्रांची गरज नाही.
येथे 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 आपले काम करत आहे.