کیا OpenVPN میں dh none کے ساتھ RSA سرٹیفکیٹ کام کر سکتا ہے؟

یہاں ایک سرور کنفیگریشن ہے جو RSA کہنے والے سرٹیفکیٹ کے ساتھ dh none کہتی ہے، ساتھ ہی یہ کھٹکتی شک کہ دونوں میں سے ایک ضرور غلط ہوگا۔ کچھ بھی غلط نہیں۔ سرٹیفکیٹ دستخط کرتا اور تصدیق کرتا ہے؛ کلید کا تبادلہ مشترکہ راز قائم کرتا ہے۔ یہ ایک ہی ہینڈ شیک میں دو الگ کام ہیں، اور TLS ایک RSA سرٹیفکیٹ کو ایسے ہینڈ شیک کی تصدیق کی اجازت دیتا ہے جو عارضی بیضوی منحنی معاہدہ استعمال کرتا ہے۔

الجھن عموماً ہجرت کی گائیڈ کے ساتھ آتی ہے۔ وہ DH پیرامیٹر فائل کو dh none سے بدلنے کو کہتی ہے، قاری دیکھتا ہے کہ سرٹیفکیٹ بیضوی منحنی سرٹیفکیٹ نہیں، اور دونوں حقائق کو تضاد سمجھا جاتا ہے۔

دو سیٹنگز متعلق کیوں دکھائی دیتی ہیں

OpenVPN کی پرانی کنفیگریشن DH پیرامیٹر فائل مانگتی تھی کیونکہ محدود میدان کا Diffie-Hellman ایسے ڈومین پیرامیٹر چاہتا ہے جن پر دونوں فریق متفق ہوں۔ dh ہدایت اسی فائل کی طرف اشارہ کرتی تھی۔ جب تعیناتی ECDH پر جاتی ہے، پیرامیٹر اس کی بجائے نامزد منحنی سے آتے ہیں، اور فائل کی مزید ضرورت نہیں رہتی، جسے dh none بیان کرتا ہے۔

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

نام رکھنا اوورلیپ کو مزید خراب کرتا ہے۔ بیضوی منحنی ECDHE اور ECDSA دونوں سوٹ ناموں میں آتی ہے، اس لیے یہ مان لینا آسان ہے کہ منحنی کا ذکر کرنے والا ہر رابطہ منحنی سرٹیفکیٹ رکھتا ہوگا۔ ایسا نہیں ہے۔

TLS 1.2 سوٹ نام کو درست طریقے سے پڑھنا

ECDHE-RSA-AES256-GCM-SHA384 لیں۔ پہلا ٹوکن کلید کے تبادلے کا خاندان ہے: عارضی بیضوی منحنی Diffie-Hellman۔ دوسرا تصدیق کا خاندان ہے: RSA۔ باقی ریکارڈ تحفظ اور ہینڈ شیک میں استعمال ہونے والے ہیش کی وضاحت کرتا ہے۔

ECDHE-ECDSA سوٹ وہی کلید تبادلے کا خاندان مختلف تصدیق طریقے کے ساتھ استعمال کرتا ہے، اس لیے اسے بیضوی منحنی سرٹیفکیٹ درکار ہے۔ DHE-RSA سوٹ RSA تصدیق کے ساتھ محدود میدان کا عارضی Diffie-Hellman استعمال کرتا ہے، اور اسے واقعی DH پیرامیٹر درکار ہیں۔

سوٹ نام بائیں سے دائیں پڑھیں اور ہر حصے کو اس کے کام پر لگائیں۔ ٹوکن الگ ہونے کے بعد سوال «کیا میرا سرٹیفکیٹ dh none سے میل کھاتا ہے» سے «کیا میرا سرور ایسے سوٹ کی اجازت دیتا ہے جس کے کلید تبادلے کو DH فائل درکار نہیں» میں بدل جاتا ہے۔

dh none اصل میں کیا غیر فعال کرتا ہے

dh none سرور سے کہتا ہے کہ محدود میدان کی DH پیرامیٹر فائل لوڈ نہ کرے۔ یہ تصدیق، سرٹیفکیٹ کی جانچ یا خود TLS کو غیر فعال نہیں کرتا۔ تاہم یہ تقاضا کرتا ہے کہ طے شدہ کلید تبادلے کو وہ پیرامیٹر درکار نہ ہوں، جس کا عملی مطلب ECDHE سوٹ یا TLS 1.3 ہینڈ شیک ہے۔

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

بیضوی منحنی کی طرف، منحنی سرور کی TLS کنفیگریشن چنتی ہے، اور OpenVPN پرانی شاخوں پر اسے چننے کا اختیار دیتا ہے۔ TLS 1.3 گروپ کے مذاکرات پروٹوکول کے اندر سنبھالتا ہے اور DH فائل کو بالکل نہیں دیکھتا۔

dh none بذات خود حفاظت میں کمی نہیں۔ تبادلے کی طاقت پھر اصل میں طے شدہ منحنی اور سوٹ پر منحصر ہے، اسی لیے اگلا قدم غائب فائل نہیں بلکہ یہ دیکھنا ہے کہ فریقوں نے کیا چنا۔

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

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

اگر یہ TLS 1.2 کے ساتھ ECDHE-RSA سوٹ اور RSA سرٹیفکیٹ دکھائے، تو مجموعہ بالکل وہی ہے جس کی dh none توقع کرتا ہے، اور درست کرنے کو کچھ نہیں۔ اگر یہ DHE سوٹ یا مشترک سائفر کے بغیر ہینڈ شیک کی ناکامی دکھائے، تو حل سائفر پالیسی یا کلائنٹ کی صلاحیت میں ہے، سرٹیفکیٹ میں نہیں۔

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

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

چیک لسٹ: کیا سرٹیفکیٹ RSA ہے، کیا ECDHE سوٹ کی اجازت ہے، کیا لاگ وہ سوٹ دکھاتا ہے، اور کیا معاون سب سے پرانا کلائنٹ بھی اس پر متفق ہوتا ہے؟ اگر چاروں ہاں ہیں، تو dh none اپنا کام کر رہا ہے۔