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

परिणाम को सेवा, बैकएंड, अनुमत नीति और देखा गया संस्करण के रूप में लिखें। ऐसा रिकॉर्ड सुरक्षा प्रश्न का सटीक जवाब देता है, जो न लेबल वाला तर्क देता है और न असुविधा वाला तर्क।