الخلاصة

  • يوزع RFC 9458 معرفة الطلب بين مرحّل وبوابة: يرى المرحّل الأصل الشبكي للعميل ولا يرى النص الصريح، وترى البوابة النص الصريح ولا ترى أصل العميل. ولا يجوز أن يكون الدوران كياناً واحداً إذا أريد تحقيق هدف الخصوصية المعلن.
  • لا يكفي التشفير لحماية هذا الفصل. فقد يعيد ملف تعريف ارتباط أو معرّف حساب أو إعداد مفتاح خاص بجهاز واحد أو سياق HPKE معاد الاستخدام أو مستودع سجلات مشترك أو نمط توقيت وحجم نادر بناء الصلة بين الشخص والرسالة.
  • أسهم Christopher A. Wood، مع المؤلف المشارك Martin Thomson، في تحديد فصل للمعرفة يمكن اختباره، لا شهادة شاملة بإخفاء الهوية. وعلى النشر الفعلي أن يثبت استقلال التشغيل وتقليل الحالة وسلامة الإعادة ودورة حياة المفاتيح وحجم مجموعة المجهولية.

التحليل: خصوصية قائمة على نقص مقصود في المعرفة

يعطي اتصال HTTPS المعتاد الخدمةَ قدرة مزدوجة في كثير من الأحيان: فهي تستقبل عنوان الشبكة الذي جاء منه الاتصال، ثم تفك حماية المحتوى كي تعالجه. يحمي التشفير الطريق من أطراف أخرى، لكنه لا يمنع الخدمة نفسها من وصل «من» بـ«ماذا».

يغير OHTTP توزيع هذه القدرة. يحول العميل الطلب إلى رسالة HTTP ثنائية، ثم يغلفها بواسطة HPKE وفق إعداد مفتاح للبوابة. يرسل الغلاف عبر HTTPS إلى مرحّل. يرى المرحّل اتصال العميل والبوابة المقصودة، لكنه لا يملك ما يفتح به الرسالة. ثم ينشئ وصلة HTTPS أخرى إلى البوابة. تفك البوابة الغلاف، وترسل الطلب إلى المورد الهدف، وتغلف الرد ليعود عبر المرحّل. وما تراه البوابة في طبقة الشبكة هو المرحّل، لا العميل الأصلي.

إذن يحمل المرحّل معلومة المصدر من دون المعنى، وتحمل البوابة المعنى من دون المصدر. وينص RFC 9458 بوضوح على أن المرحّل والبوابة لا يمكن أن يكونا الكيان نفسه لتحقيق أهداف الخصوصية الواردة فيه.

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

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

Christopher A. Wood داخل التأليف المشترك وحدود البرهان

نشر IETF وثيقة RFC 9458 في يناير 2024 ضمن المسار المعياري، وتحمل اسمي Martin Thomson وChristopher A. Wood بوصفهما مؤلفين. وتصف صفحة Datatracker المحفوظة في 1 سبتمبر 2026 Wood بأنه مهندس لدى Apple يعمل في الهندسة التشفيرية، وتسرد 24 وثيقة RFC مرتبطة به، منها RFC 9458. هذه معلومات مؤرخة بلحظة الالتقاط وقد تتغير، ولا تثبت اختراعاً فردياً أو سلطة على أي نشر خارجي.

شارك Wood أيضاً Jonathan Hoyland في مقال Cloudflare عام 2022 عن تحليل بمساعدة الحاسوب. مثّل نموذج Tamarin خصماً يستطيع مراقبة الشبكة واختراق المرحّل أو البوابة على نحو تكيفي، لكنه افترض عدم تواطؤ الدورين وعدم إرسال بيانات تعرّف العميل إلى البوابة.

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

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

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

البوابة ليست المورد الهدف

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

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

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

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

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

حين يحمل النص الصريح اسماً بديلاً

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

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

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

وعلى المرحّل ألا يضيف Via أو Forwarded يكشفان العميل. إن تلقي المعرّف ثم الوعد بحذفه أصعب إثباتاً من عدم جمعه أصلاً.

الوثيقة المطلوبة هنا جرد للحقول: هل تبقى القيمة ثابتة بين الطلبات؟ هل يمكن وصلها بمجموعة بيانات أخرى؟ من أجازها؟ وما الوظيفة التي تضيع بحذفها؟ صفة «بلا حالة» ليست وصفاً تسويقياً، بل نتيجة اختبار للبايتات الفعلية.

حداثة التشفير لا تضمن حدوث الفعل مرة واحدة

يعرف RFC 9180 تقنية HPKE التي تجمع تغليف المفتاح والاشتقاق والتشفير الموثق لإنشاء سياق حماية. ويطلب RFC 9458 سياقاً جديداً لكل طلب. إعادة الاستخدام قد تربط الطلبات، وقد تكشف في ظروف معينة محتوى للمرحّل.

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

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

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

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

HTTPS لا يخفي هيئة الحركة

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

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

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

لذلك يؤكد معدل نجاح HPKE سلامة المعالجة التشفيرية ولا يؤكد صحة المجهولية. نحتاج مقاييس لتفرد الحجم، والارتباط الزمني، ونسبة الحشو، وتركيز المسارات.

سجل إثبات لفصل المعرفة

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

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

يجب اختبار الاختراقات منفصلة. اختراق المرحّل يكشف الأصول والتوقيت؛ اختراق البوابة يكشف النصوص والمفاتيح؛ اختراق منصة سجلات مشتركة قد يكشف الصلة الكاملة. عبارة «اختراق OHTTP» لا تكفي لتحديد المعرفة التي حصل عليها الخصم.

تساعد أولوية الشيفرة العاملة عند Heng Lu على ضبط حجم الادعاء: الوظيفة التنفيذية تفصل الرؤية، لكنها لا تصادق الاستقلال المؤسسي. كما توضح فكرة المواصفة الأولية الدنيا قيمة نواة مشتركة صغيرة، بشرط ألا تهدم الجهات المحلية الفرضية الدنيا التي تمنحها معناها.

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

لا يحتاج توصيف Christopher A. Wood إلى القول إنه جعل HTTP مجهولاً في كل مكان. الأدق أنه، مع Thomson، ساعد على تحويل فصل المعرفة إلى آلية قابلة للاختبار. وأفضل تقرير نشر لا يقول «نستخدم OHTTP» فقط؛ بل يبين لماذا لا يستطيع أي مشغّل منفرد الإجابة عن السؤالين معاً: من أرسل، وماذا أرسل؟

المصادر