OpenVPN میں TLS سائفر کی خرابی: پہلے دونوں فریقوں کا موازنہ کریں

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

یہ ترتیب غلط ہو تو کبھی نہ دیکھی گئی فہرست میں AES نام شامل کرنے میں ایک گھنٹہ ضائع ہو سکتا ہے۔

دو سائفر فہرستیں، اور ہینڈ شیک توڑتی صرف ایک ہے

کنٹرول چینل TLS سیشن پر مذاکرات کرتا ہے، اور اس کی پالیسی اس سے لکھی جاتی ہے: tls-cipher TLS 1.2 کے لیے اور tls-ciphersuites TLS 1.3 کے لیے۔ ڈیٹا چینل الگ سے اس سے ترتیب دیا جاتا ہے: data-ciphers، جہاں عدم مطابقت ایسا کنکشن بناتی ہے جو قائم ہوتا ہے اور پھر ٹریفک گزر نہیں سکتا۔ دونوں سائفر کا ذکر کرنے والی خرابیاں دیتے ہیں، اسی لیے انہیں خلط ملط کیا جاتا ہے۔ کبھی مکمل نہ ہونے والا ہینڈ شیک کنٹرول چینل کی طرف اشارہ کرتا ہے، جبکہ قائم شدہ سرنگ پیکٹ گراتی ہو تو وہ ڈیٹا چینل کی طرف۔

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

سوٹ کا موازنہ کرنے سے پہلے ورژن کا موازنہ کریں

TLS 1.2 تک محدود فریق اور 1.3 لازمی سمجھنے والا فریق کوئی مشترک ورژن نہیں رکھتے، اور کوئی سائفر سٹرنگ اسے نہیں جوڑتی۔ دونوں طرف tls-version-min اور tls-version-max درج کریں، یا استعمال ہونے والے بلڈز کے طے شدہ اقدار، کیونکہ کسی تقسیم کی OpenSSL پالیسی کسی OpenVPN آپشن کے بتائے بغیر کم از کم حد بڑھا سکتی ہے۔ اگر ایک فریق آلہ یا تیسرے فریق کا کلائنٹ ہو تو اس کی ونڈو وہی ہے جس کی اس کا فرم ویئر اجازت دیتا ہے۔ ونڈوز کے باہم چھپنے کے بعد ہی سوٹ کا موازنہ معنی رکھتا ہے۔

ان ریکارڈز میں اصل بائنری فائلوں کے نام بھی ہونے چاہئیں۔ آپ کے لیپ ٹاپ پر کمانڈ لائن openvpn ضروری نہیں کہ وہی کلائنٹ ہو جو درآمد شدہ پروفائل سنبھالتا ہے۔

TLS 1.2 اور TLS 1.3 کی فہرستیں آپس میں نہیں ملتیں

TLS 1.2 سوٹ کے نام ایسے دکھتے ہیں: ECDHE-RSA-AES256-GCM-SHA384 اور وہ tls-cipher میں جاتے ہیں، جو OpenSSL سائفر سٹرنگ لیتا ہے۔ TLS 1.3 سوٹ کے نام ایسے ہیں: TLS_AES_256_GCM_SHA384 اور وہ tls-ciphersuites میں جاتے ہیں؛ 1.2 سٹرنگ میں ایک شامل کرنے سے 1.3 فہرست ترتیب نہیں پاتی، اور پارسر متن کو کبھی نہ ملائے بغیر قبول کر سکتا ہے۔ ایک ورژن کے لیے درست فلٹر دوسرے کے بارے میں کچھ نہیں کہتا۔ لکھیں کہ کون سی فہرست کس ورژن کے لیے ہے۔

openvpn --show-tls مقامی بلڈ کس چیز کی تائید کرتا ہے یہ چھاپتا ہے، اور یہ فہرست ہے، وعدہ نہیں: دور کا فریق ان سوٹس کی اجازت نہ دے، اور فعال پروفائل انہیں فعال نہ کرے۔ اسے ایسے بلڈ کو خارج کرنے کے لیے استعمال کریں جو کوئی سوٹ ہی پیش نہیں کر سکتا، پھر ترتیب شدہ فہرستوں کا موازنہ کریں۔

نئے کنکشن پر مذاکرات ثابت کریں

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

اگر کوئی منظور شدہ مشترک ترتیب نہ ہو تو جواب اپ گریڈ یا منتقلی کا منصوبہ ہے، کمزور کی گئی پالیسی نہیں۔ tls-version-min کم کرنا، تصدیق بند کرنا یا تمام پرانے سوٹ فعال کرنا اس حفاظتی تقاضے کو پورا کیے بغیر انکار ہٹا دیتا ہے جس نے اسے پیدا کیا۔

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