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 प्रमाणीकरण वाहते, म्हणून आधुनिक प्रोटोकॉल आवृत्ती कोणता वापरकर्ता अधिकृत झाला किंवा सत्र कोणत्या संसाधनांपर्यंत पोहोचू शकते याबद्दल काहीही सांगत नाही। हे स्वतंत्र नियंत्रणे आहेत स्वतंत्र पुराव्यांसह।

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