الخلاصة

  • تحوّل DNS Cookies رحلة أولى ذهاباً وإياباً إلى دليل محدود على قابلية الوصول؛ فالطلب اللاحق الذي يحمل الرمزين الصحيحين يصعب على مهاجم خارج المسار تزويره.
  • عرّف RFC 7873 التبادل، ثم حدّد RFC 9018 بنية موحّدة لـ Server Cookie بالإصدار 1 كي تتحقق عقد anycast ذات البرمجيات المختلفة من الحالة نفسها.
  • الآلية لا تثبت الهوية ولا تشفّر DNS. يستطيع مراقب على المسار رؤية الرموز، ويجمع NAT عملاء كثيرين خلف عنوان واحد، لذلك تبقى قيود المعدل والدفاعات الأخرى ضرورية.

لا يحمل الاستعلام الأول حساباً أو شهادة أو مفتاحاً متفقاً عليه. يصل على هيئة رزمة UDP بعنوان مصدر قد يكون حقيقياً أو منتحلاً. يضع العميل Client Cookie بطول ثمانية بايتات في خيار COOKIE ضمن EDNS. إذا دعم الخادم الآلية، أعاد القيمة نفسها وأضاف Server Cookie من إنشائه. وفي الاستعلام التالي يقدّم العميل الاثنين معاً.

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

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

كانت تلك المعلومة مفيدة لأن DNS فوق UDP قد يحوّل انتحال المصدر إلى تضخيم. يمكن لسؤال صغير أن يوجّه رداً أكبر إلى ضحية، ويمكن لطلب مزور أن يفرض على محلّل تكراري عملاً أو تحققاً بـ DNSSEC. وفي الاتجاه الآخر قد تتسابق ردود مزورة مع الرد الصحيح لتسميم الذاكرة المؤقتة. يثبت DNSSEC أصالة البيانات، ويوفر TSIG توثيقاً أقوى للمعاملة مع إدارة مسبقة للمفاتيح، ويصعّب تنويع المنافذ والمعرّفات التخمين، ويحد تنظيم المعدل من المخرجات. أضافت cookies دليلاً خفيفاً على العودة من دون سجل دائم لكل عميل عند الخادم.

في مايو 2016 جعل RFC 7873 خيار COOKIE يحمل الرمز 10 في EDNS. قبل معرفة Server Cookie يرسل العميل ثمانية بايتات فقط. وبعد التعلم يضيف قيمة من الخادم بطول يتراوح في المواصفة الأصلية بين ثمانية واثنين وثلاثين بايتاً. تركت المواصفة طريقة الإنشاء الدقيقة لكل تنفيذ. وهكذا يستطيع الخادم إعادة حساب القيمة من المصدر وClient Cookie وسره، بدلاً من تخزين جلسة مستقلة.

تسمح آلة الحالات بالنشر التدريجي. الخادم غير الداعم يتجاهل الخيار. والخادم الداعم الذي يتلقى Client Cookie وحده يستطيع وفق سياسته إسقاط الطلب أو إرسال BADCOOKIE أو الإجابة بشكل طبيعي؛ وإذا أجاب، أعاد Server Cookie للانتقال إلى الحالة التالية. الطول غير القانوني يؤدي إلى FORMERR. أما القيمة القديمة أو غير الصحيحة فتعامل كأنها غير موجودة. يتيح الرمز الصحيح تخفيف القيود الموجهة تحديداً إلى انتحال مصدر UDP، لا منح ثقة عامة.

لذلك يمثل BADCOOKIE انتقالاً لا مجرد خطأ. إذا أعاد الرد Client Cookie المطابق، يحفظ العميل قيمة الخادم الجديدة ويحاول ثانية. وإذا فشلت القيمة الجديدة فوراً، يستطيع الانتقال إلى TCP. وقد تكشف الإخفاقات المتكررة خللاً داخلياً: عقد العنوان anycast نفسه لا تتفق على السر أو طريقة البناء.

يوضح NAT سبب الحاجة إلى الجزأين. لو ارتبط Server Cookie بالعنوان العام وحده، لاستطاع جهاز واحد الحصول على رمز تستخدمه كل الأجهزة خلف البوابة. يميّز إدخال Client Cookie التدفقات من دون حفظ هوية فردية. لكنه يظل تمييزاً شبكياً ولا يحدد الشخص.

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

في أبريل 2021 عالج RFC 9018 المشكلة ببنية Server Cookie للإصدار 1 بطول ستة عشر بايتاً: بايت للإصدار، وثلاثة بايتات محجوزة، وأربعة للطابع الزمني، وثمانية لناتج SipHash-2-4. ومع Client Cookie يصبح طول الخيار الكامل أربعة وعشرين بايتاً بالضبط. يغطي الحساب Client Cookie والحقول البنيوية وعنوان IP للعميل وServer Secret. يدخل العنوان في التحقق من دون أن يُنسخ داخل الرمز.

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

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

عدّل RFC 9018 أيضاً إرشاد Client Cookie: أربعة وستون بتاً عشوائياً مستقلاً لكل عنوان خادم، وعدم إعادة استخدام الرموز بعد تغيّر عنوان العميل. يمنع ذلك المعرّف الثابت من تتبع الجهاز بين الشبكات. وقد لا يدرك مضيف خلف NAT أن العنوان العام للبوابة تغير؛ تبقى هذه الملاحظة خارج نطاق الآلية.

ليست قصة DNS Cookies قصة حصول DNS على الهوية، بل قصة مطابقة الدليل مع الادعاء الذي يستطيع حمله. لا تثبت الرحلة الأولى نية؛ إنها تنشئ رمزاً يجعل كذبة العنوان الذي لم يتلق الرد أصعب من خارج المسار. صاغ RFC 7873 هذا التبادل، وجعله RFC 9018 قابلاً للعمل في مجموعة anycast متنوعة. تبقى السلطة الفعلية في سياسة العميل والخادم، وفي ضبط الوقت، وفي الحيازة المنسقة للأسرار.

المصادر