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 साइफर, र आधुनिक हस्ताक्षरको प्रमाणपत्र। त्यो परिवर्तन उपकरणको मालिकसँग माग्नुहोस्, त्यसपछि क्लाइन्ट लगमा वार्ता गरिएको संस्करण र साइफर पुष्टि गर्नुहोस्। अपवादलाई होस्ट, गेटवे, वार्ता गरिएको प्रोटोकल, स्वीकृत गर्ने र म्याद सकिने मितिसँगै लेख्नुहोस्, किनकि अस्थायी समाधान पूर्वनिर्धारित बन्नबाट रोक्ने त्यही टिप्पणी हो।

सम्बन्धित लेखहरू