الخلاصة

  • أخفت خدمة الخصوصية الهوية عن المستلم لأنها كانت تعرف الأصل أو تتحكم في طريق العودة؛ فلم تكن مجهولة بالنسبة إلى كل الأطراف.
  • كان critical يطلب رفض الرسالة إذا تعذر تنفيذ الحماية، لأن الإرسال المكشوف لا يمكن التراجع عنه.

الطريق إلى نقطة الإخفاء

يمكن للعميل كتابة Anonymous واستعمال نطاق SIP المجهول المحجوز وحذف الحقول الاختيارية. لكن Contact وVia وSDP قد تحمل عناوين لازمة لاستمرار الحوار. تزويرها يكسر التوجيه. لذلك احتاجت الخصوصية إلى وسيط يعيد الكتابة ويتولى إعادة الرسائل.

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

قيم header وsession وuser كانت طلبات لا إثبات تنفيذ. وقد تمنع قيود قانونية أو ميزة ناقصة أو خطأ إعداد تحقيقها. أضاف critical سلوك الفشل المغلق، بينما منع none خدمة افتراضية من فرض إخفاء لم يرده المستخدم.

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

احتفظ الوكلاء والمستلمون بحق رفض المصدر غير المعروف. الخصوصية لا تفرض القبول. RFC 3325 ووثائق الهوية والتاريخ اللاحقة وسعت طبقات الإثبات، لكنها لم تلغِ سؤال: مجهول بالنسبة إلى من؟

مسار الاستجابة يُبنى مسبقاً

تعود استجابة SIP في الطريق الذي عبره الطلب. لذلك لا يستطيع الطرف المستقبل، بعد وصول الطلب، إدخال خدمة خصوصية جديدة في مسار الاستجابة. إذا أراد إخفاء Contact أو موضع التسجيل، فعليه إعداد الطريق قبل ذلك: عنوان رجوع مجهول، أو REGISTER عبر الخدمة، أو اتصال TLS مستمر.

هذا يجعل الخصوصية قرار توجيه لا زينة تُضاف في النهاية. رؤية رسالة نهائية منزوعة الهوية لا تثبت أن النسخة الأصلية لم تمر بوسيط آخر، ولا أن الاستجابة حظيت بالحماية نفسها. يجب حفظ تسلسل العقد لا النتيجة المرئية وحدها.

الرأس والجلسة سطحان مختلفان

إخفاء From وVia وOrganization لا يخفي بالضرورة عنوان SDP أو مصدر حزم الوسائط. وبالعكس، relay يخفي عنوان الشبكة عن النظير لكنه لا يزيل User-Agent أو Call-ID أو علامات أخرى في SIP. لهذا فصلت RFC 3323 بين header وsession.

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

الخدمة تجمع ما توزعه من حماية

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

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

تبقى مسألة الاحتفاظ بالسجلات منفصلة عن شكل الرسالة الخارجية. قد تنجح الخدمة في إزالة العنوان قبل المستلم، ثم تحتفظ في الداخل بربط كامل بين الهوية والوقت والوجهة. لا تثبت RFC 3323 مدة الاحتفاظ أو من يستطيع الوصول إلى تلك البيانات. لذلك يجب على المشغل أن يعلن سياسة السجل، ويفصل الحاجة إلى المحاسبة عن الادعاء بأن المستخدم «مجهول»، ويختبر حذف الربط عندما تنتهي الحاجة التشغيلية.

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

وهذا هو الفرق بين وعدٍ ظاهر ودليلٍ تشغيلي يمكن مراجعته لاحقاً.

Sources