OpenVPN پروفائل میں سرٹیفکیٹ کے تین بلاک ہوتے ہیں: کون سا خفیہ ہے؟

ایک لائن بدلنے کے لیے آپ .ovpn فائل کھولتے ہیں اور base64 کے تین بلاک پاتے ہیں جو سب شناختی معلومات جیسے لگتے ہیں۔ ایک شائع کرنے کے لیے محفوظ ہے، دوسرا پاس ورڈ جتنا حساس ہے، اور تیسرا ایک عوامی کلید ہے جس کا کوئی مطلب نہیں جب تک اس کی جوڑی سے کچھ اور دستخط نہ کیا جائے۔ لوگ پوری فائل مدد کے دھاگے میں چپکا دیتے ہیں کیونکہ بلاک ایک دوسرے کی جگہ استعمال ہونے والے لگتے ہیں، اور اسی طرح کلائنٹ کلید عوامی محفوظ شدہ دستاویز میں پہنچ جاتی ہے۔ یہ الگ کرنا کہ کون سا بلاک کیا کرتا ہے ان پروفائلز کے گرد زیادہ تر الجھن کی وضاحت کرتا ہے، اور یہ بھی بتاتا ہے کہ کون سی خرابیاں آپ کو خود ٹھیک کرنی ہیں۔

ایک فائل، تین بلاک، مختلف کام

عام پروفائل BEGIN اور END نشانوں کے درمیان ca بلاک، cert بلاک اور key بلاک رکھتی ہے، یا انہی تینوں کی طرف الگ فائلوں کے طور پر اشارہ کرتی ہے۔ کچھ پروفائل tls-auth یا tls-crypt کلید کے لیے چوتھا بلاک شامل کرتے ہیں، جو سرٹیفکیٹ نہیں بلکہ مشترکہ راز ہے۔ کلائنٹ ہر بلاک کو اس ہدایت کے مطابق پڑھتا ہے جو اس کا نام دیتی ہے، اس لیے لیبل ان کے ظاہر ہونے کی ترتیب سے زیادہ اہم ہیں۔

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

بلاک کے ارد گرد کی ہدایات طے کرتی ہیں کہ وہ کیسے استعمال ہوں گے۔ ca بدلیں اور کلائنٹ کسی اور اتھارٹی پر بھروسہ کرتا ہے؛ key بدلے بغیر cert بدلیں اور مصافحہ ایسی بے ضابطگی سے ناکام ہوتا ہے جس کا بھروسے سے کوئی تعلق نہیں۔

CA بلاک عوامی ہے، CA کلید کبھی نہیں

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

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

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

سرور اور کلائنٹ سرٹیفکیٹ مخالف سمتوں کی طرف اشارہ کرتے ہیں

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

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

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

دو مطالبات جو ایک جیسے لگتے ہیں اور نہیں ہیں

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

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

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

صاف مصافحہ کیا ثابت کرتا ہے اور کیا نہیں

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

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