OpenVPN tls-crypt-v2: क्लाइंट कुंजी और रैप्ड ब्लॉब क्या करते हैं
tls-crypt-v2 प्रोफ़ाइल में क्लाइंट की नियंत्रण कुंजी और उसकी रैप्ड प्रति होती है जिसे केवल सर्वर खोल सकता है। हर ऑब्जेक्ट और हटाने के हर चरण को अलग रखें।
किसी टिकट में tls-crypt-v2 प्रोफ़ाइल चिपकाना तब तक हानिरहित लगता है जब तक आप गिनें नहीं कि फ़ाइल में क्या है। क्लाइंट की नियंत्रण-चैनल कुंजी उसी कुंजी की एन्क्रिप्टेड प्रति के बगल में बैठती है, और तीसरा ऑब्जेक्ट, रैपिंग कुंजी, स्वीकार करने वाले सर्वर से कभी बाहर नहीं जाता। ये तीनों अभिरक्षा, साझा करने और हटाने के बारे में अलग-अलग सवालों का जवाब देते हैं। इन्हें अलग रखना शुरू होने से पहले ही अधिकांश नीति बहसें सुलझा देता है।
प्रोफ़ाइल में असल में क्या है
tls-crypt-v2 का क्लाइंट आधा हिस्सा एक कुंजी और उसकी रैप्ड प्रति है। क्लाइंट नियंत्रण-चैनल की सुरक्षा के लिए सादी कुंजी का उपयोग करता है और सेटअप के दौरान रैप्ड प्रति सर्वर को सौंपता है, ताकि सर्वर हर क्लाइंट के लिए सादी प्रति संग्रह किए बिना वही कुंजी फिर से पा ले। रैपिंग कुंजी उस पुनःप्राप्ति को संभव बनाती है और केवल स्वीकार करने वाले पक्ष में रहनी चाहिए। नीचे सब कुछ इसी से निकलता है कि वे तीनों ऑब्जेक्ट कहाँ रहते हैं।
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
तालिका को नाम से नहीं, अभिरक्षा से पढ़िए और नतीजे अपने आप निकल आते हैं। रैपिंग कुंजी खोना महँगी घटना है, क्योंकि प्रोफ़ाइल में कुछ भी उसे दोबारा नहीं बना सकता और ईमानदार वसूली समूह को फिर से जारी करना है। लीक हुई प्रोफ़ाइल सस्ती है पर कहीं अधिक आम है, क्योंकि लोग टिकटों में प्रोफ़ाइल चिपकाते हैं यह मानकर कि रैप्ड प्रति फ़ाइल को साझा करने योग्य सुरक्षित बना देती है। दोनों विफलताओं को अलग जवाब चाहिए, इसीलिए ऑब्जेक्ट अलग रखे जाते हैं।
रैप्ड प्रति पूरी कहानी क्यों नहीं है
प्रोफ़ाइल में काम आने वाली क्लाइंट सामग्री अपनी रैप्ड जोड़ीदार प्रति के साथ होती है, इसलिए सर्वर के लिए प्रति की सुरक्षा फ़ाइल की सुरक्षा के बारे में कुछ नहीं कहती। ब्लॉब भेजने के लिए सुरक्षित है और प्रकाशित करने के लिए असुरक्षित। उसके अंदर के मेटाडेटा हर उस व्यक्ति को दिखते हैं जिसे ब्लॉब मिलता है, जिसमें वह भी शामिल है जो बाद में उस टिकट को पढ़ेगा जिसमें वह चिपकाया गया था।
प्रोफ़ाइल को कॉन्फ़िगरेशन नमूना नहीं, क्रेडेंशियल मानिए। लीक हुई फ़ाइल अपने धारक को काम करती क्लाइंट पहचान देती है जब तक सर्वर उस पहचान को स्वीकार करना बंद न कर दे, और रैपिंग उस खिड़की के बारे में कुछ नहीं करती। हर क्लाइंट के लिए एक प्रोफ़ाइल जारी कीजिए ताकि वापस लेना एक-फ़ाइल का फ़ैसला रहे, और रैपिंग कुंजी का बैकअप उस सर्वर कॉन्फ़िगरेशन से अलग रखिए जिसे वह सक्षम करती है। दोनों में से कोई आदत छेड़ी गई प्रोफ़ाइल को ठीक नहीं करती, पर दोनों तय करती हैं कि अगली कितनी जल्दी काबू में आएगी।
हैंडशेक में सत्यापन हुक कहाँ बैठता है
सत्यापन हुक TLS स्टैक खुलने से पहले चलता है, और उसका काम रैप्ड ब्लॉब में ले जाए गए मेटाडेटा की जाँच करना है। उसे वह मेटाडेटा और एक छोटा, प्रलेखित वातावरण मिलता है, और ऑथेंटिकेशन हुक की तुलना में उसके पास काम करने को कम होता है। यह मानना कि वह उपयोगकर्ता नाम, सत्र स्थिति या प्लगइन चर देख सकता है, इस हुक के बुरी तरह लिखे जाने का आम तरीका है। किसी दूसरे हुक से अपेक्षाएँ उधार लेने के बजाय हुक का अपना मैनुअल खंड पढ़िए।
उसकी निकास स्थिति ही फ़ैसला है: गैर-शून्य परिणाम क्लाइंट को अस्वीकार करता है और शून्य परिणाम हैंडशेक को जारी रहने देता है। इसलिए नीति को बताना होगा कि मेटाडेटा गायब होने, पार्स न होने या अप्रत्याशित होने पर क्या होता है। पहले अस्वीकार का रास्ता लिखिए, फिर तय कीजिए कि कौन-से मान स्वीकार्य हैं।
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shवे दो पंक्तियाँ सर्वर पर नीति की सतह हैं: एक रैपिंग कुंजी का नाम देती है, दूसरी उस प्रोग्राम का जो हर क्लाइंट का फ़ैसला करता है। दिलचस्प सब कुछ स्क्रिप्ट में है, जो संस्करण नियंत्रण और किसी भी अन्य पहुँच नियम जैसी समीक्षा की हकदार है।
खाता, प्रमाणपत्र और नियंत्रण कुंजी अलग-अलग हटते हैं
नियंत्रण-चैनल की जल्दी स्वीकृति ऑथेंटिकेशन नहीं है, क्योंकि वह TLS पहचान जाँच से पहले और किसी भी खाता प्राधिकरण से पहले होती है। खाता बंद करना, प्रमाणपत्र निरस्त करना और क्लाइंट नियंत्रण कुंजी अस्वीकार करना तीन तंत्रों वाली तीन क्रियाएँ हैं। जो तैनाती इनमें से केवल एक करती है, उसमें नीति के बजाय खाई है। तीनों को जानबूझकर मिलाइए, और दर्ज कीजिए कि कौन-सा चरण किस प्राधिकार का उपयोग करता है।
समय दूसरा भेद है। बदली हुई स्वीकृति सूची नए हैंडशेक पर लागू होती है, जबकि पहले से स्थापित सत्र तब तक चलते रहते हैं जब तक कुछ उन्हें समाप्त न करे। नई सूची में प्रविष्टियाँ गिनकर यह साबित करना कि पुराने सत्र खत्म हो गए, वही तरीका है जिससे हटाया गया क्लाइंट घंटों तक जुड़ा रहता है।
बेमेल प्राधिकार दो छेद छोड़ते हैं जो व्यवहार में आसानी से मिल जाते हैं। खाता बंद हो सकता है जबकि उसकी नियंत्रण कुंजी अब भी हैंडशेक खोलती है, और प्रमाणपत्र निरस्त हो सकता है जबकि मेटाडेटा नीति उसी क्लाइंट को अब भी स्वीकार करती है। दोनों अलग जगहों पर एक ही गलती हैं, क्योंकि ऑपरेटर ने एक सूची को पूरा प्राधिकार मान लिया। हटाने के समय तीनों सूचियाँ साथ रखिए और गलती दिखाई देने लगती है।
प्रोफ़ाइल जारी करना और वापस लेना
जारी करना आसान आधा है: स्वीकार करने वाले पक्ष पर क्लाइंट कुंजी बनाइए, प्रोफ़ाइल ठीक एक स्वामी को दीजिए, रैपिंग सामग्री सीमित रखिए, और हर स्वीकार करने वाले सर्वर पर वही सत्यापन प्रोग्राम चलाइए। सस्ता प्रवेश पूरे समूह का गुण है, सबसे नए होस्ट का नहीं। पुरानी या ढीली स्क्रिप्ट वाला दूसरा सर्वर चुपचाप तैनाती का सबसे कमजोर रास्ता बन जाता है।
वापस लेने के लिए तीनों चरण जानबूझकर क्रम में चाहिए। सत्यापन हुक में क्लाइंट को अस्वीकार कीजिए ताकि नए हैंडशेक विफल हों, यदि PKI उपयोग में है तो उसका प्रमाणपत्र निरस्त कीजिए, और खाता बंद कीजिए ताकि बाद के प्राधिकरण के पास प्राधिकृत करने को कुछ न बचे। फिर पुरानी स्वीकृति से मंजूर सत्र समाप्त कीजिए, क्योंकि वे तीनों में से किसी को नोटिस नहीं करेंगे। जिस क्लाइंट को आप तोड़ सकते हैं उस पर यह क्रम दोहराइए।
प्रोफ़ाइल में मेटाडेटा उस नीति के लिए इनपुट है, इस बात का सबूत नहीं कि पहुँच नियंत्रण पहले से मौजूद है। OpenVPN 2.6 का डिज़ाइन दस्तावेज़ उन ऑब्जेक्ट और उनके द्वारा खींची गई सीमा का वर्णन करता है, जबकि उन्हें लागू करना ऑपरेटर के पास ही रहता है।