VPN میں DES بمقابلہ 3DES: دونوں غلط اپ گریڈ کیوں ہیں

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

جس موازنے کو لوگ اب بھی ڈھونڈتے ہیں وہ غلط ہے

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

NIST نے 2005 میں DES معیار واپس لیا، اور اس کی TDEA سفارش جنوری 2024 میں واپس لی گئی، جب نئی کرپٹوگرافک حفاظت پر TDEA کے اطلاق کی آخری تاریخ 2023 کے آخر میں گزر گئی۔ وہ تاریخیں ایک منتقلی بیان کرتی ہیں، درجہ بندی نہیں۔ مختصر سیشن یا کم قدر پیغام سوال کو دوبارہ نہیں کھولتا، کیونکہ الگورتھم کی حیثیت اس پر منحصر نہیں کہ کلید کتنی دیر استعمال ہوتی ہے۔

کلید کی تجدید ایک الگ کنٹرول ہے، اور یہ منظوری بحال نہیں کرتی۔

گفت و شنید کو ڈیٹا راستے سے الگ کریں

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

IPsec گیٹ وے پر متعلقہ آؤٹ پٹ سیکیورٹی ایسوسی ایشن ہے؛ OpenVPN پر یہ کنکشن لاگ میں سائفر اور TLS سیٹنگز ہیں۔ دونوں بتاتے ہیں کہ کیا منتخب ہوا۔ کنفیگریشن فائل میں اب بھی موجود پرانے آپشن سے کوئی بھی ثابت نہیں ہوتا۔

اگر آپ طے شدہ نتیجہ نہیں دیکھ سکتے تو آپ یہ دعویٰ نہیں کر سکتے کہ سائفر ریٹائر ہو گیا۔

وہ جزو تلاش کریں جو اب بھی اس کا تقاضا کرتا ہے

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

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

روکنا پیچ نہیں ہے، اور یہ پرانے میزبان کو قابل اعتماد نہیں بناتا۔

ان جانچوں کے ساتھ منتقل ہوں جو آپ کے پاس پہلے سے ہیں

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

openvpn --version
openssl ciphers -v 'DEFAULT:!DES:!3DES'

طے شدہ نتیجے کے ساتھ کلائنٹ اور گیٹ وے کے ورژن درج کریں، تاکہ اگلا جائزہ بتا سکے کہ واقعی کیا بدلا۔

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

تاریخی ڈیٹا ایک الگ مسئلہ ہے

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

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

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