VPN को निजी कुञ्जीमा रहेको पासफ्रेजले वास्तवमा के सुरक्षित गर्छ

VPN क्लाइन्ट सुरु हुँदा देखिने प्रम्प्टलाई गलत पढ्न सजिलो छ। यो VPN खाताको पासवर्ड होइन, टनेलको पासवर्ड होइन, र यो प्रविष्ट गर्दा जडान सुरक्षित छ भन्ने प्रमाणित हुँदैन। यसले निजी कुञ्जीको एउटा भण्डारित प्रतिनिधित्व खोल्छ ताकि क्लाइन्टले कुञ्जी सामग्री पढ्न र प्रमाणीकरणका लागि प्रयोग गर्न सकोस्। त्यसपछि हुने सबै कुरा अर्कै प्रश्न हो।

व्यवहारमा जवाफ किनारमा गल्ती हुन्छ: मानिसहरू पासफ्रेजले चलिरहेको टनेल सुरक्षित गर्छ वा यसलाई बदल्दा पहिले नै चुहिएको कुञ्जीको प्रतिलिपि रद्द हुन्छ भनी मान्छन्। दुवै अनुमान असफल हुन्छन्, र दुवै असफल हुने तरिकाले प्रमाणपत्र खुला रहन्छ जबकि अपरेटरलाई यो सम्हालिएको छ भन्ने लाग्छ।

एउटा संवाद, धेरै फरक रहस्यहरू

निजी कुञ्जीको पासफ्रेजले फाइल डिक्रिप्ट गर्छ। खाता पासवर्डले तपाईंलाई सेवामा प्रमाणित गर्छ। PKCS#12 आयात पासवर्डले कुञ्जी र त्यसको प्रमाणपत्र भएको बन्डल डिक्रिप्ट गर्छ, र यो कुञ्जीको आफ्नै पासफ्रेज जस्तै स्ट्रिङ नहुन सक्छ। यी प्रम्प्टहरू लगभग उस्तै देखिन सक्छन्, र कुन रहस्य कहाँ जान्छ भनी अनुमान गर्नु नै कुञ्जीहरू गलत फिल्डमा टाँसिने कारण हो।

टनेलको आफ्नै इन्क्रिप्शन चौथो कुरा हो। डेटा च्यानलले ह्यान्डशेकमा वार्ता गरिएका सत्र कुञ्जीहरू प्रयोग गर्छ; निजी कुञ्जीको पासफ्रेजको व्यक्तिगत प्याकेट सुरक्षामा कुनै भूमिका छैन। यदि कसैले कुञ्जी फाइल पढ्न सक्छ भने, उसले अफलाइन पासफ्रेज अनुमान गर्न प्रयास गर्न सक्छ, तर यदि उसले प्याकेट पढ्न सक्छ भने, पासफ्रेज अप्रासंगिक छ।

डिस्कमा रहेको इन्क्रिप्शनले के समेट्छ

इन्क्रिप्ट गरिएको PEM कुञ्जी दुई रूपमा आउँछ, र हेडरले तपाईंसँग कुन छ भनी बताउँछ। आधुनिक PKCS#8 रूप -----BEGIN ENCRYPTED PRIVATE KEY----- बाट सुरु हुन्छ; पुरानो PEM रूप, पुराना OpenVPN सेटअपमा अझै सामान्य, -----BEGIN RSA PRIVATE KEY----- बाट सुरु हुन्छ र त्यसको ठीक तल Proc-Type: 4,ENCRYPTED र DEK-Info लाइन राख्छ। फाइलले निजी कुञ्जीलाई तपाईंको पासफ्रेजबाट प्राप्त कुञ्जीमुनि इन्क्रिप्ट गरेर राख्छ, सामान्यतया निर्दिष्ट दोहोरिने संख्या वा कार्य कारक भएको पासवर्ड-आधारित KDF मार्फत। OpenSSL pkey कागजात ले ढाँचा र पढ्दा लागू हुने पासफ्रेज विकल्पहरू समेट्छ।

यसबाट दुई परिणाम आउँछन्। कमजोर पासफ्रेजमाथि KDF ले अनुमति दिने दरमा अफलाइन आक्रमण गर्न सकिन्छ, त्यसैले फाइल इन्क्रिप्ट भए पनि फाइल अनुमति र ब्याकअपमा पहुँच महत्त्वपूर्ण रहन्छ। र पासफ्रेज बिना केवल फाइल पाउने आक्रमणकारीले अनुमान गर्नुपर्छ; फाइल र पासफ्रेज दुवै पाउनेसँग कुञ्जी हुन्छ, जस्तो कि यो कहिल्यै इन्क्रिप्ट भएको थिएन।

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 ले हेडर र पुरानो फाइलमा इन्क्रिप्शन प्रमाणित गर्ने Proc-Type र DEK-Info लाइनहरू देखाउँछ; एउटै लाइन कुनै पनि दिशामा प्रमाण होइन। pkey लाइनले पासफ्रेज माग्छ र सार्वजनिक आधा मात्र छाप्छ, जसले फाइल र पासफ्रेज काम गर्छन् भनी निजी कुञ्जी नखोली प्रमाणित गर्छ। त्यो जाँचका लागि -text प्रयोग नगर्नुहोस्: यसले निजी घटकहरू, privateExponent, prime1, prime2 र बाँकी छाप्छ, र त्यो आउटपुट कहिल्यै कतै टाँस्नु हुँदैन, टिकटमा, च्याटमा वा लगमा पनि। PKCS#12 आदेशले बन्डलमा छुट्टै MAC वा इन्क्रिप्शन पासवर्ड छ कि भनी पनि बताउँछ, जुन सहकर्मीलाई दिनुअघि जान्न लायक हुन्छ।

कुञ्जी लोड भएपछि यसले के सुरक्षित गर्न छोड्छ

अनलक गर्नु त्यो प्रक्रियाका लागि एकतर्फी घटना हो। क्लाइन्टले KDF बाट कुञ्जी माग्छ, फाइल डिक्रिप्ट गर्छ, र आवश्यक भएसम्म निजी कुञ्जी स्मृतिमा राख्छ। त्यस क्षणदेखि पासफ्रेजले चलिरहेको सत्रबारे केही पनि सुरक्षित गर्दैन: प्रक्रिया स्मृति होइन, कोर डम्प होइन, क्लाइन्टसँग जोडिएको डिबगिङ सत्र होइन, र कुञ्जी प्रयोगमा हुँदा लिइएको मेसिनको ब्याकअप होइन।

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

प्रम्प्ट किन फेरि फेरि आउँछ

हरेक पुनःजडानमा फेरि सोध्ने क्लाइन्ट अनिवार्य रूपमा बिग्रेको हुँदैन। केही क्लाइन्टले सत्रका लागि पासफ्रेज क्यास गर्छन्, केहीले यसलाई OS किचेनमा भण्डारण गर्छन्, र केहीलाई यो उपलब्ध गराउने सहायकतर्फ निर्देशित गर्न सकिन्छ, त्यसैले तपाईंले पाउने व्यवहार क्लाइन्ट र यसको कन्फिगरेसनमा निर्भर हुन्छ, कुञ्जी फाइलमा होइन।

यदि दोहोरिने प्रम्प्ट नै वास्तविक गुनासो हो भने, कुञ्जीबाट इन्क्रिप्शन हटाउनुअघि क्लाइन्टको क्यासिङ र प्रमाणीकरण विकल्प जाँच्नुहोस्। पासफ्रेज हटाउँदा सुरक्षित फाइल सादा पाठ कुञ्जीमा परिणत हुन्छ, र पुनःजडान शान्त हुन्छ, तपाईंसँग भएको एकमात्र आराम-नियन्त्रणको लागतमा। राम्रो जवाफ सामान्यतया समर्थित प्रमाणपत्र भण्डार हो जसमा तपाईंले जसरी पनि प्रयोग गर्ने फाइल अनुमति हुन्छ।

हानि र खुलासा एउटै मर्मत होइन

हराएको पासफ्रेज प्रमाणपत्रबाट पुनःप्राप्त गर्न सकिँदैन। प्रमाणपत्र सार्वजनिक सामग्री हो जसले नामलाई कुञ्जीसँग जोड्छ; यसमा निजी कुञ्जीतर्फ फर्कने बाटो छैन र पासफ्रेजबारे कुनै संकेत छैन। व्यावहारिक विकल्पहरू कुञ्जीको अधिकृत ब्याकअप, वा अपरेटरको सामान्य प्रक्रियाबाट जारी गरिएको नयाँ पहिचान हुन्। पासफ्रेज 'पुनःप्राप्त' गर्ने प्रस्ताव गर्ने जो कोहीले यसको अनुमान गर्ने प्रस्ताव गर्छ।

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