الخلاصة

  • يحمل server_name اسماً من DNS يقدمه العميل في ClientHello لتضييق اختيار سياق TLS أو الشهادة أو وجهة التمرير. لا يعمل بوصفه اعتماداً للعميل.
  • تحقق هوية الخدمة وHost أو :authority وSNI الصاعد وحالة ECH وترخيص التطبيق قرارات مستقلة، حتى إذا تكررت فيها السلسلة النصية نفسها.

نجح الاختيار وفشلت السلطة

عثر callback على SSL_CTX المقصود، وقدم الخادم الشهادة الصحيحة، واكتملت مصافحة TLS 1.3. كانت المشكلة في السطر التالي، حين نسخت المنظومة وسم السياق إلى حقل principal ومنحت الاتصال طريقاً إدارياً.

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

تساعد الشهادة المختارة العميل على توثيق الخادم. لا توثق العميل لدى الخادم. لم ينكسر التشفير؛ الذي حدث هو ترقية إشارة اختيار إلى عضوية وصلاحية.

قواعد الصياغة لا تثبت ملكية الاسم

تعرف RFC 6066 قائمة ServerNameList داخل ClientHello. ويحمل النوع host_name اسم مضيف من DNS بصيغة ASCII؛ لا تقبل عناوين IPv4 أو IPv6 الحرفية، ولا يجوز تكرار نوع الاسم نفسه.

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

يجوز للخادم إنهاء الاتصال بتنبيه unrecognized_name قاتل إذا فهم الاسم ورفضه، كما يمكنه اتباع سياسة fallback معلنة. لذلك يجب اختبار غياب SNI والاسم المجهول وغير الصحيح والمضيف الافتراضي فعلياً؛ وجود جدول إعداد لا يبين المسار الذي نُفذ.

سلامة السجل لا تمنح صاحب القول حقاً

يدخل ClientHello في transcript الخاص بـTLS 1.3 الذي توثقه Finished. بعد مصافحة ناجحة، لا يستطيع وسيط تغيير SNI العادي خفية بين الطرفين.

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

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

اختيار الشهادة ليس التحقق منها

يساعد SNI الخادم على اختيار credential. أما RFC 9525 فتطلب من العميل بناء reference identifiers المقبولة بصورة مستقلة، ثم مقارنتها بالهويات المعروضة في الشهادة.

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

يفصل OpenSSL الخطوتين أيضاً. تضبط SSL_set_tlsext_host_name() قيمة SNI، بينما يجب ضبط اسم DNS المتوقع للتحقق من الشهادة بصورة منفصلة. قد يستدعي برنامج الوظيفة الأولى فيحصل على الشهادة المناسبة من دون أن يوثق الخدمة توثيقاً صحيحاً.

وقد تغطي شهادة واحدة أسماء SAN متعددة. هذا يجعلها صالحة تشفيرياً لخدمات عدة، ولا يدمج صلاحيات مستأجريها.

authority في HTTP تصل في طبقة أخرى

بعد TLS يحمل HTTP/1.1 حقل Host، ويستخدم HTTP/2 وHTTP/3 عادة :authority. تعد RFC 9110 هذه المعلومة أساسية لتحديد هدف الطلب وتوجيهه.

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

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

حتى التطابق لا يثبت هوية العميل؛ إنه يثبت اتساق إشارتين إلى الوجهة فقط.

ينشئ الوكيل اتصالاً باسم جديد

حين ينهي الوكيل TLS في الجهة السفلى، يبدأ مصافحة مستقلة في الجهة الصاعدة. لكل ساق ClientHello وSNI وشهادة وreference identity ونتيجة خاصة.

يمكن تثبيت SNI الصاعد أو اشتقاقه من المضيف الصاعد أو authority في HTTP أو خريطة مضبوطة. يميز Envoy هذه المصادر ويفصل التحقق من SAN وفق SNI الفعلي عن التحقق وفق authority الخاصة بالطلب.

في التمرير الشفاف تكون الشهادة أضيق. يستطيع ssl_preread في NGINX قراءة SNI واختيار backend من دون إنهاء TLS. يثبت الجهاز أنه قرأ إشارة واختار مساراً، لا أن الشهادة النهائية قُبلت أو أن المصافحة اكتملت.

لا تكفي خانة واحدة باسم sni. يلزم حفظ معرفي الاتصال ومصدر كل اسم وسبب الاختيار ونتيجة التحقق.

يضع ECH اسماً عاماً وآخر داخلياً

يضع Encrypted Client Hello الخصائص الحساسة في ClientHelloInner. ويحمل ClientHelloOuter عادة public name الذي يوصل الحركة إلى الخادم الأمامي ويدعم retry.

عند قبول ECH تجري المعالجة انطلاقاً من inner الموثق. وعند الرفض قد يوثق العميل اتصالاً بالاسم العام للحصول على إعداد إعادة المحاولة فقط. تنص RFC 9849 على أن هذا لا يوثق origin ولا يجوز إبلاغ التطبيق به كنجاح.

لذلك قد يكون SNI الخارجي صحيحاً للتوجيه ومحدوداً عمداً بوصفه هوية origin. يجب أن تسجل المراقبة حالة ECH ودور نقطة الرصد ومصدر الاسم، وألا تخلط ordinary وouter وaccepted inner.

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

الاختبار الأقوى يحاول إساءة استعمال الإشارة

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

ثم تُختبر حالة غياب SNI والاسم المجهول وfallback واختلاف HTTP authority وشهادة صالحة للاسمين. وفي الوكيل يُفرض SNI صاعد مختلف وتُطلب نتيجتا تحقق مستقلتان. لا يجوز لمسار passthrough ادعاء نجاح TLS. أما ECH فيغطي القبول والرفض/retry وعدم الاستخدام.

وجود callback في OpenSSL أو GnuTLS يثبت القدرة. استجابة الشيفرة المنفذة لهذه الحالات تثبت الحد الحقيقي.