Linux पर AnyConnect का अमान्य TLS संस्करण: पहले सुधार का दायरा तय करें

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

नीति छूने से पहले संदेश पढ़ें

संवाद से सटीक स्ट्रिंग निकालकर रखें। संस्करण की शिकायत प्रोटोकॉल परत की ओर, प्रमाणपत्र की शिकायत विश्वास या नामकरण की ओर, और असफल लॉगिन क्रेडेंशियल की ओर इंगित करता है। TLS 1.0, 1024-बिट DHE समूह, AES-256-CBC और SHA-1 हस्ताक्षर वाला गेटवे पूरी तरह वैध प्रमाणपत्र रख सकता है और फिर भी आधुनिक नीति द्वारा आपके क्रेडेंशियल भेजे जाने से पहले अस्वीकार किया जा सकता है।

सिस्टम के OpenSSL से एंडपॉइंट जाँचें, वास्तविक होस्टनाम और वह पोर्ट इस्तेमाल करते हुए जो क्लाइंट उपयोग करता है।

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com का विफल होना और -tls1 -cipher DEFAULT@SECLEVEL=0 का सफल होना बताता है कि सीमा संस्करण और कुंजी आकार दोनों है। यदि पहला आदेश प्रोटोकॉल चेतावनी के बजाय छोटी DH कुंजी बताता है, तो संस्करण ठीक है और केवल समूह पर ध्यान देना है। जाँच में कभी निजी कुंजी या पासवर्ड न डालें।

विकल्प 1: क्रिप्टो नीति से पूरे होस्ट को ढीला करें

Fedora और RHEL 8 और 9 पर, update-crypto-policies --set LEGACY OpenSSL की सिस्टम नीति नीचे लाता है, और update-crypto-policies --show पुष्टि करता है कि क्या सक्रिय है। यह आमतौर पर टनल बहाल करता है, लेकिन नीति प्रक्रिया शुरू होने पर पढ़ी जाती है, इसलिए फिर से परीक्षण से पहले क्लाइंट और उसके द्वारा बनाई गई किसी भी सहायक प्रक्रिया को पुनः आरंभ करें। यह मशीन पर हर TLS क्लाइंट के लिए पुराने प्रोटोकॉल और कमजोर समूहों की भी अनुमति देता है, बगल की खिड़की के ब्राउज़र से लेकर कर्नेल अपडेट करने वाले पैकेज प्रबंधक तक।

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

Debian और Ubuntu के पास इसके लिए एक भी स्विच नहीं है। समकक्ष /etc/ssl/openssl.cnf में संपादन है जो सिस्टम डिफ़ॉल्ट अनुभाग में निचला MinProtocol और CipherString = DEFAULT@SECLEVEL=0 सेट करता है। वही दायरा, अलग फ़ाइल, रिलीज़ अपग्रेड के दौरान थोड़ा और आसानी से नज़र से ओझल।

विकल्प 2: एक क्लाइंट के लिए एक कॉन्फ़िग फ़ाइल

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

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

OPENSSL_CONF को उस फ़ाइल की ओर इंगित करें और VPN क्लाइंट को ऐसे रैपर से शुरू करें जो उसे एक्सपोर्ट करता है। होस्ट पर बाकी सब डिफ़ॉल्ट नीति रखता है, और अनुपालन का सवाल आने पर यही गुण मायने रखता है। गेटवे को दोष देने से पहले पुष्टि करें कि फ़ाइल वास्तव में लागू है: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 को TLS 1.0 सिफ़र सूचीबद्ध करने चाहिए, और खाली परिणाम का अर्थ है कि श्रृंखला टूटी है और क्लाइंट ने चुपचाप सिस्टम डिफ़ॉल्ट रखे हैं।

फ़ाइल संस्करण-संवेदी है। OpenSSL 1.1.1 और 3.x वही अनुभाग नाम स्वीकार करते हैं, लेकिन प्रदाताओं के आसपास निर्देशों का प्रसंस्करण 3.x में बदल गया, इसलिए फ़ाइल पढ़ी गई मानने के बजाय क्लाइंट के लॉग और परीक्षण हैंडशेक से सत्यापित करें। अनुभाग नाम में टाइपो खुलकर विफल होता है, और क्लाइंट चुपचाप सिस्टम डिफ़ॉल्ट उपयोग करता है।

सीमा कवरेज है। GnuTLS या NSS से जुड़ा कुछ भी OPENSSL_CONF को अनदेखा करता है, और क्लाइंट द्वारा पर्यावरण विरासत में लिए बिना शुरू की गई कोई भी सहायक प्रक्रिया भी। रैपर बनाने से पहले ldd से जाँचें कि बाइनरी वास्तव में किस TLS लाइब्रेरी से जुड़ी है, क्योंकि उत्तर ही तय करता है कि यह विकल्प है भी या नहीं।

विकल्प 3: एक बार इस्तेमाल होने वाला VM या कंटेनर

दो हफ़्ते तक एक पुराने गेटवे पर हमला करने वाले ठेकेदार के लिए, ढीली नीति वाला समर्पित VM वर्कस्टेशन से साफ़ सीमा है। पुरानी सतह और रोज़मर्रा की ब्राउज़र प्रोफ़ाइल अब कर्नेल नीति साझा नहीं करतीं, और निपटान ऑडिट निष्कर्ष नहीं, मिटाना है।

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

तुलना आपको क्या छोड़ती है

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

टिकाऊ सुधार उपकरण पर ही है: TLS 1.2 या बाद का, कम से कम 2048 बिट का समूह, AEAD सिफ़र और आधुनिक हस्ताक्षर वाला प्रमाणपत्र। उपकरण के मालिक से यह बदलाव माँगें, फिर क्लाइंट लॉग में बातचीत किया गया संस्करण और सिफ़र पुष्ट करें। अपवाद को होस्ट, गेटवे, बातचीत किए गए प्रोटोकॉल, स्वीकृति देने वाले और समाप्ति तिथि के साथ लिखें, क्योंकि यही नोट अस्थायी समाधान को डिफ़ॉल्ट बनने से रोकता है।