8192-बिट कुञ्जीहरूले ह्यान्डशेक रोक्छन्; 1024-बिट DH अस्वीकार गरिन्छ

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

केही पनि पुनः उत्पादन गर्नुअघि असफलता पढ्नुहोस्

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

यी दुईलाई विपरीत सुधार चाहिन्छ, र यहीँ धेरैजसो प्रयास गल्ती हुन्छन्। पहिले नै सानो समूह अस्वीकार गरिसकेको ग्राहकमा 8192-बिट प्यारामिटर पुनः उत्पादन गर्नुले ढिलो केस अझ बिगार्छ, तर छिटो केसका लागि केही गर्दैन। कुनै फाइल छुनुअघि तपाईंले कुन लक्षण देख्नुभयो लेख्नुहोस्।

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

ढिलो केस: हार्डवेयरले धान्न नसक्ने सामग्री

Diffie-Hellman र RSA को काम कुञ्जीको आकारसँग छिटो बढ्छ, र यी सबै सुरुङमा कुनै ट्राफिक बग्नुअघि नै हुन्छ। सानो राउटर वा कम शक्तिको ग्राहकमा पर्याप्त ठूलो समूहले आदानप्रदानलाई अर्को पक्षको समयसीमाभन्दा पर धकेल्न सक्छ, जसले गर्दा जडान फेरि प्रयास गर्छ वा कुनै त्रुटि नै नभई अड्किएको देखिन्छ।

सुधार भनेको प्रत्येक पक्षले समर्थन गर्ने र प्रत्येक उपकरणले सहजै गणना गर्न सक्ने आकारमा झर्नु हो। 2048-बिट RSA कुञ्जी र 2048-बिट समूह व्यापक रूपमा अनुकूल आधाररेखा रहन्छन्; ठूलो बनाउनु केवल तब मद्दत गर्छ जब सबै पक्ष सहमत हुन्छन् र प्रोसेसरले प्रत्येक पुनर्वार्तामा त्यसको खर्च बेहोर्न सक्छ। त्यो आधाररेखामाथिको सबै जानाजान गरिएको साटासाट हो, उन्नयन होइन।

आकार कुनै अंक होइन, र तुलना तालिकाको सबैभन्दा ठूलो संख्या स्वतः सही छनोट होइन। तपाईंको नीतिले अनुमति दिने र सबै पक्षले स्वीकार गर्ने सबैभन्दा सानो मान छान्नुहोस्, त्यसपछि सुधार भयो भनी मान्नुको सट्टा ह्यान्डशेक नाप्नुहोस्। अझै समयसीमा नाघ्ने सानो समूहले आकार कहिल्यै पूरा कथा नभएको बताउँछ।

छिटो केस: पुस्तकालयले अस्वीकार गर्ने समूह

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

जाँच छल्न कन्फिगरेसन सम्पादन गर्नुको सट्टा फाइल बदल्नुहोस्। हालको समूह उत्पादन गर्नुहोस्, प्रमाणित गर्नुहोस्, त्यसपछि डेमनले साँच्चै पढ्ने ठाउँमा स्थापना गर्नुहोस्। ग्राहक नयाँसँग सफलतापूर्वक जोडिनेसम्म पुरानो फाइल राख्नुहोस्:

openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pem

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

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

अर्को पक्ष र हार्डवेयरका लागि आकार छान्नुहोस्

केही विचित्र उत्पादन गर्नुअघि टाढाको छेउले के सहन सक्छ पत्ता लगाउनुहोस्। 2048-बिट समूहका लागि धेरै पुरानो उपकरण बदल्नुपर्ने उपकरण हो, किनकि सर्भरलाई कमजोर समूहतर्फ फर्काउनुले अनुकूलताको उजुरीलाई अवरोधमा बदल्छ मात्र। टिकाउ सुधार पुरानो प्यारामिटरतर्फ होइन, नयाँ सफ्टवेयरतर्फ जान्छ। यस क्षेत्रको हरेक अस्थायी अपवाद स्थायी कन्फिगरेसन बन्ने बाटो खोज्छ।

सर्भरको CPU सीमा भएको ठाउँमा नीतिभन्दा तल झर्नुको सट्टा एल्गोरिदम बदल्नुहोस्। X25519 जस्तो दीर्घवृत्तीय वक्र कुञ्जी आदानप्रदान ठूलो सीमित-क्षेत्र समूहभन्दा नाटकीय रूपमा सस्तो छ र व्यापक रूपमा समर्थित छ, जसले यसलाई सानो RSA मोड्युलसभन्दा कार्यक्षमताको उजुरीको राम्रो उत्तर बनाउँछ।

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

पुनर्निर्माणले रद्द गर्न नसकोस् भनेर छनोट अभिलेख गर्नुहोस्

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

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