TLS त्रुटिहरू कम्पनीको VPN मा मात्र: सही भरोसा भण्डार ठीक गर्नुहोस्

Go बिल्ड, Composer इन्स्टल र Python क्लाइन्ट सबै घरमा काम गर्छन् र सबै कम्पनीको VPN भित्र असफल हुन्छन्। यो ढाँचाले तपाईंलाई अनुप्रयोगको बारेमा होइन, बाटोको बारेमा भन्छ। सुरुङमा केही कुराले तपाईंको प्रक्रियाले देख्ने प्रमाणपत्र शृंखला बदल्यो, वा कुनै शृंखला आउनुअघि नै हात मिलाउने क्रम रिसेट गर्यो। दुवै खराबी टर्मिनलमा उस्तै देखिन्छन् र पूर्ण रूपमा फरक प्रतिक्रिया माग्छन्।

तीन सन्देश, तीन संयन्त्र

x509 certificate signed by unknown authority त्रुटिको अर्थ शृंखला बनियो र त्यसको जरा त्यो प्रक्रियाले प्रयोग गर्ने भरोसा भण्डारमा छैन। self-signed certificate in certificate chain त्रुटिको अर्थ सामान्यतया जाँच प्रोक्सीले आफ्नै प्रमाणपत्रले जवाफ दियो, र त्यो यस्तो शृंखला हो जुन तपाईंको रनटाइमले चिन्दैन। हात मिलाउने क्रममा SSL EOF भन्नाले कुनै पनि उपयोगी प्रमाणपत्र पठाउनुअघि नै जडान बन्द भयो, र त्यो ClientHello अस्वीकार गर्ने मध्यस्थ उपकरण हो, भरोसाको समस्या नै होइन।

असुरक्षित झन्डा थप्दा तीनै सन्देश हराउँछन् तर अवरोध आफ्नै ठाउँमा रहन्छ, र वास्तविक आक्रमणकारीलाई समात्ने जाँच पनि हटाइदिन्छ।

प्रक्रियाले वास्तवमै पढ्ने बन्डल खोज्नुहोस्

Windows भण्डारमा इन्स्टल गरिएको कम्पनीको जराले प्रणाली भण्डार हेर्ने ब्राउजर र .NET अनुप्रयोगहरू ठीक गर्छ। कन्टेनर भित्र चल्ने बिल्डका लागि यसले केही गर्दैन, किनकि त्यसको आफ्नै CA बन्डल हुन्छ, र certifi प्रयोग गर्ने Python प्रक्रिया वा आफ्नै समावेशी सूची प्रयोग गर्ने Node प्रक्रियाका लागि पनि केही गर्दैन। Go बाइनरी जुन वातावरणमा चल्छ त्यसको प्रणाली पूल पढ्छ, अर्थात् कन्टेनर, ल्यापटप होइन। त्यसैले एउटै मेसिनले एकै समयमा चल्ने ब्राउजर र असफल हुने बिल्ड उपकरण दिन्छ।

अनुमान गर्नुको सट्टा उपकरणलाई सोध्नुहोस्। python3 -c "import ssl; print(ssl.get_default_verify_paths())" Python ले हेर्ने फाइलहरू छाप्छ, र node -e "console.log(process.env.NODE_EXTRA_CA_CERTS)" ओभरराइड पहिले नै सेट छ कि छैन देखाउँछ। कन्टेनरका लागि, त्यही जाँच इमेजभित्रै चलाउनुहोस्, किनकि बिल्डले वास्तवमै त्यही वातावरण प्रयोग गर्छ।

बिल्ड चल्ने ठाउँमै एउटा जरा इन्स्टल गर्नुहोस्

जाँच जरा IT बाट PEM फाइलको रूपमा लिनुहोस् र भरोसा गर्नुअघि छुट्टै च्यानलबाट यसको औंलाको छाप प्रमाणित गर्नुहोस्। Debian आधारित इमेजमा, यसलाई /usr/local/share/ca-certificates/ मा प्रतिलिपि गरेर update-ca-certificates चलाउनुहोस्; RHEL परिवारका इमेजले फाइल /etc/pki/ca-trust/source/anchors/ मा राखेपछि update-ca-trust प्रयोग गर्छन्। कन्टेनर बिल्डमा, असफल हुने आदेशअघि यी चरणहरू थप्नुहोस् ताकि तह निर्भरता इन्स्टलमाथि क्यास होस्।

स्थानीय devcontainer का लागि, PEM माउन्ट गर्नुहोस् र सुरुमै त्यही अद्यावधिक आदेश चलाउनुहोस्, अरू कसैले पुनरुत्पादन गर्न नसक्ने व्यक्तिगत इमेजमा पकाउनुको सट्टा। आफ्नै बन्डल ल्याउने उपकरणलाई आफ्नै अभिलेखित ओभरराइड चाहिन्छ: pip मा प्रमाणपत्र सेटिङ छ, npm मा cafile सेटिङ छ, र बाँकी अधिकांशले मानक वातावरण चर स्वीकार गर्छन्।

यो कुनै पनि प्रमाणपत्र स्वीकार गर्नुजस्तै होइन। तपाईं जाँच गर्ने पक्षबाट प्राप्त एउटा निश्चित जरा एउटा वातावरणमा थप्नुहुन्छ, र बाँकी हरेक शृंखलाका लागि प्रमाणीकरण खुला रहन्छ। कुन फाइल कहिले थपियो र कहिले सकिन्छ लेख्नुहोस्, किनकि जाँच जरा अरू कुनै CA जस्तै नवीकरण हुन्छ।

जब हात मिलाउने क्रम प्रमाणपत्रअघि मर्छ

यदि केही पनि प्रस्तुत गरिएन भने, भरोसा भण्डारको कुनै पनि परिवर्तनले मद्दत गर्दैन। त्यही अनुरोधलाई सुरुङ खुला र बन्द अवस्थामा तुलना गर्नुहोस्, त्यसपछि openssl s_client -connect host:443 -servername host -showcerts ले शृंखला सिधै जाँच्नुहोस्। VPN बाहिर पूरा भई भित्र रिसेट हुने जडान मध्यस्थ उपकरणको नीति निर्णय हो, र उपचार त्यो होस्टका लागि अपवाद हो, अर्को प्रमाणपत्र होइन। प्याकेज रजिस्ट्री वा API अन्त्य बिन्दु बिना परिवर्तन जान दिन अनुरोध गर्नुहोस्।

उपकरणले VPN छल्ने गरी सुरुङ विभाजन गर्दा त्यो ट्राफिकको जाँच टर्छ, जसले नीति उल्लंघन गर्न सक्छ र उपकरणलाई विश्वसनीय बनाउँदैन।

हरेक उपकरणका लागि नतिजा लेख्नुहोस्

बाइनरी, त्यसले पढ्ने भरोसा फाइल, खेलमा रहेको वातावरण चर र स्वीकृत अपवाद सूचीबद्ध गर्ने छोटो टिप्पणीले अर्को व्यक्तिको सम्पूर्ण निदान बचाउँछ। टिप्पणी ल्यापटपअनुसार होइन, उपकरणअनुसार राख्नुहोस्, किनकि बदलिएको कुरा ल्यापटप हुनु दुर्लभ छ।

र टिकटमा दुई वाक्य अलग राख्नुहोस्: हामीले एउटा निश्चित कम्पनी जरा इन्स्टल गर्यौं, र हामीले प्रमाणीकरण बन्द गर्यौं। तीमध्ये एउटा मात्र सहयोग कार्य हो।