एक पुराना पीयर 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"

बैनर नहीं, बातचीत में तय किए गए मान पढ़ें

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

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

हर अपवाद को एक मालिक और एक तारीख़ चाहिए

हटाने की शर्त के बिना अपवाद चुपचाप डिफ़ॉल्ट बन जाता है, इसलिए डिवाइस, मालिक, कारण और जिस तारीख़ को वह जाएगा, उसे उस कॉन्फ़िगरेशन के बगल में रखें जिसे वह न्यायसंगत ठहराता है। उस पंक्ति के बिना कमज़ोर न्यूनतम सीमा उस हार्डवेयर से ज़्यादा जीती है जिसे उसकी ज़रूरत थी।

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