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 पर ही पहुँचते हैं। यह वरीयता क्रिप्टोग्राफ़ी के बजाय संचालन के बारे में है, क्योंकि बेड़ा बढ़ने पर हर साथी पर सूची संपादित करने से एक प्राधिकरण के माध्यम से पहचान जोड़ना और हटाना सस्ता है। जहाँ क्लाइंट कार्यान्वयन इस विकल्प का समर्थन नहीं करता, वहाँ उत्तर वह अनुकूल विश्वास मॉडल है जिसे वह क्लाइंट दस्तावेज़ित करता है, या समर्थित प्रतिस्थापन है। सत्यापन चेतावनी को दबाना वह समर्थन नहीं जोड़ता, और डिज़ाइन का पूरा मूल्य यही है कि सत्यापन अब भी होता है।