ایک پرانا پیر TLS 1.0 پر مجبور کرتا ہے: استثنا محدود کریں، ہوسٹ نہیں

ایک پرانا آلہ سامنے آتا ہے، جڑ نہیں پاتا، اور سب سے تیز نظر آنے والی مرمت یہ ہے کہ پورے ہوسٹ کو کمزور کر دیا جائے جب تک کنکشن کامیاب نہ ہو۔ وہ تبادلہ اسی لمحے نظر نہیں آتا اور عملاً مستقل ہو جاتا ہے، کیونکہ آخر کار کام کرنے والی نچلی حد کوئی نہیں ہٹاتا۔ دباؤ دو بالکل مختلف خرابیوں سے پیدا ہوتا ہے، اور ان میں سے صرف ایک کا تعلق سائفرز سے ہے۔ پہلے خرابی کی درجہ بندی کریں، پھر استثنا وہاں رکھیں جہاں سے وہ پھیل نہیں سکتا۔

ہدایت بدلنے سے پہلے ناکامی کو دو حصوں میں تقسیم کریں

مشترکہ سائفر نہ ہونے یا غیر تعاون یافتہ پروٹوکول ورژن کے بارے میں سرور لاگ لائن کنٹرول چینل سے آتی ہے: دونوں سرے اس بات پر متفق نہیں ہو سکے کہ خود گفت و شنید کو کیسے محفوظ کیا جائے۔ کلائنٹ کی وہ لائن جو کہتی ہے کہ سرور سرٹیفکیٹ کی تصدیق کا کوئی طریقہ فعال نہیں، بالکل کسی اور جگہ سے آتی ہے، کیونکہ وہ کلائنٹ یہ بھی نہیں دیکھتا کہ جواب کس نے دیا۔ ڈیٹا سائفر بدلنے سے دوسری صورت میں کچھ نہیں ہوتا، اور کردار کی جانچ شامل کرنے سے پہلی میں کچھ نہیں ہوتا۔

منقطع ہونے سے پہلے کی آخری لائن نہیں، بلکہ ہر فریق کی سب سے پہلی ناکام لائن لیں، کیونکہ آخری عموماً صرف نتیجہ ہوتی ہے۔ پھر معلوم کریں کہ کلائنٹ نے واقعی کون سی فائل کھولی: درآمد شدہ پروفائل اکثر مختلف ظاہری ناموں کے ساتھ دو بار ہوتا ہے، اور اس کاپی میں ترمیم کرنا جسے کوئی نہیں پڑھتا، ایک قائل کرنے والی تبدیلی نہ ہونے کی کیفیت پیدا کرتا ہے۔ چلتی ہوئی پروسیس وہی ترتیبات رکھتی ہے جن کے ساتھ شروع ہوئی تھی، اس لیے محفوظ شدہ فائل لوڈ شدہ فائل نہیں ہوتی۔ نیچے دیے گئے کمانڈز اسی کوشش کی کلائنٹ گفت و شنید اور سرور کا نقطہ نظر ساتھ ساتھ دکھاتے ہیں۔

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

کمزور نچلی حد کے لیے دوسرا سننے والا ہی دیانت دار جگہ ہے

جب آلہ 2.5 سے پہلے کے ڈیٹا چینل کے ساتھ TLS 1.0 پر رک جاتا ہے، تو سرور کو کنٹرول چینل کی کم نچلی حد اور ایسا ڈیٹا سائفر پیش کرنا ہوتا ہے جسے پرانا کلائنٹ پہچانتا ہو۔ فال بیک ہدایت بالکل اسی پیر کے لیے ہے، جبکہ سائفر فہرست جدید کلائنٹس کو جدید سوٹس پر رکھتی ہے۔ دونوں ہدایات سننے والے کی ہیں نہ کہ صارف یا کنکشن کی، اور بعد میں کوئی بھی فی کلائنٹ آپشن انہیں تنگ نہیں کرتا۔ اسی لیے مرکزی پورٹ پر ایک پرانا آلہ ہونا ہر اس پیر کے بارے میں فیصلہ ہے جو وہ پورٹ شیئر کرتا ہے۔

جہاں پلیٹ فارم اجازت دے، پرانے سننے والے کو الگ پورٹ پر اس کی اپنی مثال کے طور پر چلائیں، اس پورٹ کی اجازت صرف آلے کے پتے سے دیں، اور مرکزی سروس کو چھیڑیں نہیں۔ دوسرا سننے والا کیوں موجود ہے یہ اس فائل میں لکھیں جس میں اس کی ترتیب ہے، ورنہ آئندہ کی صفائی اسے بچا ہوا کچرا سمجھے گی۔ تقسیم کی قدر صرف تب ہے جب کمزور نچلی حد وہیں ختم ہو جہاں آلہ ختم ہوتا ہے۔

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

پرانا فراہم کنندہ سرٹیفکیٹ اصل میں کیا توڑتا ہے

تصدیق کی خرابی ایک غائب کردار بندی ہے: اس کے بغیر کلائنٹ ہر وہ سرٹیفکیٹ قبول کرے گا جو کسی قابل اعتماد CA سے جڑا ہو، چاہے وہ سرور کے لیے جاری کیا گیا ہو یا نہیں۔ پہلے سرٹیفکیٹ کو سرور کے کردار سے باندھیں، اور بندی کو ٹیوننگ نوب نہیں بلکہ ضرورت سمجھیں۔ صرف وہی پروفائل جس میں اس مرحلے کے بعد بھی ناکامی ہو، حقیقی سرٹیفکیٹ مسئلہ رکھتا ہے۔

پرانا فراہم کنندہ سرٹیفکیٹ جس کی کلید کا سائز یا دستخطی الگورتھم اب OpenSSL کی طے شدہ پالیسی پر پورا نہیں اترتا، کنٹرول چینل پر محدود سیکیورٹی سطح کی تبدیلی کا معاملہ ہے۔ وہاں سطح کم کرنا تصدیق کو بند نہیں کرتا، اور اسے کبھی خالی CA، غیر فعال تصدیق یا غیر جانچے گئے ہوسٹ نام کے ساتھ نہیں ملانا چاہیے۔ لائن کو اسی ایک پروفائل کے اندر رکھیں جسے اس کی ضرورت ہے؛ نرم کی گئی OpenSSL ترتیب کو عالمی طور پر برآمد کرنا مشین کے ہر پروگرام کو وہی نرمی دے گا۔

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

بینر نہیں، طے شدہ اقدار پڑھیں

verbosity 4 پر دونوں سرے وہ کنٹرول چینل TLS ورژن اور سائفر چھاپتے ہیں جن پر وہ متفق ہوئے، اور سیشن کا ڈیٹا سائفر۔ وہ لائنیں پڑھیں نہ کہ ابتدائی بینر، جو کامیابی کی اطلاع دیتا ہے نہ کہ اس کی شرائط۔ پھر جدید کلائنٹ کو مرکزی سننے والے سے دوبارہ جوڑیں اور تصدیق کریں کہ وہ اب بھی جدید سوٹ پر اترتا ہے، کیونکہ مشترکہ ترتیب میں رس گیا استثنا سب سے پہلے یہیں ظاہر ہوتا ہے۔ آپ کی نقل کی گئی اقدار اگلے جائزے کی بنیاد بنتی ہیں۔

پرانا آلہ تنہا آزمائیں: اسے جڑنا چاہیے، اور لاگز میں کمزور پیرامیٹر دکھانے والا واحد سیشن وہی ہونا چاہیے۔ اگر دوسرا پیر بھی پرانے سوٹ پر گفت و شنید کرے، تو استثنا ارادے سے زیادہ وسیع ہے اور سننے والوں کی تقسیم واقعی نہیں ہوئی۔ صرف نتیجہ نہیں، دونوں مشاہدے درج کریں۔

ہر استثنا کے لیے مالک اور تاریخ ضروری ہے

ہٹانے کی شرط کے بغیر استثنا خاموشی سے طے شدہ بن جاتا ہے، اس لیے آلہ، مالک، وجہ اور وہ تاریخ جب یہ جاتا ہے، اس ترتیب کے پاس رکھیں جسے یہ جائز ٹھہراتا ہے۔ اس لائن کے بغیر کمزور نچلی حد اس ہارڈ ویئر سے زیادہ زندہ رہتی ہے جسے اس کی ضرورت تھی۔

کلائنٹ بدلنا، یا فراہم کنندہ سے موجودہ پروفائل مانگنا، وہ نتیجہ ہے جس کا ہدف ہونا چاہیے؛ استثنا تاخیر ہے، ڈیزائن نہیں۔ جب آلہ ریٹائر ہو، سننے والے اور پروفائل کو ایک ہی تبدیلی میں ہٹا دیں تاکہ کوئی بھی آدھا چلتا نہ رہے۔ ان میں سے کچھ بھی پرانے پیرامیٹرز کو محفوظ نہیں بناتا، یہ صرف ایک آلے کی حد کو سب کی بنیاد بننے سے روکتا ہے۔