قد يكون ملف ECH صالحاً لحدود خصوصية خاطئة

Summary

يستطيع فحص RFC 9934 إثبات أن المفتاح الخاص في ملف PEM يطابق إعداد ECHConfig واحدا على الأقل في القائمة العلنية. لكنه لا يثبت أن الملف معتمد لمالك DNS المقصود، أو لمجموعة الخوادم المتاحة، أو لقائمة إعادة المحاولة، أو لمجموعة إخفاء الهوية، أو للمرحلة الحالية من دورة الحياة.
لا ينقص التشغيل نسخة أخرى من المفتاح، بل إيصال سياسة ونشر يحافظ على الخصوصية. ينبغي أن يصل ملخص الإعداد بسجل RRSet المأذون، ومجموعة نقاط النهاية، وأدوار التشغيل العادي وإعادة المحاولة، وفترة التداخل، وشروط الرجوع، والجهات المسؤولة، من دون كشف المفتاح الخاص أو قائمة الأسماء المحمية.

ما الذي تثبته الإشارة الخضراء فعلا

يستطيع فاحص الملف أن يقدم جوابا واضحا ومريحا. حدود PEM صحيحة، والمفتاح الخاص بنية PKCS #8 سليمة، ويمكن فك ECHConfigList، ويوجد في القائمة إعداد علني واحد على الأقل يطابق المفتاح الخاص. لا تلف في الملف، والعلاقة التشفيرية قائمة، فتظهر إشارة النجاح.

لهذا النجاح قيمة تشغيلية حقيقية. من دون صيغة مشتركة قد تبتكر مكتبات TLS وخزائن الأسرار والخوادم حاويات غير متوافقة لنقل مادة ECH. عندئذ تعتمد عملية التدوير أو الانتقال بين المنتجات على تحويلات خاصة بكل مورد. يقرر RFC 9934 أن ملف ECH بصيغة PEM يحتوي صفرا أو مفتاحا خاصا واحدا، مع ECHConfigList مرمزة. وإذا وجد المفتاح وجب أن تضم القائمة ECHConfig تطابقه. كما يخصص الوسم ECHCONFIG للجزء العلني، ويمنع نشر الجزء الخاص في DNS.

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

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

لذلك لا يكفي أن يسأل المشغل: «هل الملف صالح؟». عليه أن يسأل أيضا: «صالح لأي حالة نشر معتمدة؟».

قائمة واحدة تحمل قرارات متعددة

يسمح RFC 9934 عمدا بأن تحتوي ECHConfigList على عدة قيم ECHConfig مرتبة بحسب الأفضلية. قد تختلف القيم في الامتدادات أو في public_name. ويمكن لخادم TLS أن يضبط عدة أسماء ملفات، ثم يختار مجموعة فرعية فقط لتكوين retry_configs التي يعيدها عند رفض ECH.

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

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

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

تعمل ECH عبر المسار كله لا داخل الحاوية

يصف RFC 9849 بروتوكول ECH، ويصف RFC 9848 اكتشافه عبر DNS. في الاتصال الفعلي يقرأ العميل إشارة HTTPS أو SVCB، ويبني ClientHello خارجيا وآخر داخليا، ويصل إلى خادم اختارته موازنة الحمل، وينتظر أن يجد الخادم المفتاح الصحيح. وعند الرفض قد يتلقى إعدادات جديدة ثم ينشئ اتصالا آخر.

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

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

في البنى متعددة السحب أو مزودي CDN قد ينقل تغيير alias أو TargetName الحركة إلى مؤسسة أخرى. هل يسمح لها بحيازة المفتاح نفسه والانضمام إلى مجموعة الخصوصية ذاتها؟ هذا قرار تعاقدي وخدمي. قابلية تسليم الملف لا تمنح تفويضا بتوسيع الحدود.

نشر DNS سلطة مستقلة

يكتشف العملاء القائمة العلنية عادة في المعامل ech لسجلات HTTPS أو SVCB. يوفر RFC 9460 إطار Service Binding، ويحافظ سجل IANA على المعاملات ذات الصلة. ما ينشر في DNS هو ECHConfigList العلنية، وليس المفتاح الخاص الموجود في الملف. يجب أن يتسق المحتويان، لكن الاتساق لا يثبت سلطة النشر.

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

كما أن public_name ليس تعليقا للقراءة البشرية. فهو يدخل في السياق المرئي للاتصال الخارجي وفي السلوك عند عدم قبول ECH. قواعد هوية الخدمة في RFC 9525 وأساس TLS في RFC 8446 يوضحان الفصل: قدرة خادم على فك التشفير لا تعني أنه مخول بتمثيل كل خدمة تستخدم الاسم الخارجي.

ينبغي لإيصال النشر أن يسجل الملخص المعياري لـRRSet المعتمد، والمنطقة أو مسار التفويض، وTargetName ومجموعة العناوين المتوقعة، وأولوية SVCB أو HTTPS، وافتراضات الذاكرة الوسيطة، ونافذة النشر. لا يحل الإيصال محل DNSSEC أو فحص الشهادة أو موافقة التغيير، بل يبين أن القرارات المستقلة تشير إلى الحالة نفسها.

تغطية الخوادم خاصية لمجموعة

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

لهذا يجب أن تصف عبارة «تم تثبيت الملف» مجموعة خوادم لا عقدة مفضلة. تشمل المجموعة عناوين IPv4 وIPv6، ومواقع التعافي، والمزودين البدلاء، والسعة قليلة الاستخدام، والتوسعات المؤقتة، والتجمعات التي تستعيد وزنها بعد حادث. أثناء التحديث التدريجي قد تكون الملفات كلها صالحة منفردة، فيما يعيش DNS والخوادم في أجيال غير متوافقة.

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

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

مجموعة إخفاء الهوية ليست خاصية في PEM

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

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

لذلك لا توجد قاعدة آلية تقول إن الجمع جيد دائما أو الفصل آمن دائما. على صاحب الخدمة ومسؤول الخصوصية ومشغل المنصة اختيار حدود يمكن تفسيرها. قابلية المفتاح للعمل لا تعتمد هذا الاختيار نيابة عنهم.

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

إعادة المحاولة قناة سياسة مستقلة

يستطيع الخادم عند رفض ECH أن يعيد retry_configs. ويلاحظ RFC 9934 أنه حتى عند ضبط عدة ملفات يمكن اختيار مجموعة فرعية فقط لهذا الرد. إذن مجموعة الإعدادات المقبولة في الوضع العادي ومجموعة الإعدادات المعلنة للاسترداد تؤديان وظيفتين مختلفتين.

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

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

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

يتغير معنى الإعداد نفسه مع الزمن

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

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

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

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

قابلية النقل تنقل المسؤولية أيضا

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

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

ليس الحل تحميل البروتوكول كل القواعد التنظيمية. المطلوب طبقة منفصلة وقابلة للتحقق للحقائق المؤسسية. تدفع فكرة Policy Mirror عند Heng Lu إلى السؤال عما إذا كانت إشارة الحالة المرئية تعكس القرار الحقيقي. وتقترح فكرة الحد الأدنى من المواصفة الأولية البدء بإيصال صغير ومحلي وقابل للتطوير، لا إنشاء سلطة مركزية شاملة منذ البداية.

الوصف الملتزم بالواقع يعرض الاستثناءات. لا يجوز أن تختفي عمليات النشر الجزئي والرجوع الطارئ ونقص الأدلة خلف أيقونة خضراء. حالة «الملف صالح، والحدود لم تثبت بعد» نتيجة صادقة وقابلة للعمل.

البنية الدنيا لإيصال يحفظ الخصوصية

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

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

تفصل الكتلة الرابعة القبول وإعادة المحاولة والتداخل والرجوع والتقاعد. وتسجل الخامسة حدود الخصوصية بإصدار السياسة ونطاق الحجم وفئة العزل من دون تعداد الأسماء. أما السادسة فتسمي المسؤولية: المقترح، ومعتمد DNS، وأمين المفتاح، وصاحب الخدمة، ووقت التوقيع، وشروط الإلغاء، ومراجع الأدلة.

ينبغي أن يكون الإيصال قابلا للتوقيع وإعادة الإنتاج من مدخلات معيارية والإلغاء الموثق. يمكنه الإشارة إلى أدلة محفوظة في أنظمة مقيدة، لكنه لا يحتوي المفتاح أو قائمة الأسماء أو عناوين العملاء أو نسخ المصافحة. يبقى HPKE في RFC 9180، وبروتوكول ECH، واكتشاف DNS مصادر تعريف العناصر التقنية؛ الإيصال يوثق قرار استخدامها في الواقع ولا يعيد تعريفها.

على الأتمتة أن تظهر حد الضمان

يجب أن يبدأ خط النشر بفحص RFC 9934. الصيغة الفاسدة، أو المفتاح غير المطابق، أو القائمة التي لا تفك، توقف العملية. وبعد النجاح يطلب مرجع السياسة ودليل البيئة.

من دون ملخص RRSet معتمد تكون الحالة «ملف صالح، نشر غير مأذون». وعند نقص مجموعة النهاية تكون «ملف صالح، تغطية غير مكتملة». وعند عدم مراجعة تغير المجموعة تكون «تطابق تشفيري، حدود معلقة». لا تقلل هذه الحالات من شأن المعيار؛ بل تمنع بيع ضمانه المحدد بوصفه ضمانا أوسع.

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

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

لا تجعل التدقيق نقطة مراقبة جديدة

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

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

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

موافقتان لقضيتين مختلفتين

مهمة RFC 9934 تعريف صيغة ملف قابلة للتشغيل البيني، لا اختيار حدود المستأجرين أو سلسلة الموافقات أو مدة التدوير لكل مشغل. ليست المشكلة فصلا ناقصا في RFC، بل عادة تشغيلية تفسر فحص الصيغة على أنه موافقة شاملة.

قد يوحد بيان ECH موقع مستقبلا بعض الحقول. وحتى ذلك الوقت يؤدي إيصال محلي الوظيفة إذا كان قابلا للتحقق، وفصل ضمان البروتوكول عن القرار المؤسسي، وسجل عدم اليقين بصدق.

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

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

صلاحية ملف مفاتيح ECH لا تثبت صحة حدود الخصوصية

لماذا هذا مهم