OpenVPN tls-crypt-v2: क्लाइन्ट कुञ्जी र बेरिएको blob ले के गर्छन्
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 |
तालिका नामले होइन, अभिरक्षाले पढ्नुहोस् र परिणाम आफैं स्पष्ट हुन्छन्। बेर्ने कुञ्जी गुमाउनु महँगो घटना हो, किनकि प्रोफाइलमा केहीले पनि त्यसलाई पुनर्निर्माण गर्न सक्दैन र इमानदार पुनःप्राप्ति भनेको समूह फेरि जारी गर्नु हो। चुहिएको प्रोफाइल सस्तो तर धेरै सामान्य हुन्छ, किनकि बेरिएको प्रतिलिपिले फाइल साझा गर्न सुरक्षित बनाउँछ भनी विश्वास गर्ने मानिसहरूले प्रोफाइल टिकटमा टाँस्छन्। दुई असफलतालाई फरक प्रतिक्रिया चाहिन्छ, त्यसैले वस्तुहरू अलग राखिन्छन्।
बेरिएको प्रतिलिपि किन पूरा कथा होइन
प्रोफाइलले उपयोगी क्लाइन्ट सामग्री आफ्नो बेरिएको जोडीसँगै बोक्छ, त्यसैले सर्भरका लागि प्रतिलिपि जोगाउनु फाइल जोगाउनेबारे केही भन्दैन। Blob पठाउन सुरक्षित र प्रकाशित गर्न असुरक्षित हुन्छ। भित्रको मेटाडाटा blob प्राप्त गर्ने जो कोहीलाई देखिन्छ, त्यो टाँसिएको टिकट पछि पढ्नेलाई पनि।
प्रोफाइललाई कन्फिगरेसन नमुना होइन, प्रमाण मान्नुहोस्। चुहिएको फाइलले यसको धारकलाई सर्भरले त्यो पहिचान स्वीकार गर्न छोडेसम्म चल्ने क्लाइन्ट पहिचान दिन्छ, र बेर्नेले त्यो खाली अवधिबारे केही गर्दैन। प्रत्येक क्लाइन्टका लागि एउटा प्रोफाइल जारी गर्नुहोस् ताकि फिर्ता लिनु एक-फाइलको निर्णय रहोस्, र बेर्ने कुञ्जीको ब्याकअप त्यसले सम्भव बनाउने सर्भर कन्फिगरेसनबाट अलग राख्नुहोस्। दुवै बानीले छेडिएको प्रोफाइल सुधार्दैनन्, तर दुवैले अर्को कति छिटो नियन्त्रणमा आउने भन्ने तय गर्छन्।
ह्यान्डसेकमा प्रमाणीकरण हुक कहाँ बस्छ
प्रमाणीकरण हुक TLS स्ट्याक खुल्नुअघि चल्छ, र यसको काम बेरिएको blob मा बोकिएको मेटाडाटा जाँच्नु हो। यसले त्यो मेटाडाटा र सानो, कागजात गरिएको वातावरण पाउँछ, र प्रमाणीकरण हुकभन्दा यससँग काम गर्न कम सामग्री हुन्छ। यसले प्रयोगकर्तानाम, सत्र स्थिति वा प्लगइन चल देख्न सक्छ भनी मान्नु यो हुक नराम्ररी लेखिने सामान्य तरिका हो। अर्को हुकबाट अपेक्षा सापटी लिनुभन्दा हुकको आफ्नै म्यानुअल खण्ड पढ्नुहोस्।
यसको निकास स्थिति निर्णय हो: शून्य नभएको नतिजाले क्लाइन्ट अस्वीकार गर्छ र शून्य नतिजाले ह्यान्डसेक जारी राख्न दिन्छ। त्यसैले नीतिले मेटाडाटा हराएको, पार्स गर्न नसकिने वा अप्रत्याशित हुँदा के हुन्छ भन्नुपर्छ। पहिले अस्वीकारको बाटो लेख्नुहोस्, त्यसपछि कुन मान स्वीकार्य छन् भनी निर्णय गर्नुहोस्।
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 को डिजाइन कागजात ले वस्तु र तिनले तान्ने सीमाको वर्णन गर्छ, जबकि तिनको कार्यान्वयन अपरेटरकै हातमा रहन्छ।