क्या विफल VPN हैंडशेक वाकई डाउनग्रेड हमला है?

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

डाउनग्रेड हमला वास्तव में क्या बदलता है

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

बदलता समझौता है, प्रमाणीकरण नहीं। यदि हमलावर पकड़े बिना प्रस्ताव बदल सकता है, तो पक्ष अब भी हैंडशेक पूरा कर सकते हैं और एक-दूसरे को प्रमाणित कर सकते हैं, पर उन मापदंडों के साथ जो हमलावर पसंद करता है। इसीलिए दिलचस्प सवाल यह है कि क्या बातचीत खुद अखंडता सुरक्षा के दायरे में है।

बातचीत को ही प्रमाणित करना क्यों ज़रूरी है

TLS 1.3 उस सुरक्षा को स्पष्ट बनाता है। नया संस्करण प्रस्तावित करने वाला क्लाइंट चुपचाप पीछे हटे सर्वर को पहचान सकता है, क्योंकि सर्वर का यादृच्छिक मान 1.2 या नीचे बातचीत करते समय एक निश्चित पैटर्न रखता है, और क्लाइंट को उसे देखते ही रोकना होता है। पूरा ट्रांसक्रिप्ट अंतिम संदेशों से भी ढका होता है, इसलिए बातचीत में कहीं भी बदलाव बाद में विफल होता है, चुपचाप निकल नहीं जाता।

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

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

कॉन्फ़िगर की गई संगतता हमला नहीं है

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

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

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

कारण का नाम देने से पहले विफलता पढ़ें

किसी भी बदलाव से पहले सटीक त्रुटि स्ट्रिंग, क्लाइंट और सर्वर संस्करण तथा समय सुरक्षित रखें। फिर वर्गीकृत करें: क्या पक्ष प्रस्ताव पर असहमत थे, पैकेट पथ विफल हुआ, या एक पक्ष ने ऐसा मापदंड अस्वीकार किया जिसे कभी स्वीकार करता था?

प्रस्ताव का अमेल आमतौर पर दोषी संस्करणों या एल्गोरिद्म का नाम लेता है और हर बार उसी बिंदु पर विफल होता है। रूटिंग या MTU समस्या अटक जाती है या समय समाप्त हो जाता है, और यह अक्सर नेटवर्क के अनुसार बदलती है। समाप्त प्रमाणपत्र बातचीत की नहीं, सत्यापन की त्रुटि देता है।

इनमें से कोई भी हमलावर का सबूत नहीं है। पहली विफलता पर दुर्भावनापूर्ण कारण मान लेना ही गलती है, क्योंकि यह उस निश्चित बग को छिपा देता है जो कल फिर विफल होगा।

पुष्टि करें कि वास्तव में क्या चुना गया

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

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

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