Linux वर AnyConnect ची अवैध TLS आवृत्ती: आधी दुरुस्तीचा व्याप्ती ठरवा

संपूर्ण होस्टवर लागू होणारे LEGACY धोरण, प्रति प्रक्रिया OpenSSL संरचना आणि एकदाच वापरला जाणारा VM यांची तुलना, शिवाय त्रुटी कायमची दूर करणारा गेटवे बदल.

ही त्रुटी पासवर्डच्या विनंतीपूर्वी येते, आणि तोच उपयुक्त भाग आहे: अजून काहीही प्रमाणित झालेले नाही, त्यामुळे ओळखपत्रे ही समस्या नाही. 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 कडे यासाठी एकच स्विच नाही. समतुल्य म्हणजे सिस्टम डीफॉल्ट विभागात कमी MinProtocol आणि CipherString = DEFAULT@SECLEVEL=0 सेट करणारे /etc/ssl/openssl.cnf संपादन. तीच व्याप्ती, वेगळी फाइल, आवृत्ती अपग्रेडदरम्यान थोडे अधिक सहजपणे नजरेआड होणारे.

पर्याय 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 सायफर आणि आधुनिक स्वाक्षरीचे प्रमाणपत्र. तो बदल उपकरणाच्या मालकाकडे मागा, नंतर क्लायंट लॉगमध्ये वाटाघाटी झालेली आवृत्ती आणि सायफरची पुष्टी करा. अपवाद होस्ट, गेटवे, वाटाघाटी झालेला प्रोटोकॉल, मंजूरी देणारा आणि समाप्ती तारखेसह लिहून ठेवा, कारण तात्पुरता उपाय डीफॉल्ट होण्यापासून रोखणारी तीच नोंद आहे.

संबंधित लेख