OpenVPN EC विरुद्ध ED: यी नामहरू बलको भर्याङ किन होइनन्
EC, ED, ECDHE र auth फरक प्रश्नको जवाफ दिन्छन्। केही तुलना वा सम्पादन गर्नुअघि OpenVPN प्रोफाइललाई हरेक नामले गर्ने कामअनुसार मिलाउनुहोस्।
एउटै प्रोफाइलमा ec, ed, ecdh, ecdsa, auth र TLS साइफरको सूची छेउछाउ राख्नुहोस्, अनि फाइल छ स्थितिको बल-डायलजस्तो देखिन थाल्छ। तर त्यस्तो होइन। हरेक नामले फरक प्रश्नको जवाफ दिन्छ, र तीमध्ये एउटामा फरक पर्ने दुई प्रोफाइल अनिवार्य रूपमा एकअर्काभन्दा बलियो वा कमजोर हुँदैनन्। नामहरूलाई तिनले गर्ने कामअनुसार मिलाउन करिब पाँच मिनेट लाग्छ र चलिरहेको कन्फिगरेसनमा मानिसहरूले गर्ने धेरैजसो नराम्रो सम्पादन रोक्छ।
तलको मिलाइ आफैँ अलमलबाट सुरु हुन्छ, त्यसपछि बाहिरतिर प्रोफाइलका ती भागतिर जान्छ जसले तपाईंको ट्राफिक वास्तवमा केले जोगाउँछ भन्ने निर्धारण गर्छ। हरेक खण्डले एक-एक गलत पढाइ लिन्छ र नाम साँच्चै केसँग जोडिएको छ देखाउँछ।
दुई अक्षर, दुई फरक प्रश्न
सबैभन्दा धेरै बहस ल्याउने जोडी EC र ED हो, र बहसले प्रायः ती एउटै प्रश्नका प्रतिद्वन्द्वी उत्तर हुन् भन्ने मान्छ। ती एउटै अक्षमा पनि छैनन्। EC गणितको एउटा परिवार वर्णन गर्छ: दीर्घवृत्तीय वक्र क्रिप्टोग्राफी, जहाँ सुरक्षा ठूलो परिमित क्षेत्रबाट नभई वक्रमा रहेको विविक्त लगारिदमको कठिनाइबाट आउँछ।
ED त्यही परिवारभित्रको वक्र आकार वर्णन गर्छ। Twisted Edwards वक्रहरू गति र धेरै कार्यान्वयन त्रुटिविरुद्धको प्रतिरोधका लागि छानिएको निरूपण हो, र Ed25519 मानिसहरूले सामान्यतया भन्न खोज्ने नाम हो। वक्र दीर्घवृत्तीय वक्र क्रिप्टोग्राफीको प्रतिस्पर्धी होइन; यो दीर्घवृत्तीय वक्र लेख्ने एउटा तरिका हो। ED लाई "नयाँ, बलियो EC" भनेर पढ्नु पहिलो गलत मोड हो, र त्यसपछिको सबै त्यही दिशामा गलत हुने सम्भावना हुन्छ।
हस्ताक्षर गर्नु र आदानप्रदान गर्नु अलग काम हुन्
परिवारको प्रश्न टुंगिएपछि बाँकी नामहरू दुई स्तम्भमा बाँडिन्छन् जुन कहिल्यै एकअर्काको ठाउँ लिँदैनन्। एउटा स्तम्भले हस्ताक्षर गर्छ, अर्कोले साझा गोप्यमा सहमति जनाउँछ।
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA र ECDSA दुवैले हस्ताक्षर गर्छन्, तर ती फरक कुञ्जी ढाँचा भएका फरक योजना हुन्, त्यसैले एउटाका लागि जारी गरिएको प्रमाणपत्र अर्कोका रूपमा प्रयोग गर्न मिल्दैन। EdDSA थोरै वक्रहरूको समूहका लागि परिभाषित छ; P-256 तीमध्ये एउटा होइन, त्यसैले P-256 प्रमाणपत्र ECDSA ले जाँचिन्छ र कहिल्यै Ed25519 ले जाँचिँदैन।
आदानप्रदान स्तम्भमा EdDH नामको कुनै समानता छैन। Curve25519 कुञ्जीमा हुने क्षणिक सहमति X25519 हो, र त्यो विशेष वक्रसहितको ECDH हो, P-256 मा जस्तै। Ed25519 ले कडाइका साथ हस्ताक्षर योजना जनाउँछ, तर दुई वक्र सम्बन्धित भएकाले नाम आदानप्रदानका लागि पनि खुकुलो रूपमा प्रयोग हुन्छ: हस्ताक्षरका लागि प्रयोग हुने Edwards रूप र X25519 का लागि प्रयोग हुने Montgomery रूप एउटै आधार समूह वर्णन गर्छन्।
EC प्रोफाइलमा dh फाइल किन हुँदैन
dh फाइलमा परिमित क्षेत्र Diffie-Hellman का लागि पहिल्यै बनाइएका प्यारामिटर हुन्छन्, र ती प्यारामिटर हुनुको कारण ठूलो अभाज्य सङ्ख्या र जेनेरेटर कतैबाट आउनुपर्ने हुनु हो। दीर्घवृत्तीय वक्रको आदानप्रदानलाई ती चाहिँदैन: नाम दिइएको वक्र नै प्यारामिटर समूह हो, र दुवै पक्षलाई त्यो पहिल्यै थाहा छ। EC प्रोफाइलले निर्देश छोड्न सक्नुको पूरै कारण यही हो।
अन्यथा आधुनिक देखिने प्रोफाइलमा दुई अवस्थाले अझै dh लाइन बनाउँछन्। पहिलो परिमित क्षेत्रका समूहबारे साँच्चै वार्ता गर्ने दोस्रो श्रोता वा पुरानो साथी हो। दोस्रो RSA युगको टेम्प्लेटबाट प्रतिलिपि गरिएको र कहिल्यै नहटाइएको बाँकी पाठ हो। आदानप्रदानका लागि वक्र नाम दिएर पनि 2048-बिट dh फाइल लोड गर्ने प्रोफाइल त्यसका कारण बढी सुरक्षित हुँदैन; यसले नचाहिने वस्तु बोकिरहेको हुन्छ।
TLS 1.3 ले नामबाट कुञ्जी आदानप्रदान हटायो
TLS_AES_256_GCM_SHA384 लाई TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 सँग तुलना गर्नुहोस्, छोटो नाम घटुवा जस्तो देखिन्छ। यो पुनर्नामकरण हो, र कारण संरचनागत छ: TLS 1.3 ले स्थिर RSA र परिमित क्षेत्रको Diffie-Hellman कुञ्जी आदानप्रदान हटायो, त्यसैले क्षणिक दीर्घवृत्तीय वक्र आदानप्रदान बाँकी रहेको एकमात्र गैर-PSK विकल्प हो। हरेक सूटमा त्यसको नाम लिनु त्यही तथ्य दर्जनौं पटक दोहोर्याउनु हो।
प्रमाणपत्रको प्रकार नामबाट सम्बन्धित कारणले हरायो। 1.3 मा प्रमाणपत्रले ह्यान्डशेकको हस्ताक्षर प्रमाणित गर्छ, कुञ्जी सम्झौता होइन, त्यसैले यसले अब सूट छान्दैन। त्यसैले कन्फिगरेसनमा 1.3 का लागि छुट्टै साइफर सूची छ: सूटहरू पुनर्नामकरण र पुनर्संरचना भए, कमजोर बनाइएनन्।
एउटा परिणाम स्पष्ट रूपमा भन्न लायक छ। ECDHE कुञ्जी आदानप्रदानको एल्गोरिदम हो र कहिल्यै साइफर होइन। "दीर्घवृत्तीय" भनेर वर्णन गरिएको सूटले दुई पक्ष साझा कुञ्जीसम्म कसरी पुगे भन्नेबारे केही भन्छ, र त्यसपछि पेलोड कसले इन्क्रिप्ट गर्छ भन्नेबारे केही भन्दैन।
auth ले प्याकेट प्रमाणित गर्छ, पेलोड होइन
auth निर्देशले प्याकेट प्रमाणित गर्ने HMAC डाइजेस्ट छान्छ, र यसको ऐतिहासिक पूर्वनिर्धारित मान SHA1 हो। गैर-AEAD डेटा साइफरसँग OpenVPN ले इन्क्रिप्ट गरिएको पाठमा डाइजेस्ट गणना गरी थप्छ, यो इन्क्रिप्ट-त्यसपछि-MAC मिलाइ हो जसले प्याडिङसँग छेडछाड अव्यावहारिक बनाउँछ।
यहाँको भ्रम के हो भने auth लाई SHA512 सम्म उठाउँदा सुरुङ बलियो हुन्छ। यसले इन्क्रिप्शनको बल बढाउँदैन, र सहमति भएको डेटा साइफर AES-256-GCM जस्तो AEAD मोड भए डाइजेस्ट डेटा प्याकेटमा पटक्कै लागू हुँदैन। GCM ट्यागले तिनलाई पहिल्यै प्रमाणित गर्छ, र auth मान नियन्त्रण च्यानलको HMAC र अझै प्रयोग हुने कुनै पनि गैर-AEAD साइफरका लागि रहन्छ।
त्यसैले निर्देश महत्त्वपूर्ण छ, तर फाइलमा यसको स्थानले सङ्केत गरेभन्दा साँघुरो ठाउँमा महत्त्वपूर्ण छ। वास्तवमा कुन साइफर सहमति भयो भनी जाँच्दा यो पटक्कै लागू हुन्छ कि हुँदैन थाहा हुन्छ।
प्रोफाइल स्तम्भअनुसार पढ्नुहोस्, क्रमअनुसार होइन
तीन प्रश्नले तहहरू सफा छुट्याउँछन्, र हरेकको जवाफ सहमति भएको सत्रको फरक भागले दिन्छ। कुन साइफरले पेलोड जोगाउँछ? कुन ट्याग वा डाइजेस्टले हरेक प्याकेटको जमानत दिन्छ, र प्रयोग भइरहेको साइफरलाई त्यो पटक्कै चाहिन्छ? कसको प्रमाणपत्रले ह्यान्डशेक बन्द गर्यो, र नियन्त्रण च्यानल थप रूपमा tls-auth वा tls-crypt ले सुरक्षित छ?
EC वा ED लेबलमा कुनै कुराले ती तीनमध्ये एउटै निर्धारण गर्दैन, र सूटको नाम एक्लैले पनि तिनमध्ये कुनै निर्धारण गर्दैन। सहमति भएको नतिजा नै एकमात्र प्रमाण हो, त्यसैले शब्दावलीबाट बल अनुमान गर्नुको सट्टा त्यही पढ्नुहोस्:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logपहिलो आदेशले तपाईंको प्रमाणपत्रले वास्तवमा कुन हस्ताक्षर योजना प्रयोग गर्छ भनी बताउँछ, र तपाईं ECDSA चलाउनुहुन्छ कि Ed25519 भन्ने थाहा पाउने एकमात्र भरपर्दो तरिका त्यही हो। दोस्रोले ग्राहकले सत्रका लागि अभिलेख गरेको नियन्त्रण च्यानलको लाइन देखाउँछ, जसमा TLS संस्करण र यो जुन सूटमा अडियो त्यो पनि समावेश छ। प्रोफाइलको सम्पादन यी दुई आउटपुटमध्ये एउटाले पनि न्यायोचित ठहराउन सकिँदैन भने, त्यो सम्भवतः गुणको होइन नामको परिवर्तन हो।