tls-auth اور tls-crypt: OpenVPN میں ہر ایک کیا محفوظ کرتا ہے

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

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

مشترکہ کلید دراصل کس چیز کی حفاظت کرتی ہے

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

tls-auth اس راز کو کنٹرول پیکٹوں پر HMAC شمار کرنے کے لیے استعمال کرتا ہے۔ درست دستخط کے بغیر پیکٹ مزید مہنگی TLS پروسیسنگ تک پہنچنے سے پہلے ہی خارج کر دیا جاتا ہے، اسی لیے اس اختیار کو اکثر TLS کا متبادل نہیں بلکہ پہلا فلٹر کہا جاتا ہے۔

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

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

دونوں اختیارات کہاں مختلف ہیں

دکھائی دینے والا فرق یہ ہے کہ ناظر کیا دیکھتا ہے۔ tls-auth کے ساتھ ہینڈ شیک نظر آتا ہے مگر کلید کے بغیر تصدیق نہیں ہو سکتی۔ tls-crypt کے ساتھ ہینڈ شیک ہر اس شخص کے لیے مبہم ہے جس کے پاس کلید نہیں۔

تشکیل بھی مختلف ہے۔ tls-auth سمت کی قدر کے ساتھ استعمال ہوتا ہے، اس لیے ایک فریق کلیدی مواد کا ایک نصف استعمال کرتا ہے اور دوسرا فریق دوسرا نصف۔ tls-crypt دونوں سمتوں میں ایک ہی کلید استعمال کرتا ہے، اس لیے سمت کی ہدایت اس کی ترتیب کا حصہ نہیں۔

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

ایک نیا انداز، tls-crypt-v2، ہر کلائنٹ کو اس کی اپنی لپٹی ہوئی کلید سے باندھتا ہے تاکہ ایک کلائنٹ کی منسوخی کے لیے گروہی کلید دوبارہ جاری کرنے کی ضرورت نہ ہو۔ یہ جاننے کے قابل ہے، مگر یہ الگ اختیار ہے اور یہاں کے دونوں میں سے کسی کا ہم معنی نہیں۔

عدم مطابقت کیوں ایسے لگتی ہے کہ کچھ ہو ہی نہیں رہا

جب مشترکہ مواد میل نہیں کھاتا، دوسرا سرا بھیجنے والے کو وجہ بتائے بغیر پیکٹ پھینک دیتا ہے۔ پڑھنے کے لیے کوئی توثیقی غلطی نہیں ہوتی، کیونکہ پیکٹ کبھی اس پرت تک پہنچا ہی نہیں جو اسے پیدا کرتی۔

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

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

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

اب بھی کیا الگ ترتیب دینا ہے

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

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

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