الخلاصة

  • يعرّف RFC 9934 ملف PEM يضم صفراً أو مفتاحاً خاصاً واحداً بصيغة PKCS #8، ثم ECHConfigList واحدة؛ وإذا وُجد السر وجب أن يطابق إعداداً عاماً واحداً على الأقل في القائمة.
  • هذا التطابق دليل على علاقة داخل الملف، لا على المفتاح النشط في ذاكرة الخادم أو القيمة المنشورة في DNS أو عمر ذاكرة العميل أو قبول ECH أو نتيجة الخصوصية.

ليس السؤال الأصعب في تدوير ECH: «هل أنشأنا مفتاحاً جديداً؟» بل: «أي جيل كان حقيقياً عند كل شاهد؟» قد يرى مدير المفاتيح الجيل الجديد، ويظل الخادم على السابق لأن إعادة التحميل لم تقع. وقد ينشر الخادم القادر إعلاناً جديداً بينما يحمل محلل DNS أو عميل بعيد قيمة قديمة لم ينتهِ TTL الخاص بها. كلمة «الحالي» هنا ليست حقيقة واحدة؛ إنها علاقة بين مكان وزمن.

يمنح RFC 9934 هذه العلاقة نقطة ارتكاز عملية. فهو يضع صيغة مشتركة تمكّن مديري المفاتيح وخوادم مبنية على مكتبات TLS مختلفة من تبادل مادة ECH من دون اختراع حاوية خاصة بكل منتج. يحتوي الملف على صفر أو مفتاح خاص واحد، تتبعه ECHConfigList واحدة. وإذا حضر المفتاح جاء أولاً بترميز PKCS #8 PrivateKey وبين حدّي PRIVATE KEY. وتأتي القائمة العامة بعده بحدّي ECHCONFIG، ويحمل نصها base64 للقيمة الثنائية نفسها القابلة للنشر في سجل HTTPS.

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

يسمح المستند أيضاً بملف لا يحتوي مفتاحاً خاصاً. ليست هذه حالة ناقصة، بل تعبير عن حد نشر مهم. ما يُعرض للجمهور هو ECHConfigList، أما المفتاح الخاص في ملف يحمله فلا يجوز نشره في DNS. لذلك تحتاج الأتمتة إلى مخرجين مرتبطين بالجيل نفسه ومختلفين في السلطة: إسقاط سري يصل إلى الخادم فقط، وإسقاط عام يصل إلى HTTPS/SVCB. جمعهما في حزمة قابلة للنشر يهدد بكشف السر؛ وفصلهما بلا معرف أو تجزئة مشتركة يمنع إثبات اتساقهما.

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

يشرح RFC 7468 انضباط الحدود النصية والتسميات الذي استند إليه الشكل، ويحدد RFC 4648 أساس ترميز base64. لكن نجاح parser في إعادة البايتات لا يحدد أصحاب القدرة الفعلية على قراءتها. صلاحيات النظام، ونسخ backup، ولقطات التخزين، ووكلاء النشر، ومسارات دعم الطوارئ كلها أسطح حيازة عملية، حتى إن ظهر مالك واحد في وصف الملف.

تأتي مشكلة الزمن بوضوح في RFC 9849. ينبغي للخادم المواجه للعملاء أن يحتفظ بالإعدادات المنشورة حالياً وبقيم سابقة قد تظل لدى العملاء طوال TTL أو أكثر. إذا استطاع فك ClientHello الداخلي أمكن قبول ECH ومتابعة المصافحة الداخلية. وإذا لم يستطع، عالج ClientHello الخارجي ورفض ECH وقدّم إعدادات حديثة لإعادة المحاولة. العميل هو الذي يؤكد القبول؛ والاتصال الذي رُفضت فيه ECH لا يصبح مساراً جاهزاً لبيانات التطبيق بمجرد وصول رد.

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

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

حتى اكتمال هذا الوصل لا يسمح بوصف DNS بأنه إيصال خصوصية شامل. يوضح RFC 9848 أن مجموعة سجلات تمزج نقاط نهاية تدعم ECH وأخرى لا تدعمها قابلة للتخفيض بالحجب الانتقائي. وقد يظل DNS النصي وعنوان IP وأنماط المرور وصغر مجموعة إخفاء الهوية كاشفاً. ويوحّد RFC 9460 سطح Service Binding، لكنه لا يشاهد السر في ذاكرة الخادم ولا قرار المصافحة عند العميل.

وفق Running-Code Primacy عند Heng Lu، لكل شاهد سلطة بحجم ما نفّذه. المدقق يثبت بايتات الملف وعلاقته الداخلية. والخادم يثبت مجموعة المفاتيح التي حمّلها. والسلطة والمحلل يثبت كل منهما عرض DNS الذي رآه. والعميل يثبت عرضه ونتيجة ECH. والتطبيق يثبت الأثر اللاحق. الوضوح لا ينتقص من أي شاهد؛ بل يمنع نظاماً واحداً من الاستيلاء على حقيقة الأنظمة الأخرى.

كما يفسر مبدأ Minimum Initial Specification سبب صغر RFC 9934. صيغة تسليم مشتركة تكفي لتحقيق قابلية التشغيل البيني، ولا يلزمها فرض مدير مفاتيح أو TTL أو طريقة reload أو سياسة خصوصية عالمية. القرارات المحلية تبقى لدى من يستطيع ملاحظة آثارها وعكسها. لكن الاستقلال المحلي لا يعفي صاحبه من تقديم دليل قابل للربط.

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

المصادر