एक जुना पीअर 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 आवृत्ती आणि सिफर, आणि सत्राचा डेटा सिफर छापतात. इनिशियलायझेशन बॅनर नाही, त्या ओळी वाचा, कारण बॅनर यशाची माहिती देतो, त्याच्या अटींची नाही. मग आधुनिक क्लायंटला मुख्य लिसनरशी पुन्हा जोडा आणि तो अजूनही आधुनिक संचावर उतरतो याची खात्री करा, कारण सामायिक कॉन्फिगरेशनमध्ये गळालेला अपवाद सर्वात आधी इथेच दिसतो. तुम्ही कॉपी करता ती मूल्ये पुढील पुनरावलोकनाचा आधार बनतात.

जुने उपकरण स्वतंत्रपणे तपासा: ते कनेक्ट व्हायला हवे, आणि लॉगमध्ये कमकुवत पॅरामीटर दाखवणारे तेच एकमेव सत्र असायला हवे. दुसरा पीअरही जुन्या संचावर वाटाघाटी करत असेल, तर अपवाद अपेक्षेपेक्षा व्यापक आहे आणि लिसनरचे विभाजन प्रत्यक्षात झाले नाही. फक्त निष्कर्ष नव्हे, दोन्ही निरीक्षणे नोंदवा.

प्रत्येक अपवादाला मालक आणि तारीख हवी

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

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