VPN मध्ये DES विरुद्ध 3DES: दोन्ही चुकीचे अपग्रेड का आहेत

दोन्ही सिफर कालबाह्य आहेत, आणि नवीन रहदारीसाठी दोन्हीपैकी कोणतेही योग्य लक्ष्य नाही. उपयुक्त तुलना DES विरुद्ध 3DES नाही; ती मागे घेतलेला अल्गोरिदम विरुद्ध देखभाल केलेला अल्गोरिदम आहे. जर गेटवे अजूनही त्यापैकी एक देऊ करत असेल, तर काम आहे ते शोधणे की काय त्याची मागणी करते आणि ती अट काढून टाकणे, दोन बंद रस्त्यांपैकी मजबूत निवडणे नाही.

लोक अजूनही ज्याचा शोध घेतात ती तुलना चुकीची आहे

2000 च्या दशकात लिहिलेली उत्तरे DES ची तिप्पट DES शी तुलना करतात आणि तिप्पट DES अधिक मजबूत आहे असा निष्कर्ष काढतात. तेव्हा ते योग्य होते आणि आता निरुपयोगी आहे, कारण दोन्ही नवीन रहदारीच्या संरक्षणासाठी मागे घेतले आहेत आणि त्यांच्यातील निवड दोन बंद रस्त्यांमधील निवड आहे.

NIST ने 2005 मध्ये DES मानक मागे घेतले, आणि त्याची TDEA शिफारस जानेवारी 2024 मध्ये मागे घेतली, नवीन क्रिप्टोग्राफिक संरक्षणावर TDEA लागू करण्याची मुदत 2023 च्या अखेरीस संपल्यानंतर. त्या तारखा संक्रमणाचे वर्णन करतात, क्रमवारीचे नाही. लहान सत्र किंवा कमी मूल्याचा संदेश प्रश्न पुन्हा उघडत नाही, कारण अल्गोरिदमची स्थिती की किती काळ वापरली जाते यावर अवलंबून नाही.

की नूतनीकरण हे वेगळे नियंत्रण आहे, आणि ते मान्यता पुनर्संचयित करत नाही.

वाटाघाटी डेटा मार्गापासून वेगळी करा

VPN प्रोटोकॉल एकापेक्षा जास्त ठिकाणी संरक्षणाची वाटाघाटी करतात. नियंत्रण चॅनेल एक संच वापरू शकते तर वाहून नेला जाणारा डेटा दुसरा वापरतो, आणि प्रस्ताव यादी फक्त सांगते की पीअर काय स्वीकारण्यास तयार आहे. प्रस्ताव नाही, वाटाघाटी झालेला निकाल वाचा. हा फरक सामान्य गोंधळ स्पष्ट करतो: गेटवे अजूनही जुना अल्गोरिदम सूचीबद्ध करतो आणि ऑपरेटर त्याचा वापर होत असल्याचे गृहीत धरतो, जेव्हा तो देऊ केला जाऊ शकतो आणि कधीही निवडला जाऊ शकत नाही, किंवा फक्त एका जुन्या पीअरसाठी निवडला जाऊ शकतो.

IPsec गेटवेवर संबंधित आउटपुट सुरक्षा संघटना आहे; OpenVPN वर ते कनेक्शन लॉगमधील सिफर आणि TLS सेटिंग्ज आहेत. दोन्ही सांगतात काय निवडले गेले. कॉन्फिगरेशन फाइलमध्ये अजूनही असलेल्या जुन्या पर्यायाने दोन्हीपैकी काहीही सिद्ध होत नाही.

जर तुम्हाला वाटाघाटी झालेला निकाल दिसत नसेल, तर सिफर मागे घेतला गेला असे तुम्ही म्हणू शकत नाही.

अजूनही त्याची मागणी करणारा घटक शोधा

जुन्या गरजा तीन ठिकाणांहून येतात: काहीही चांगले न देणारा जुना क्लायंट, अल्गोरिदम अजूनही सूचीबद्ध करणारे गेटवे धोरण, आणि फक्त जुना प्रोटोकॉल बोलणारे उपकरण. प्रत्येकाचे वेगळे समाधान आहे. सुसंगतता पुरवठादार सक्षम करण्यापूर्वी बंधनाच्या मालकाला कोणते आहे ते विचारा, कारण ते सक्षम केल्यास प्रत्येक जोडणाऱ्या पीअरवर परिणाम होतो.

अजून बदलता न येणाऱ्या एका उपकरणासाठी, त्याच्या समोर देखभाल केलेला गेटवे ठेवा आणि ती सीमा काय वाहते ते मर्यादित करा. हे जुना सिफर आवरते, पण प्रत्येक दूरस्थ वापरकर्त्याला तो वारसा म्हणून मिळत नाही.

आवरणे हे पॅच नाही, आणि ते जुन्या होस्टला विश्वासार्ह बनवत नाही.

तुमच्याकडे आधीच असलेल्या तपासण्यांसह स्थलांतर करा

स्थलांतर तेव्हा पूर्ण होते जेव्हा इच्छित पीअर देखभाल केलेल्या प्रोफाइलसह जोडतात, वाटाघाटी झालेला संच तुम्ही अपेक्षित असलेला असतो, आणि अनुप्रयोग कार्य करतो. सर्व्हर ओळख पडताळणी आणि खाते तपासण्या संपूर्ण वेळेत ठेवा; सिफर बदल त्यांना सैल करण्याचे कारण नाही.

openvpn --version
openssl ciphers -v 'DEFAULT:!DES:!3DES'

वाटाघाटी झालेल्या निकालाच्या बाजूला क्लायंट आणि गेटवे आवृत्त्या नोंदवा, जेणेकरून पुढील पुनरावलोकन सांगू शकेल की प्रत्यक्षात काय बदलले.

त्याच्या मालकाद्वारे जुनी परवानगी मागे घ्या, नंतर पुष्टी करा की फक्त मागे घेतलेला अल्गोरिदम देऊ करणारा पीअर आता नाकारला जातो. जुना पर्याय सक्षम ठेवणारे स्थलांतर हे घडले नसलेले स्थलांतर आहे. नकाराचा पुरावा बदल नोंदीसह ठेवा, कारण पुढील ऑडिट विचारेल तुम्हाला कसे माहीत, आणि काढून टाकलेली कॉन्फिगरेशन ओळ नोंदवलेल्या नकारापेक्षा कमकुवत पुरावा आहे. सत्र ताजे असतानाच त्या नोंदीत चाचणी तारीख आणि पीअरची ओळख जोडा.

ऐतिहासिक डेटा ही वेगळी समस्या आहे

वर्षांपूर्वी संरक्षित केलेले संग्रहण वाचण्यासाठी कायदेशीररीत्या जुना अल्गोरिदम आवश्यक असू शकतो. ते विद्यमान सामग्रीचे डिक्रिप्शन आहे, आणि नवीन रहदारी संरक्षित करण्यासारखे तेच काम नाही.

असे काम वेगळ्या होस्टवर ठेवा, ज्याचा उद्देश नोंदवलेला असेल आणि कोण ते चालवू शकतो याची छोटी यादी असेल.

हा फरक महत्त्वाचा आहे कारण मागे घेतलेला सिफर उपलब्ध ठेवण्याचे हे एकमेव प्रामाणिक कारण आहे. ते मर्यादित व्याप्तीच्या साधनाचे समर्थन करते, सार्वजनिक VPN प्रोफाइलमधील कायमच्या ओळीचे कधीही नाही.