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 कडे येऊन थांबतात। ती पसंती क्रिप्टोग्राफीबद्दल नाही तर कार्यचालनाबद्दल आहे, कारण ताफा वाढताच प्रत्येक समकक्षावर यादी संपादित करण्यापेक्षा एका प्राधिकरणामार्फत ओळखी जोडणे व वगळणे स्वस्त आहे। जिथे क्लायंट अंमलबजावणी हा पर्याय समर्थन देत नाही, तिथे उत्तर त्या क्लायंटने दस्तऐवजीकृत केलेले सुसंगत विश्वास मॉडेल आहे, किंवा समर्थित पर्याय आहे। पडताळणी इशारा दाबणे ते समर्थन जोडत नाही, आणि रचनेचे संपूर्ण मूल्य हेच आहे की पडताळणी अजूनही होते।