الخلاصة

  • جعل RFC 3329 وكيل المستخدم وأول قفزة في SIP يتبادلان القوائم ويشغّلان الآلية المشتركة الأعلى في تفضيل الخادم، ثم يعيدان قائمته الثابتة كاملة في Security-Verify عبر الحماية المختارة.
  • كشف التطابق حذف الخيارات، لكنه لم يضمن أقوى أمان حديث أو السرية؛ فقد اعتمد حده الأدنى على سلامة ومنع إعادة التشغيل في أضعف آلية ما زالت مسموحة.

بدأ اختيار الحماية قبل وجودها

لا تستطيع شبكة كبيرة تحديث كل جهاز في وقت واحد. قد يعرف جهاز قديم HTTP Digest، فيما يعرف الجديد TLS أو IPsec أيضا. التهيئة المسبقة لكل زوج تعرقل الانتقال، وتجربة الآليات واحدة بعد أخرى تتيح للمهاجم تزوير فشل يجعل الآلية القوية تبدو غير متاحة.

تبدو المفاوضة حلا مباشرا: يعلن العميل قدراته، ويرتب الخادم خياراته، ويختاران أفضل تقاطع. لكن الطلب والاستجابة الأوليين يعبران قبل تشغيل الاختيار. يستطيع مهاجم على المسار حذف TLS وترك Digest، فتستمر المحادثة ويعتقد كل طرف أن الآخر لم يعرض التشفير أصلا.

فصل RFC 3329 العرض عن الإثبات. أرسل العميل Security-Client إلى كيان SIP التالي. ورد الخادم بقائمة Security-Server ثابتة ومرتبة بالتفضيل، ومعها معلومات بدء الآليات. اختار العميل الآلية المشتركة المعروفة ذات أعلى تفضيل، وشغّلها، ثم أرسل طلبا جديدا يحوي Security-Verify، وهي نسخة من قائمة الخادم المستلمة. قارن الخادم الإيصال بسياسته.

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

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

منعت القائمة الثابتة خفضا متسقا

لم يجز للخادم تكوين قائمته من Security-Client. لو حذف ما لم يعلنه العميل، لاستطاع المهاجم تقليص قائمة العميل أولا، ودفع الخادم إلى عرض مقصوص مطابق، ثم إعادة إيصال صحيح ظاهريا. وجب أن تكون قائمة الخادم مستقلة وثابتة في نطاق السياسة. أمكن وجود قائمة لكل واجهة، لكن كل واحدة سبقت الطلب.

سمح ذلك بالمقارنة من دون حالة SIP جديدة. لم يحتفظ الخادم بتحد خاص بكل عميل؛ بل قارن Security-Verify بالإعداد عند عودته. قد تحتفظ وصلة TLS أو رابطة IPsec بحالة تخصها، أما إثبات القائمة فلم يحتج جلسة إضافية.

وجب اختلاف قيم q. اختار العميل الآلية التي يعرفها وتحمل أعلى تفضيل لدى الخادم. ظل تعديل القائمة الأولى للعميل قادرا على إزالة معلومات البدء أو دفع الطرفين إلى اختيارين مختلفين. كان الفشل إشارة إلى هجوم محتمل، لكنه قد ينتج أيضا من إعداد قديم أو خلل توافق.

اقتصرت الحدود على وكيل المستخدم والكيان التالي، وهو غالبا الوكيل الأول أو الصادر. عند بدء الخادم، فحص أن الطلب يحوي Via واحدة؛ وجود أكثر من واحدة يعني أنه ليس القفزة الأولى. لذلك لم تكن المفاوضة حماية شاملة من طرف إلى طرف ولا غطاء تلقائيا لكل وكيل أو محتوى.

عبّر 421 و494 عن مرحلتين لا عن اتهامين

في البدء من العميل، حمل الطلب المكشوف Security-Client وsec-agree في Require وProxy-Require. أعاد الخادم 494 Security Agreement Required وقائمته كاملة حتى إن لم توجد آلية مشتركة.

وقد تفرض سياسة الخادم الإجراء. العميل الذي لا يعلن الدعم يتلقى 421 Extension Required. وإذا أعلن sec-agree ولم يكمل الاتفاق بعد، يتلقى 494. حملت الاستجابتان قدرات الخادم وبيانات بدء الآلية المفضلة.

لم يثبت الرمزان وقوع هجوم. قد يعني 421 جهازا قديما أو وسم دعم مفقودا. وقد يكون 494 الخطوة الأولى الطبيعية أو نتيجة اختلاف أو استئناف بعد انتهاء رابطة. احتاج السجل المفيد إلى القوائم والرمز ومواد البدء والاختيار ونتيجة الحماية والمقارنة.

اختلف بدء الآليات. أنشأ TLS وصلة محمية وفق قواعد اكتشاف خادم SIP. أدرج Digest قائمة الخادم في حساب التحقق. حاول IPsec-IKE إنشاء IKE، واعتمد IPsec اليدوي على مفاتيح وسياسة خارجية. أضاف RFC 3310 سياق AKA إلى Digest، ولم يلغ إعادة القائمة.

اختلف العمر أيضا. أغلق انتهاء TLS الرابطة، وفاوض IKE على عمره، وأعاد Digest التحدي عند فساد الاعتماد، واتبع IPsec اليدوي قواعد خارجية. لم يكف تسجيل «نجح الاتفاق» من دون معرّف الرابطة وشرط نهايتها.

حدّدت أضعف قابلية توافق أرضية الأمان

اشترط قسم الأمان أن تقدم أضعف آلية معروضة سلامة ومنع إعادة التشغيل لقائمة Security-Verify. إذا استطاع المهاجم كسرها، فلا ينبغي عرضها. جعلت المفاوضة الخفض أصعب، لكنها لم تصلح خوارزمية مكسورة.

لم يعن النجاح السرية. قد يصادق Digest من دون تشفير محتوى SIP. حمى TLS قفزة واحدة. واعتمد IPsec على الرابطة الفعلية. أثبت تطابق القائمة استمرارية محدودة بين السياسة والإيصال، لا تشغيل كل الخيارات ولا السرية من طرف إلى طرف.

نشر RFC 3329 في يناير 2003. حدّثه RFC 8996 بمنع TLS 1.0 وTLS 1.1. ويعرّف RFC 8446 TLS 1.3، بينما يحدّث RFC 7616 Digest. بقي تصميم الإيصال، لكن اسم tls لا يقر كل نسخة تاريخية.

توضح التصحيحات فرقا آخر. يضع مثالان Security-Verify في ACK رغم أن جدول الاستخدام المعياري يجعله غير قابل للتطبيق، والتصحيح محفوظ لتحديث الوثيقة. ويصحح خطأ موثق طول SPI في ipsec-3gpp. يسجل IANA الأسماء والمراجع، ولا يثبت النشر أو الأمان الحالي.

ترك RFC 3329 نمطا عاما للتحقق المؤجل. عندما تأتي القدرة على الحماية بعد العرض، يُحفظ العرض حتى تبدأ الحماية ثم يعاد ويقارن بدقة. الإيصال السليم يثبت الاستمرارية في حد معروف؛ ولا يثبت أن سياسة التوافق قوية بما يكفي.

المصادر