CA बिना OpenVPN: peer-fingerprint ले सहकर्मीहरूलाई कसरी प्रमाणित गर्छ
फिंगरप्रिन्ट एउटा प्रमाणपत्र पिन गर्छ, साझा रहस्य होइन। डाइजेस्ट के समेट्छ, प्रत्येक पक्षले आफ्नो अनुमत सूची कसरी बनाउँछ र नवीकरणको लागत कति हुन्छ हेर्नुहोस्।
सानो तैनाती फिंगरप्रिन्टतिर जान्छ किनकि प्रमाणपत्र प्राधिकरण त्यस्तो पूर्वाधार जस्तो देखिन्छ जसलाई चलाउन कसैसँग समय छैन। सहज प्रवृत्ति उचित छ, तर मानिसहरूले त्यसको सट्टा लिने छोटो बाटो—एउटा डेटा-च्यानलको रहस्य दुवै छेउमा प्रतिलिपि गर्ने—त्यस्तो छैन। peer-fingerprint सेटअपले TLS संरचना अक्षुण्ण राख्छ: प्रत्येक पक्षसँग अझै आफ्नै निजी कुञ्जी र प्रमाणपत्र छ, र प्रत्येक पक्षले अझै अर्कोलाई प्रमाणित गर्छ। बदलिने कुरा यो हो कि प्रमाणीकरण कहाँ लंगरिएको छ: विश्वसनीय जारीकर्ताबाट पिन गरिएका डाइजेस्टको छोटो सूचीसम्म। डाइजेस्टले नाम नभई पूरै प्रमाणपत्र समेट्ने हुँदा, नवीकरण साँच्चै समय लिने कार्य बन्छ।
फिंगरप्रिन्टले वास्तवमा के को प्रतिबद्धता लिन्छ
प्रमाणपत्रको फिंगरप्रिन्ट DER-एन्कोड गरिएको पूरै प्रमाणपत्रको डाइजेस्ट हो, यसको सार्वजनिक कुञ्जीको होइन र यसको विषय-नामको पनि होइन। त्यसैले एउटै नाम र एउटै कुञ्जी तर फरक वैधता मिति भएका दुई प्रमाणपत्रका फिंगरप्रिन्ट फरक हुन्छन्। यसैले पिनिङलाई सटीक बनाउँछ, र यसैले नवीकरणलाई बाधक बनाउँछ। पिनिङको अर्थ सामान्य रूपमा कुञ्जीमा भरोसा गर्नु हुन सक्दैन, किनकि यसले एउटा वस्तुलाई उसको जीवनको एक क्षणमा नाम दिन्छ। जो कोहीले डाइजेस्ट जान्न सक्छ, र त्यो जान्नु आफैंमा केही प्रमाणित गर्दैन।
openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256मिल्ने निजी कुञ्जीको स्वामित्वले नै सहकर्मीसँग त्यो प्रमाणपत्र छ भनी प्रमाणित गर्छ, र डाइजेस्ट भनेको अर्को पक्षले त्यो प्रमाणपत्र अपेक्षा गरेको थियो कि थिएन भनी निर्णय गर्ने तरिका हो। यही अलगावले यो डिजाइन पुरानो साझा-रहस्य व्यवस्था नभएको कारण हो: साझा कुञ्जीले एउटै बाइट जान्ने जो कोहीलाई प्रमाणित गर्छ, जबकि पिनिङले एउटा प्रमाणपत्र प्रमाणित गर्छ। फरक उपकरणले त्यही रहस्यको प्रतिलिपि नभई आफ्नै प्रविष्टि पाउँछ, जो फाइलहरूमा सानो फरक र क्षतिको दायरामा ठूलो फरक हो।
नक्सा पारस्परिक छ, सममित होइन
प्रत्येक अन्त्य बिन्दुलाई दुई कुरा चाहिन्छ: आफ्नै निजी कुञ्जी प्रमाणपत्रसहित, र कुन सहकर्मी प्रमाणपत्र स्वीकार्ने भन्ने वक्तव्य। क्लाइन्टमा त्यो वक्तव्य सर्भर प्रमाणपत्रको डाइजेस्ट हो; सर्भरमा त्यो दर्ता भएका क्लाइन्ट डाइजेस्टको सूची हो। Community 2.6 का लागि सानो सेटअपको आधिकारिक उदाहरण peer-fingerprint सहित व्यवस्था देखाउँछ, र वास्तविक तैनातीका लागि यो विश्वास मोडेल छनोट गर्नुअघि त्यो पढ्न योग्य छ। दुई दिशा एउटा उल्टो सूची होइनन्, र ती एकै क्षणमा असफल हुँदैनन्।
| Verification direction | What is pinned | What never leaves that endpoint | How a wrong pin shows up |
|---|---|---|---|
| Client checks the server | One digest, for the server certificate | The server private key | The client aborts during the TLS handshake |
| Server checks the client | A digest per enrolled client | Each client private key | The server rejects the peer before a tunnel exists |
उपकरण थप्नुले सर्भरमा अनुमत सूची सम्पादन गर्छ, विद्यमान क्लाइन्टको निजी सामग्री प्रतिलिपि नगरी र सर्भर कुञ्जी कतै नसारी। दुई दिशा स्वतन्त्र रूपमा पनि असफल हुन्छन्, जो निदानमा उपयोगी हुन्छ: कुन पक्षले ह्यान्डशेक बन्द गर्छ, त्यही पक्षको अपेक्षा पूरा भएको थिएन। यदि क्लाइन्टले सर्भरलाई अस्वीकार गर्छ भने, डाइजेस्ट प्रस्तुत गरिएको प्रमाणपत्रसँग मिल्दैन। यदि सर्भरले क्लाइन्टलाई अस्वीकार गर्छ भने, त्यो क्लाइन्टको डाइजेस्ट सूचीमा छैन, वा क्लाइन्टले दर्ता भएको भन्दा फरक प्रमाणपत्र प्रस्तुत गरिरहेको छ।
दर्ता: नयाँ उपकरण कसरी सामेल हुन्छ
नयाँ उपकरणको कुञ्जी र प्रमाणपत्र जहाँ निजी कुञ्जी रहनेछ त्यहीँ उत्पन्न गर्नुहोस्, त्यसपछि मात्र सार्वजनिक वस्तु त्यस पक्षकहाँ सार्नुहोस् जसले यसलाई पिन गर्नुपर्छ। अपेक्षित डाइजेस्ट तपाईंले पहिले नै विश्वास गर्ने च्यानलबाट पठाउनुहोस्, र चिनजानको देखिने नामको सट्टा पूरै प्रमाणपत्र तुलना गर्नुहोस्। प्रमाणपत्रकै त्यही अप्रमाणित डाउनलोडबाट प्रतिलिपि गरिएको डाइजेस्टले दुई फाइल एकअर्कासँग मिल्छन् भन्ने मात्र प्रमाणित गर्छ। यो निरन्तरताको जाँच हो, पहिचानको होइन, र यो यस डिजाइन कमजोर हुने सबैभन्दा शान्त बाटो हो।
सर्भरमा, डाइजेस्ट थप्नु सामान्य प्रबन्धकबाट जाने कन्फिगरेसन परिवर्तन हो र त्यसपछि पुन: जडान हुन्छ। नयाँ उपकरण जोडिन्छ र जसको डाइजेस्ट हटाइयो त्यो उपकरण अब जोडिँदैन भनी पुष्टि गर्नुहोस्। केवल सकारात्मक अवस्था समेट्ने परीक्षणले अनुमत सूची अप्रमाणित छोड्छ, र छ महिनापछि तपाईं ठ्याक्कै त्यही अवस्थामा हुनुहुनेछ।
नवीकरण महँगो क्षण हो
प्रत्येक प्रमाणपत्र सकिन्छ, र कुञ्जी र नाम उही रहे पनि नयाँ प्रमाणपत्रको नयाँ डाइजेस्ट हुन्छ। जारीकर्तामुनि नवीकरण त्यो जारीकर्तामा भरोसा गर्ने सहकर्मीहरूका लागि पारदर्शी हुन्छ; पिनिङमुनि यो प्रमाणपत्र पिन गर्ने प्रत्येक सहकर्मीका लागि दर्ताको घटना हो।
म्याद सकिने मितिपछि होइन, अघि नै क्रमको योजना बनाउनुहोस्। नयाँ डाइजेस्ट यसलाई प्रमाणित गर्ने पक्षहरूलाई वितरण गर्नुहोस्, परिवर्तन लागू गर्नुहोस्, र त्यसपछि मात्र अन्त्य बिन्दुमा प्रमाणपत्र फेर्नुहोस्। त्यो क्रमले कुन प्रमाणपत्र चालु छ भन्नेमा दुई पक्ष नमिल्ने कुनै झ्याल छोड्दैन। सूची आफैलाई पनि समीक्षामा राख्नुहोस्, किनकि पिन गरिएको सूचीले महिनाअघि निवृत्त गरिएका उपकरणका प्रविष्टि जम्मा गर्छ। प्रत्येक पुरानो प्रविष्टि त्यस्तो पहिचान हो जो यसको कुञ्जी बाँचेमा अझै प्रमाणित हुन्छ, त्यसैले एउटा हटाउनु सफाइ होइन, सुरक्षा कदम हो।
विश्वास नक्साले के निर्धारण गर्दैन
प्रमाणीकरण एउटा तह हो, र पिन गरिएको नक्साले ठेगाना पूल, धकेलिएका रुट, बाटोको MTU वा फायरवाल नीतिबारे केही भन्दैन। ती अलग कन्फिगरेसन र अलग असफलता विधिसहित रहन्छन्। प्रमाणित हुने तर कुनै ट्राफिक नपठाउने टनेल कहिल्यै नउठ्ने टनेलभन्दा फरक अन्वेषण हो।
नक्सा पनि असीमित रूपमा स्केल हुँदैन, र ठूला तैनाती जारीकर्ता-आधारित PKI मा गएर टुंगिन्छन्। त्यो प्राथमिकता क्रिप्टोग्राफीको होइन, सञ्चालनको हो, किनकि बेडा बढ्दै जाँदा प्रत्येक सहकर्मीमा सूची सम्पादन गर्नुभन्दा एउटा प्राधिकरणमार्फत पहिचान थप्नु र हटाउनु सस्तो हुन्छ। जहाँ क्लाइन्ट कार्यान्वयनले यो विकल्प समर्थन गर्दैन, उत्तर त्यो क्लाइन्टले दस्तावेज गर्ने अनुकूल विश्वास मोडेल हो, वा समर्थित प्रतिस्थापन हो। प्रमाणीकरण चेतावनी दबाउनुले त्यो समर्थन थप्दैन, र डिजाइनको सम्पूर्ण मूल्य यही हो कि प्रमाणीकरण अझै हुन्छ।