ca md too weak: سرٹیفکیٹ دوبارہ جاری کریں یا سطح کم کریں؟

OpenVPN کلائنٹ گزشتہ ماہ کام کرتا تھا، اب آغاز پر اس نقص کے ساتھ ناکام ہوتا ہے: ca md too weak, اور ڈسک پر موجود پروفائل اسی کے ساتھ بائٹ بائٹ یکساں ہے جو کام کرتا تھا۔ پیغام سرٹیفکیٹ اتھارٹی کے سرٹیفکیٹ پر دستخط کے بارے میں ہے، ڈیٹا سائفر، auth ڈائجسٹ یا اکاؤنٹ پاس ورڈ کے بارے میں نہیں۔ تین شرطیں طے کرتی ہیں کہ حل نیا شناختی مواد ہے، نیا چین ہے، یا جان بوجھ کر پالیسی تبدیلی ہے۔ انہیں ترتیب سے کریں، پھر میزبان پر ہر TLS کنکشن کمزور کر کے سرنگ واپس لانے کے عام نتیجے سے بچ جائیں گے۔

نقص دراصل کس کا نام لیتا ہے

OpenSSL یہ توثیقی نقص چین بناتے وقت اٹھاتا ہے، جب CA کے طور پر کام کرنے والا سرٹیفکیٹ ایسا دستخطی ڈائجسٹ رکھتا ہے جسے لائبریری کی سکیورٹی سطح اب قبول نہیں کرتی۔ MD5 ڈیفالٹ سطح پر مسترد ہوتا ہے، اور SHA-1 سطح بڑھانے پر مسترد ہوتا ہے۔ یہاں پتے کے سرٹیفکیٹ کا ڈائجسٹ اس جاری کنندہ کے ڈائجسٹ سے کم اہم ہے جو اس پر دستخط کرتا ہے۔ وہی پالیسی کسی ایسی جڑ کو بھی مسترد کر سکتی ہے جو جاری ہونے کے دن بالکل عام تھی۔

اسی لیے auth یا data-ciphers میں ترمیم اس ناکامی کے لیے کچھ نہیں کرتی۔ وہ سیٹنگز بتاتی ہیں کہ مصافحے کے بعد پیکٹ کیسے محفوظ ہوتے ہیں، جبکہ مسترد شدہ شے شناختی دستاویز ہے جو سرنگ وجود میں آنے سے پہلے جانچی جاتی ہے۔ سرٹیفکیٹ اپنی مدتِ اعتبار کے اندر آرام سے رہ سکتا ہے اور پھر بھی ایسا دستخط رکھ سکتا ہے جو لائبریری قبول نہیں کرے گی۔

جانچوں کو ذہن میں الگ رکھیں، پھر نقص پراسرار لگنا بند ہو جائے گا۔ مدتِ اعتبار کی تاریخیں، کلید کا استعمال اور دستخطی ڈائجسٹ خودمختار جانچیں ہیں، اور ان میں سے بالکل ایک ابھی ناکام ہوئی ہے۔

پہلی شرط: کیا مسترد شدہ شے جڑ ہے؟

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

یکجا CA فائلوں میں اکثر کئی بلاک ہوتے ہیں، اس لیے پہلے کو ہی قصوروار ماننے کے بجائے وہ بلاک پہچانیں جو واقعی لوڈ ہوتا ہے۔ کمانڈ openssl x509 -in ca.pem -noout -subject -issuer -text ایک وقت میں ایک سرٹیفکیٹ بیان کرتی ہے، یعنی اگر بنڈل میں زیادہ ہوں تو پہلے اسے الگ کرنا ہوگا۔ چھاپے گئے دستخطی الگورتھم کا موازنہ اس ڈائجسٹ سے کریں جس کی جڑ بننے کے دور سے توقع رکھتے ہیں۔

کمزور جڑ کے نیچے SHA-256 سے دستخط شدہ پتہ بھی ناکام ہوتا ہے، کیونکہ چین کی جانچ بالکل اوپر تک جاتی ہے۔ یہی ترتیب اگلی شرط کو اہم بناتی ہے۔

دوسری شرط: کیا جاری کنندہ آپ کے کنٹرول میں ہے؟

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

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

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

تیسری شرط: سطح کم کرنا اور کیا قبول کرتا ہے

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

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

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

فیصلہ، بطور قاعدہ لکھا گیا

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

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