خود دستخط شدہ VPN سرٹیفکیٹ: اس کا مطلب کیا ہے اور یہ کس پر بھروسا کرتا ہے

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

سرٹیفکیٹ بھروسے کا ذخیرہ نہیں ہے

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

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

OpenVPN کا ca اختیار ایپ تک محدود بھروسے کی واضح ترین مثال ہے۔ وہ فائل ان اینکرز کے نام دیتی ہے جنہیں کلائنٹ قبول کرے گا، اور اس میں ایک نجی CA یا چھوٹی تعیناتی میں سرور کا اپنا خود دستخط شدہ سرٹیفکیٹ ہو سکتا ہے۔ نسخہ 2.6 CA فائل تقسیم کرنے کے بجائے SHA-256 فنگر پرنٹ پن کرنے کے لیے --peer-fingerprint بھی قبول کرتا ہے۔ WireGuard اس سے بھی آگے ہے: اس میں سرٹیفکیٹ بالکل نہیں، ہر ساتھی کے لیے صرف ایک مستقل عوامی کلید ہے، اس لیے خود دستخط کا سوال اس پر لاگو نہیں ہوتا۔

آپ بھروسا کہاں نصب کرتے ہیں یہ طے کرتا ہے کہ اسے کون وراثت میں پائے گا

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

Debian یا Ubuntu پر، /usr/local/share/ca-certificates/ میں فائل ڈالنا اور update-ca-certificates چلانا پورے سسٹم کی بنڈل بدل دیتا ہے۔ Windows پر، certutil -addstore -f Root مشین کے ذخیرے میں لکھتا ہے اور بلند پرامپٹ مانگتا ہے، جبکہ -user شامل کرنا اس کے بجائے موجودہ صارف کے ذخیرے کو نشانہ بناتا ہے؛ دونوں قابلِ تبادلہ نہیں۔ Firefox اپنا NSS ڈیٹا بیس رکھتا ہے، اس لیے OS سطح کی درآمد وہاں کبھی ظاہر نہ ہو۔

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

آپ اب بھی عوامی CA کے بغیر خفیہ کر رہے ہیں

TLS ہاتھ ملانا سیشن کلیدیں اخذ کرتا ہے، چاہے ساتھی کا سرٹیفکیٹ اس چیز سے زنجیر بند ہو جس پر آپ پہلے سے بھروسا کرتے ہیں یا نہیں۔ خود دستخط شدہ کا مطلب سادہ متن نہیں، اور یہ بھی نہیں کہ ٹریفک پرواز کے دوران پڑھی جا سکتی ہے۔ اس کا مطلب یہ ہے کہ کلائنٹ کے پاس پہلے سے یہ ماننے کی کوئی وجہ نہیں کہ کلید اسی سرور کی ہے جس کی اس نے درخواست کی۔

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

جاری کرنے والے پر بھروسا نام کی جانچ کو نہیں چھوڑتا

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

OpenVPN تقسیم کو نظر آنے والا بناتا ہے۔ verify-x509-name متوقع موضوع کو name، name-prefix یا subject کے میل سے پن کرتا ہے۔ remote-cert-tls server تقاضا کرتا ہے کہ ساتھی کا سرٹیفکیٹ سرور سرٹیفکیٹ کے طور پر قابلِ استعمال ہو، جو صرف کلائنٹ کا سرٹیفکیٹ مسترد کرتا ہے چاہے جاری کرنے والا قابلِ بھروسا ہو۔ دونوں میں سے کوئی ترتیب CA فائل بھیجنے سے تبدیل نہیں ہوتی۔

کوئی بھی فیصلہ کرنے سے پہلے سرٹیفکیٹ دیکھیں:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName دکھاتا ہے کہ کس نے جاری کیا، کن ناموں کے لیے اور کب تک۔
• openssl verify -CAfile ca.crt server.crt جانچتا ہے کہ آپ کی بھیجنے والی زنجیر واقعی پتے کی توثیق کرتی ہے یا نہیں۔
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error ویب پورٹل جیسے TLS آخری مقامات کے لیے کام کرتا ہے؛ 1194 پر OpenVPN پروٹوکول سادہ TLS سلسلہ نہیں، اس لیے وہ جانچ وہاں لاگو نہیں ہوتی۔

میعاد ختم شدہ تاریخ، اس نام کے لیے subjectAltName نہ ہونا جس سے آپ جڑتے ہیں، یا serverAuth استعمال نہ ہونا والا سرٹیفکیٹ اینکر کتنی احتیاط سے نصب کیا گیا ہو، ناکام ہوتا ہے۔

ایک قبول کرنے سے پہلے پانچ جانچیں

فنگر پرنٹ کا موازنہ ایسے ذریعے سے کریں جو وہ رابطہ نہ ہو جسے آپ ٹھیک کرنے کی کوشش کر رہے ہیں: ایک کنسول، آپ کے پاس پہلے سے موجود انسٹالر، ایک دستخط شدہ ترتیباتی فائل۔ سرور پر openssl x509 -in server.crt -noout -fingerprint -sha256 اور کلائنٹ لاگ میں وہی قدر یہ جاننے کے لیے کافی ہیں کہ آپ ایک ہی چیز دیکھ رہے ہیں۔

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

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

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