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 संदर्भ तयार करण्याचे प्रकार आणि किल्ली-सामग्री विभागांचे दस्तऐवजीकरण करतो, जो फोरम पोस्टमधून कॉपी केलेल्या आदेशापेक्षा चांगला स्रोत आहे।