لا يزال TLS 1.3 يرسل اسم الخادم في نص صريح

ترقية مستمع إلى TLS 1.3 تغيّر ما يمكن للمراقب قراءته، لكن ليس بالقدر الذي يوحي به رقم الإصدار. لا يزال ClientHello ينتقل قبل التفاوض على أي تشفير، وفي اتصال عادي يوجد اسم الخادم المطلوب هناك في نص صريح. Encrypted Client Hello هو الآلية التي تخفيه، وهو نشر منفصل بشروطه المسبقة. نفّذ هذه الخطوات الأربع قبل كتابة سياسة تفترض أيًا من السلوكين.

ما تكشفه المصافحة فعليًا

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

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

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

اقرأ ClientHello بدلًا من الافتراض

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

openssl s_client -connect app.plant.example:443 -servername app.plant.example -tls1_3 </dev/null> 2>/dev/null | head -20
sudo tcpdump -ni eth0 -c 40 'tcp port 443' -w /tmp/tls.pcap
tshark -r /tmp/tls.pcap -Y 'tls.handshake.extensions_server_name' -T fields -e tls.handshake.extensions_server_name

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

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

تعامل مع امتداد ECH كادعاء، لا كدليل

رؤية امتداد ECH في ClientHello لا تعني أن الاتصال استخدم ECH. يرسل العملاء GREASE ECH عندما لا يملكون تهيئة صالحة للاستخدام، تحديدًا كي تبدو مصافحاتهم موحدة. الامتداد موجود، والـ hello الداخلي طُعم، والاسم الفعلي لا يزال مقروءًا.

dig +short HTTPS app.plant.example
openssl s_client -connect app.plant.example:443 -tls1_3 -status </dev/null> 2>/dev/null | grep -i -E 'ech|status_request'

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

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

اكتب نطاق المراقب في السياسة

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

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

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