SSTP र SSL 3.0: लेबल बनाम सहमत भएको संस्करण

दुई जनाले एउटै SSTP परिनियोजन हेरेर विपरीत निष्कर्षमा पुग्न सक्छन्। एकजनाले उत्पादनको कागजात पढ्छ, SSL अक्षर देख्छ र सुरुङले वर्षौं अघि हटाइएको प्रोटोकल चलाइरहेको मान्छ। अर्कोले आधुनिक ह्यान्डशेकतर्फ देखाउँछ र प्रश्न सकिएको भन्छ। दुवैले लेबलबाट बहस गर्छन्, सहमत भएको संस्करणबाट होइन, र यीमध्ये एउटा मात्र प्रमाण हो। गर्न लायक तुलना भनेको नामले के वाचा गर्छ र सेवाले वास्तवमै के छान्छ भन्नेबीचको हो।

एउटै प्रश्नका दुई उत्तर

लेबलको तर्क भन्न सजिलो छ: SSTP लाई सुरक्षित सकेट टनेलिङ प्रोटोकल भनिन्छ, ऐतिहासिक नामले SSL भन्छ, त्यसैले जडान SSL 3.0 हुनुपर्छ। यो टिक्छ किनकि नाम साँच्चै त्यही परम्पराबाट आएको हो, र किनकि दोहोर्याउने अधिकांशले कहिल्यै ह्यान्डशेक हेरेका छैनन्। यो यसकारण पनि टिक्छ कि निष्कर्ष सतर्क सुनिन्छ, मानौं सबैभन्दा नराम्रो मान्नु नै सुरक्षित विकल्प हो। सबैभन्दा नराम्रो मान्नु र वास्तविक संस्करण नाप्नु दुई फरक काम हुन्, र यीमध्ये एउटाले मात्र केही बदल्छ।

प्रमाणको तर्क अझ साँघुरो प्रश्न सोध्छ। यो क्लाइन्ट र यो सर्भर यही अन्त्यबिन्दुमा, यही समयमा कुन प्रोटोकल संस्करणमा सहमत भए? उत्तर त्यो सेवाबाट आउँछ जसले TLS अन्त्य गर्छ, कुनै मार्केटिङ पृष्ठ वा मिल्दो नामको वेबसाइटमा पुगेको ब्राउजरबाट होइन।

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

सेवाले वास्तवमै छान्ने संस्करण पढ्नुहोस्

घटकहरूको नामबाट सुरु गर्नुहोस्: क्लाइन्ट कार्यान्वयन, सर्भर कार्यान्वयन, TLS अन्त्यबिन्दु र बीचमा TLS अन्त्य गरेर पुनः स्थापना गर्ने सबै कुरा। TLS अन्त्य गरेर ब्याकएन्डसँग साधारण HTTP बोल्ने लोड ब्यालेन्सरले तपाईंले कुन यन्त्रको नीति पढ्नुपर्ने हो त्यो बदल्छ।

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

नतिजासँगै अन्त्यबिन्दु र समय लेख्नुहोस्, किनकि पछि नीति बदलिँदा मिति नभएको अवलोकन बेकार हुन्छ। तपाईंलाई चासो लाग्ने प्रयोगकर्ताहरूकै नेटवर्क मार्गमा रहेको क्लाइन्टबाट जाँच दोहोर्याउनुहोस्, किनकि अवरोध गर्ने यन्त्रले आफ्नै सेटिङले TLS अन्त्य गर्न सक्छ। यदि दुई स्थिति मिलेनन् भने तपाईंले महत्त्वपूर्ण घटक भेट्टाउनुभयो। यदि मिले भने तपाईंसँग नाराको सट्टा प्रमाण छ।

रेकर्ड फिल्डलाई वार्ताबाट अलग गर्नुहोस्

एउटा फिल्डमा पुरानो देखिने संस्करण नम्बर SSL 3.0 सत्र जस्तै तथ्य होइन। RFC 7568 ले रेकर्ड तहको संस्करण र सहमत प्रोटोकललाई छुट्टाछुट्टै विषय मान्छ, र ठ्याक्कै यही भेदबाट आत्मविश्वासी गलत उत्तरहरू आउँछन्। सहमत प्रोटोकल पढ्नुहोस्, त्यसपछि साइफर, र त्यसपछि मात्र सत्रबारे निष्कर्ष निकाल्नुहोस्।

त्यही कागजात प्रोटोकलकै बारेमा स्पष्ट छ: SSL 3.0 प्रयोग गर्नु हुँदैन, र यसमा वार्ता वा फर्किने काम निषेध छ। कारण त्यो भाँचिएको CBC संरचना हो जसको POODLE आक्रमणले फाइदा उठायो, र यो प्रोटोकलको गुण हो, कुनै एउटा अनुप्रयोगको कन्फिगरेसन होइन।

त्यसैले “यो कार्यभार सम्भवतः शोषण गर्न गाह्रो छ” SSL 3.0 सक्षम राख्ने तर्क होइन। आवश्यकता प्रोटोकल हटाउनु हो, कुनै एउटा प्रदर्शनमा बहस जित्नु होइन।

SSL 3.0 लाई यस्तो नीतिले हटाउनुहोस् जसको तपाईं बचाउ गर्न सक्नुहुन्छ

Windows मा Schannel का प्रोटोकल सेटिङहरू Protocols कुञ्जीमुनि हुन्छन् र क्लाइन्ट तथा सर्भर भूमिकाका लागि छुट्टाछुट्टै पढिन्छन्, त्यसैले एउटा दिशा सुधार्ने परिवर्तनले अर्को दिशा अछुतो छोड्न सक्छ। हालका सेटिङ र तिनका रिस्टार्ट आवश्यकता Microsoft ले कागजात गरेको छ, र त्यही होस्टमा रहेको तेस्रो-पक्ष TLS लाइब्रेरीले तिनलाई पूर्ण रूपमा बेवास्ता गर्छ।

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

नीति समर्थित प्रशासनिक मार्गबाट बदल्नुहोस्, स्वामी सेवाले आफ्नो कन्फिगरेसन पुनः पढ्छ भन्ने पुष्टि गर्नुहोस्, र फर्कने स्वीकृत मार्ग राख्नुहोस्। अर्को वातावरणबाट फराकिलो रजिस्ट्री स्क्रिप्ट टाँस्नु त्यही मार्ग हो जसले एउटा सेवाको सुधार मेसिनका हरेक TLS क्लाइन्टका लागि अवरोधमा बदल्छ। यहाँ रिस्टार्टको दायरा महत्त्वपूर्ण छ: लागू देखिने सेटिङ अझै पनि त्यसलाई पुनः लोड नगरेको सेवाको स्मृतिमा रहन सक्छ।

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

परिवर्तनलाई नयाँ जडानसँग स्वीकार गर्नुहोस्

नीति परिवर्तनपछि नयाँ सत्रहरूसँग परीक्षण गर्नुहोस्, किनकि परिवर्तन अघि बनेको जडानले अहिले लागू कन्फिगरेसनबारे केही प्रमाणित गर्दैन। स्वीकृत प्रोटोकल सफल हुन्छ र निषेधित प्रोटोकल अधिकृत प्रमाणीकरण प्रक्रियामा असफल हुन्छ भन्ने पुष्टि गर्नुहोस्, त्यसपछि प्रमाणपत्रको पहिचान र विश्वासका जाँच ठ्याक्कै जस्ता थिए तस्तै छोड्नुहोस्।

सम्झनुहोस् ह्यान्डशेकले के समेट्दैन। SSTP ले TLS तहपछि PPP प्रमाणीकरण बोक्छ, त्यसैले आधुनिक प्रोटोकल संस्करणले कुन प्रयोगकर्ता अधिकृत भयो वा सत्र कुन स्रोतसम्म पुग्न सक्छ भन्ने केही भन्दैन। यी छुट्टाछुट्टै नियन्त्रण हुन् छुट्टाछुट्टै प्रमाणसहित।

नतिजा सेवा, ब्याकएन्ड, स्वीकृत नीति र अवलोकित संस्करणका रूपमा लेख्नुहोस्। यस्तो रेकर्डले सुरक्षा प्रश्नको ठ्याक्कै उत्तर दिन्छ, जो लेबलको तर्क वा असुविधाको तर्कले कहिल्यै दिँदैन।