0x یا 0s؟ ipsec.secrets میں PSK کی ساخت سمجھنا

ایک کلائنٹ مشترکہ کلید سے توثیق کرتا ہے اور دوسرا اسے مسترد کر دیتا ہے، حالانکہ آپ کے چسپاں کردہ حروف دونوں طرف ایک جیسے دکھائی دیتے ہیں۔ غالباً وہی حروف ہیں؛ فرق یہ ہے کہ فائل ان پر کون سا ضابطہ ڈی کوڈنگ لاگو کرتی ہے۔ اقتباس میں دیا گیا متن لفظی طور پر لیا جاتا ہے، 0x سے شروع ہونے والا ٹوکن ہیکسا ڈیسیمل کے طور پر پڑھا جاتا ہے، اور 0s سے شروع ہونے والا ٹوکن Base64 کے طور پر پڑھا جاتا ہے۔ ان تین لکھائیوں میں سے صرف ایک آپ کا مطلوبہ معنی رکھتی ہے، اس لیے درستی عام طور پر بہتر پاس ورڈ نہیں بلکہ ایک تبدیلی ہوتی ہے۔

علامت سائفرز کی طرف نہیں، انکوڈنگ کی طرف اشارہ کرتی ہے

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

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

ایک راز، فائل اسے پڑھ سکتی ہے تین طریقوں سے

چار بائٹ کی قدر کے لیے key1 ہیکسا ڈیسیمل اور Base64 ایک ہی بائٹس کی دو دوبارہ انکوڈنگز ہیں، اور صرف ابتدائی حروف ہی تجزیہ کار کو بتاتے ہیں کہ اس کے پاس کون سی ہے۔ swanctl کی اسناد بھی یہی روایت اپناتی ہیں، اس لیے دو انٹرفیس کے درمیان منتقل شدہ قدر اپنا مفہوم صرف اس وقت برقرار رکھتی ہے جب اس کا سابقہ ساتھ جائے۔

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

اس بلاک کی دو تفصیلیں سب سے زیادہ وقت لیتی ہیں۔ ہیکسا ڈیسیمل ہندسے دونوں کیس قبول کرتے ہیں، اس لیے 0x6b657931 اور 0x6B657931 ایک ہی قدر ہیں، لیکن طاق تعداد میں حروف مسترد ہونے کے بجائے خاموشی سے غلط پڑھے جاتے ہیں، جو کٹائی کے بعد ہر بائٹ کو سرکا دیتا ہے۔ Base64 کی بھرتی قدر کا حصہ ہے، اس لیے آخری = نشانوں کے بغیر چسپاں کیا گیا متن بلند آواز میں ناکام ہونے کے بجائے مختلف بائٹس میں ڈی کوڈ ہو جاتا ہے۔

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

Base64 متن کہاں سے آتا ہے

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

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

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

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

تصدیق کریں کہ ہر ساتھی دراصل کون سے بائٹس استعمال کرتا ہے

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

فائل درست ہونے پر دوبارہ شروع کرنے کے بجائے دوبارہ لوڈ کریں۔ ipsec rereadsecrets IKE ڈیمون کی نقل تازہ کرتا ہے، اور swanctl سیٹ اپ اپنی ہی کمانڈ سے اسناد لوڈ کرتا ہے۔ دوبارہ شروع کرنے سے ہر قائم شدہ تعلق گر جاتا ہے اور وہ موازنہ تباہ ہو جاتا ہے جو آپ کرنا چاہ رہے تھے۔

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

نتیجہ چھپائے بغیر فائل تبدیل کریں

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

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