openssl rand वह कुंजी क्यों नहीं बना सकता जो tls-crypt चाहता है

OpenSSL पहले से इंस्टॉल है, होस्ट के पास एंट्रॉपी है, और इससे कुंजी बनाना स्पष्ट शॉर्टकट लगता है। आउटपुट यादृच्छिक और गुप्त और पूरी तरह अनुपयोगी होगा, और विफलता कुंजी प्रारूप का उल्लेख करने वाली किसी चीज़ के बजाय कंट्रोल-चैनल त्रुटि के रूप में आएगी। यही भ्रम महँगा हिस्सा है, क्योंकि यह लोगों को उनके सिफर जाँचने भेजता है। VPN जो पढ़ता है वह एक विशिष्ट फ़ाइल संरचना है, कोई मनमाना बाइट ब्लॉक नहीं, और सुविधा का एक रूप सर्वर के बाहर बिल्कुल नहीं बनाया जा सकता।

डिस्क पर मौजूद फ़ाइल वास्तव में क्या होनी चाहिए

OpenVPN की स्टैटिक कुंजी फ़ाइल टेक्स्ट है। यह एक टिप्पणी पंक्ति से शुरू होती है जो बताती है कि यह क्या है, निश्चित चौड़ाई की पंक्तियों में हेक्स डेटा रखती है, और कुल 256 बाइट कुंजी सामग्री रखती है। OpenVPN इसे कंट्रोल चैनल के साझा रहस्य के रूप में पढ़ता है, प्रमाणपत्र के रूप में नहीं, पासफ़्रेज़ के रूप में नहीं और ऐसी किसी चीज़ के रूप में नहीं जिसे TLS लाइब्रेरी पहचानेगी।

यही ऑब्जेक्ट प्रकार कंट्रोल चैनल की दोनों सुविधाओं की सेवा करता है। tls-auth के साथ, हर पीयर को दिशा भी चाहिए ताकि एक पक्ष के पैकेट उस पर वापस परावर्तित न हो सकें। tls-crypt के साथ, एक ही साझा रहस्य दोनों दिशाओं में कंट्रोल चैनल को एन्क्रिप्ट और प्रमाणित करता है, जो हैंडशेक को छिपाता भी है और साथ ही सुरक्षा देता है।

इनमें से कुछ भी गुप्त ज्ञान नहीं है, और प्रारूप मुख्य बात नहीं है। मुख्य बात यह है कि फ़ाइल को वही होना चाहिए जो पाठक अपेक्षा करता है: हेडर, पंक्ति की चौड़ाई, अंतिम नई पंक्ति और कुल लंबाई। एक पंक्ति से हटी फ़ाइल कचरे के रूप में लोड होती है या पूरी तरह विफल हो जाती है। इसलिए दो पीयरों की बाइट-दर-बाइट तुलना एक वैध पहला परीक्षण है, और यह दोनों कॉन्फ़िगरेशन फ़ाइलों में से किसी को पढ़ने से तेज़ है।

एक बनाने का समर्थित तरीका

सादा स्टैटिक कुंजी उस टूल से बनाएँ जो इसे उपभोग करेगा, और फिर दोनों सिरों से इसका संदर्भ दें:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

विकल्प की वर्तनी समय के साथ बदली: 2.4 युग के पुराने इंस्टॉलेशन फ़ाइल नाम से पहले अलग फ़्लैग वाला रूप उपयोग करते थे, जबकि मौजूदा बिल्ड छोटा रूप स्वीकार करते हैं। किसी भी तरह, परिणामी फ़ाइल वही ऑब्जेक्ट प्रकार है, इसलिए जाँच यह है कि दोनों पीयरों के पास समान बाइट हैं या नहीं।

दूसरी पीढ़ी ऐसी संरचना जोड़ती है जिसे कोई बाहरी जनरेटर आविष्कार नहीं कर सकता। सर्वर कुंजी एक बार बनाई जाती है, और हर क्लाइंट को उससे व्युत्पन्न लिपटी हुई कुंजी मिलती है:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

क्लाइंट को जो मिलता है वह सर्वर की अपनी कुंजी की प्रतिलिपि नहीं है। यह एक लिपटा हुआ ऑब्जेक्ट है जो ऐसा मेटाडेटा रखता है जिसे केवल सर्वर ही खोल सकता है, और यही लपेट ही कारण है कि एक डिवाइस की फ़ाइल किसी अन्य डिवाइस को छुए बिना निरस्त की जा सकती है। सर्वर कुंजी सर्वर पर ही रखें और उसे उस डिवाइस-आधारित भरोसे की जड़ मानें।

हाथ से बनी बाइट कहाँ टूटती हैं

सही हेडर के नीचे 256 यादृच्छिक बाइट को हेक्स के रूप में छापने से सैद्धांतिक रूप से लोड होने वाली स्टैटिक कुंजी फ़ाइल मिलेगी। यह फिर भी बुरा विचार है। हर फ़ॉर्मेटिंग विवरण ऐसी सामग्री बनाने का अवसर बन जाता है जो लोड के समय विफल हो या, इससे बुरा, दो पीयरों को अलग-अलग मानों के साथ छोड़ दे जो केवल प्रमाणीकरण विफलता के रूप में सामने आते हैं।

v2 रूप के साथ ऐसा समतुल्य कुछ संभव नहीं है। लिपटी हुई क्लाइंट कुंजी केवल सर्वर कुंजी प्रक्रिया के आउटपुट के रूप में मौजूद होती है, और सर्वर उसे खोलने के लिए आवश्यक सामग्री रखता है। यादृच्छिक ब्लॉक अस्वीकार हो जाएगा या सीधे डिक्रिप्ट नहीं होगा, और दोनों में से कोई भी संदेश यादृच्छिकता का उल्लेख नहीं करेगा।

संस्करण संगतता इन सबके ऊपर बैठती है। पहली पीढ़ी को दोनों सिरों पर इसका समर्थन करने वाला संस्करण चाहिए, और दूसरी को फिर से नया संस्करण चाहिए। सुविधा के अस्तित्व से पहले बना क्लाइंट केवल लिपटी सामग्री स्वीकार करने वाले सर्वर के साथ हैंडशेक पूरा नहीं कर सकता, और जो विफलता वह रिपोर्ट करता है वह संस्करण के बजाय कंट्रोल चैनल की ओर इशारा करती है।

सबको बाहर बंद किए बिना घुमाना

एक साझा रहस्य घुमाना समन्वय का अभ्यास है, तकनीकी नहीं। सर्वर के पिछली कुंजी वापस लेने से पहले हर क्लाइंट के हाथ में प्रतिस्थापन फ़ाइल होनी चाहिए, और पुराना मान रखने वाला कोई भी मशीन उसी क्षण विफल हो जाती है। कार्यदिवस के बीच में यह घुमाव शुरू न करें।

v2 व्यवस्था के साथ, घुमाव प्रति डिवाइस है: एक मशीन के लिए नई लिपटी कुंजी जारी करें और पुरानी को केवल उसी मशीन के लिए सेवानिवृत्त करें। हर क्लाइंट के इसका समर्थन करने वाले संस्करण पर होने के बाद स्थानांतरण का मुख्य तर्क यही है।

फ़ाइल अनुमतियाँ उसी बातचीत का हिस्सा हैं। कुंजी केवल उसी खाते के लिए पठनीय होनी चाहिए जो सेवा चलाता है, और उसे उन प्रोफ़ाइलों के साथ उसी रिपॉज़िटरी में नहीं रहना चाहिए जिन्हें वह सुरक्षित रखती है। OpenVPN 2.6 संदर्भ निर्माण के रूपों और कुंजी-सामग्री अनुभागों का दस्तावेज़ीकरण करता है, जो फ़ोरम पोस्ट से कॉपी किए गए कमांड से बेहतर स्रोत है।