एउटा पुरानो पीयरले TLS 1.0 जबरजस्ती गर्छ: अपवाद सीमित गर्नुहोस्, होस्ट होइन

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

निर्देश बदल्नुअघि असफलतालाई दुई भागमा बाँड्नुहोस्

साझा साइफर छैन वा प्रोटोकल संस्करण असमर्थित छ भन्ने सर्भर लग लाइन नियन्त्रण च्यानलबाट आउँछ: दुवै पक्ष वार्ताकै सुरक्षा कसरी गर्ने भन्नेमा सहमत हुन सकेनन्। सर्भर प्रमाणपत्र प्रमाणीकरणको कुनै पनि विधि सक्रिय छैन भन्ने क्लाइन्ट लाइन पूर्ण रूपमा अर्कै ठाउँबाट आउँछ, किनभने त्यो क्लाइन्टले कसले जवाफ दियो भनेर नै जाँच गर्दैन। डेटा साइफर बदल्नुले दोस्रो अवस्थामा केही गर्दैन, र भूमिका जाँच थप्नुले पहिलोमा केही गर्दैन।

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

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

कमजोर तल्लो सीमाका लागि दोस्रो सुन्ने ठाउँ नै इमानदार ठाउँ हो

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

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

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

पुरानो प्रदायक प्रमाणपत्रले वास्तवमा के तोड्छ

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

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

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

ब्यानर होइन, वार्तामा तय भएका मानहरू पढ्नुहोस्

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

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

हरेक अपवादलाई मालिक र मिति चाहिन्छ

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

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