क्या 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 अपना काम कर रहा है।