0x أم 0s؟ فكّ ترميز صيغة PSK في ipsec.secrets

عميل واحد يصادق بالمفتاح المشترك وآخر يرفضه، بينما تبدو الأحرف التي لصقتها متطابقة على الطرفين. من المرجح أنها الأحرف نفسها؛ الفرق هو أي قاعدة فك ترميز يطبّقها الملف عليها. السلسلة بين علامتي تنصيص تُؤخذ حرفيًا، والرمز الذي يبدأ بـ 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 يحمّل بيانات الاعتماد عبر أمره الخاص. إعادة التشغيل تُسقط كل ارتباط قائم وتدمّر المقارنة التي كنت تحاول إجراءها.

لا يتطلب أي من هذه الفحوص كشف السر. الطول ومحدّد الهوية وموضع الصف تفسّر معظم حالات الفشل من هذا النوع قبل أن يحتاج أحد إلى تفريغ ست عشري.

غيّر الملف دون إخفاء النتيجة

اقصر الملف على حساب البرنامج الخفي، وأبعد الأسرار الحيّة عن التذاكر والدردشة ولقطات الشاشة، لأن مفتاحًا ملصوقًا تسريب لا تشخيص. كما أنه يعيش أطول من الحادث الذي أنتجه.

اختبر من عميل تتحكم في إعداداته، وتأكد من نجاح المصادقة، ثم تأكد من أن النفق ينقل حركة المرور. إعادة التحميل التي تصلح المصافحة بينما يبقى التوجيه معطلًا مشكلة أخرى، وتصبح مرئية بمجرد أن يتوقف السر عن الحركة.