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 प्रोफाइलमा स्थायी लाइनलाई कहिल्यै होइन।