الخلاصة

  • تعرّف RFC 9540 المعامل الفارغ ohttp في سجلات SVCB أو HTTPS، والمسار /.well-known/ohttp-gateway على المضيف نفسه، وطريقة جلب إعداد مفاتيح البوابة.
  • لا تكتشف الآلية المرحّل ولا تزكيه؛ فإعلان DNS وهوية الطرف والمفتاح القابل للاستخدام واكتمال الطلب إيصالات مستقلة.
  • يمكن لمفتاح أو تحويل أو dohpath لا يراه إلا عميل واحد أن يعيد تمييزه رغم صحة التشفير، ولذلك يحتاج الاتساق إلى دليل مستقل.

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

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

تكمن أهمية RFC 9540، المنشورة في فبراير 2024، في أنها لا تخفي هذا التعارض. فهي توحّد اكتشاف خدمات Oblivious HTTP بواسطة سجلات Service Binding، وتحدد طريقاً إلى البوابة ومفاتيحها، ثم تصف كيف يمكن للطريق نفسه أن يصبح سطحاً للاستهداف. لذلك لا يجوز للإدارة اختزال «تم اكتشاف OHTTP» و«تحققت خاصية الخصوصية» في حالة واحدة.

قيمة فارغة تحمل قراراً كبيراً

يجب أن تكون قيمة SvcParamKey المسماة ohttp فارغة في التمثيل النصي وعلى السلك. وجودها يعني أن الخدمة الموصوفة تستطيع العمل كهدف OHTTP بواسطة بوابة مرتبطة بها.

ومع ذلك يغير هذا الوجود قواعد الاختيار. إذا أُدرج ohttp ضمن mandatory فعلى العميل الذي لا يفهمه تجاهل السجل. وإذا لم يكن إلزامياً فهو يعلن خياراً إضافياً. ويمكن نشر عدة سجلات بتكوينات مختلفة.

الإيصال الناتج محدود: سلطة DNS معينة أعلنت قدرة معينة في وقت معين وبـ TTL وقواعد اختيار محددة. لا يثبت ذلك أن العميل استخدم OHTTP، ولا أن البوابة متاحة، ولا أن عملاء آخرين شاهدوا المادة نفسها. وفي DNS الواضح غير المحمي بـ DNSSEC يستطيع طرف على المسار حذف معلومات SVCB وإحداث خفض. قد يخفف فحص المسار المعروف أو الجمع بين DNS المشفر وDNSSEC هذا الخطر، لكنه لا يشهد على سلوك البوابة لاحقاً.

ينبغي أن يحتفظ سجل الأدلة بالإجابة الخام والمحلل ونقطة الرصد وTTL وعمر الذاكرة المؤقتة وحالة DNSSEC والنقل وقائمة mandatory والمرشحين وسبب الاختيار. تحويلها كلها إلى خانة ohttp=true يمحو صاحب القول وأثره في القرار.

الاكتشاف لا يصل إلى المرحّل

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

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

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

يجب عبور العنوان المعروف مرتين وباستقلال

بعد رؤية ohttp يستخدم العميل /.well-known/ohttp-gateway على المضيف نفسه الذي يستضيف الهدف. ويمكن للخادم إعادة توجيه هذا المورد. غير أن العميل لا يجوز أن يسلّم المرحّل URI التحويل الذي شاهده عند جلب المفاتيح.

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

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

كشف الهوية قد يسبق أول طلب محمي

قبل التغليف، يرسل العميل GET إلى البوابة مع Accept: application/ohttp-keys. إذا جلب الإعداد مباشرة رأت البوابة عنوان IP. قد يكون ذلك مقبولاً إذا كان الوعد يقتصر على فصل الاستعلامات المفردة عن مشترك معروف أصلاً، لكنه يناقض وعد إخفاء الموقع وقد يسمح باختيار مفتاح خاص بالعنوان.

يمكن لوكيل أن يحجب IP، لكنه يضيف مراقباً جديداً. والأهم أن صحة الإعداد لا تعني شيوعه. تستطيع البوابة إعطاء العميل «أ» مفتاحاً صالحاً مختلفاً وإعطاء الجميع مفتاحاً آخر. ولأن طلبات OHTTP قد تُربط بواسطة الإعداد المستخدم، تنشأ هوية منفردة من دون كسر الخوارزمية.

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

يمكن أن يتحول dohpath إلى اسم

في DoH المحجوب توجد مساحة استهداف إضافية. يستطيع المحلل إعطاء كل عميل dohpath مختلفاً، فيبقى المحتوى مشفراً والمفتاح مشتركاً بينما يعمل المسار كمعرّف.

يمكن للعميل قبول قيمة معروفة واحدة مثل /dns-query{?dns}، أو مقارنة القيم الحرة بمصدر مستقل. وتسمح RFC بأخذ عينات وفق القدرة ونموذج التهديد، لكن دليل العينة لا يبرر حكماً شاملاً على الأحداث غير المفحوصة.

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

تسعة إيصالات قبل حكم الخصوصية

يفصل النشر القابل للحكم بين: إعلان ohttp؛ فهم كونه إلزامياً؛ قبول سلطة DDR أو DNR؛ التحقق من هوية الطرف؛ استلام إعداد مفتاح قابل للتحليل؛ اتساق المفتاح والمسار والتحويل؛ صلاحية المرحّل وقدرته على الوصول؛ اكتمال المعاملة؛ ثم خاصية الخصوصية التي تسندها الأدلة فعلاً.

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

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

المصادر