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 توثیق لے کر چلتا ہے، اس لیے جدید پروٹوکول ورژن اس بارے میں کچھ نہیں کہتا کہ کون صارف مجاز تھا یا سیشن کن وسائل تک پہنچ سکتا ہے۔ یہ الگ کنٹرول ہیں الگ ثبوتوں کے ساتھ۔

نتیجہ سروس، بیک اینڈ، اجازت شدہ پالیسی اور مشاہدہ شدہ ورژن کے طور پر لکھیں۔ ایسا ریکارڈ سیکیورٹی سوال کا درست جواب دیتا ہے، جو نہ لیبل والی دلیل دیتی ہے نہ تکلیف والی دلیل۔