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 कीचेनमध्ये साठवतात, आणि काहींना तो पुरवणाऱ्या सहाय्यकाकडे निर्देश करता येते, म्हणून तुम्हाला मिळणारे वर्तन क्लायंट आणि त्याच्या कॉन्फिगरेशनवर अवलंबून असते, की फाइलवर नाही.

पुनरावृत्ती होणारा प्रॉम्प्ट हीच खरी तक्रार असल्यास, कीवरून एन्क्रिप्शन काढण्यापूर्वी क्लायंटचे कॅशिंग आणि प्रमाणीकरण पर्याय तपासा. पासफ्रेज काढल्याने संरक्षित फाइल साध्या मजकुराची की बनते, आणि पुनःकनेक्शन शांत होते, तुमच्याकडे असलेल्या एकमेव विश्रांती नियंत्रणाच्या किमतीवर. चांगले उत्तर सहसा समर्थित क्रेडेन्शियल स्टोअर असते ज्यात तुम्ही वापरत असलेल्याच फाइल परवानग्या असतात.

नुकसान आणि उघडकीस येणे ही एकच दुरुस्ती नाही

हरवलेला पासफ्रेज प्रमाणपत्रातून पुनर्प्राप्त करता येत नाही. प्रमाणपत्र ही सार्वजनिक सामग्री आहे जी नाव कीशी जोडते; त्यात खाजगी कीकडे परत जाण्याचा मार्ग नाही आणि पासफ्रेजबद्दल कोणताही सुगावा नाही. व्यावहारिक पर्याय म्हणजे कीचा अधिकृत बॅकअप, किंवा ऑपरेटरच्या सामान्य प्रक्रियेद्वारे जारी केलेली नवी ओळख. पासफ्रेज 'पुनर्प्राप्त' करण्याची ऑफर देणारा प्रत्येकजण त्याचा अंदाज लावण्याची ऑफर देत आहे.

उघडकीस येण्यास वेगळा प्रतिसाद लागतो. तीच की नव्या पासफ्रेजने पुन्हा एन्क्रिप्ट केल्यास की सामग्री बदलत नाही, म्हणून दुसरीकडे आधीच उघडलेली प्रत अजूनही काम करते. दुरुस्ती म्हणजे क्रेडेन्शियल रद्द करणे किंवा बदलणे: नवी की आणि प्रमाणपत्र जारी करा, वितरित करा, आणि जुनी सहभागीाकडे निवृत्त करा. तसे होईपर्यंत, फाइलचा पासवर्ड बदलणे हे घरकाम आहे, नियंत्रण नाही. नवी ओळख काम करते याची खात्री झाल्यावरच जुनी फाइल बॅकअपबाहेर ठेवा, आणि कोणत्या अनुक्रमांकाने किंवा बोटांच्या ठशाने ती बदलली ते नोंदवा.