Encrypted Client Hello وDoH: ما الذي لم تعد جدران الحماية المحيطية قادرة على رؤيته

اعتمدت جدران حماية الشبكة والخوادم الوسيطة، منذ عشرين عامًا، على حقل واحد غير مشفّر لمعرفة وجهة حركة المرور المشفّرة: مؤشر اسم الخادم (SNI)، وهو اسم المضيف الذي يعلنه العميل في أول رسالة من مصافحة TLS. بروتوكول DNS عبر HTTPS (DoH، RFC 8484) أخفى بالفعل استعلام DNS الذي يسبق الاتصال. أما Encrypted Client Hello، المنشور الآن بصفته RFC 9849، فيُخفي مؤشر SNI نفسه. ومعًا، يُزيلان الإشارتين اللتين بُنيت عليهما معظم أنظمة تصفية حركة المرور الصادرة.

كيف يعمل ECH: رسالة ClientHello داخلية وأخرى خارجية

يبني العميل، في بروتوكول ECH، رسالتَي ClientHello. الرسالة الداخلية تحمل الوجهة الحقيقية والمعطيات الحساسة، وتُشفَّر بواسطة HPKE إلى مفتاح عام نشره الخادم مسبقًا. أما الرسالة الخارجية، فتُرسَل دون تشفير وتحمل اسمًا عامًا مشتركًا، عادةً اسم الواجهة الأمامية لمزوّد الخدمة، بحيث لا يعرف المراقب سوى أن العميل يتحدث إلى ذلك المزوّد (RFC 9849؛ شرح Cloudflare).

TLS ClientHello (outer, cleartext)
  server_name:            cloudflare-ech.com      <- shared public name
  encrypted_client_hello: <HPKE ciphertext>        <- real hostname is inside

من أين يأتي المفتاح: سجل DNS من نوع HTTPS

يحتاج العميل إلى مفتاح ECH العام للخادم قبل بدء المصافحة، ويحصل عليه من DNS، عبر سجل الموارد من نوع HTTPS (النوع 65، RFC 9460)، الذي تحمل معلمته ech قائمة ECHConfigList. استعلمنا عن سجل حقيقي بالفعل. أمر dig المضمّن في macOS لا يعرف هذا السجل باسمه، فاطلبه برقمه:

$ dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
     …0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.com

وإذا سار استعلام DNS نفسه عبر DoH، فلن يرى مراقب الشبكة الاستعلام، ولا اسم المضيف داخل المصافحة إذا استُخدم ECH. وهذا الجمع بين الاثنين هو موضوع هذا المقال.

استخدام ECH قرار يتخذه العميل لا الشبكة

ECH ليس شيئًا تُفعّله الشبكة؛ فكل عميل يقرر بنفسه. أضافت المتصفحات دعمًا له (Chrome Platform Status)، وغالبًا ما يرتبط ذلك باستخدام DNS مشفّر. وبرامج كثيرة أخرى لا تستخدمه إطلاقًا. تُظهر نقطة تتبع Cloudflare ما استقبلته فعليًا، وأمر curl المضمّن في macOS لا يزال يرسل اسم المضيف دون تشفير:

$ curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext

والصورة الواقعية اليوم صورة مختلطة: المتصفحات تُخفي اسم المضيف على نحو متزايد، وبرامج أخرى كثيرة لا تفعل، وأي برنامج صُمّم لتفادي المراقبة يمكنه اختيار استخدام ECH وDoH عمدًا.

ما تفقده جدران الحماية المحيطية، وما تحتفظ به

والخلاصة الصادقة أن التصفية القائمة على اسم المضيف عند حافة الشبكة تتوقف عن العمل مع حركة مرور ECH، بينما تبقى الضوابط القائمة على IP فعّالة. لا تزال الشبكة قادرة على رفض الاتصال بمحلِّلات DoH معروفة، وهو ما يمنع المتصفحات عمليًا من الحصول على مفاتيح ECH عبر DNS مشفّر، وقادرة أيضًا على حظر نطاقات عناوين بأكملها. لكنها لم تعد قادرة على التمييز بين موقعين خلف المزوّد نفسه، أو السماح بأحدهما وحظر الآخر، دون كسر TLS بطريقة صُمّم ECH لاكتشافها.

الرؤية تنتقل إلى الجهاز نفسه

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

• قرّر على مستوى التطبيق لا على مستوى اسم المضيف: يحصل المتصفح وعميل المزامنة والملف التنفيذي المجهول على قواعد مختلفة.
• اعتبر أيّ برنامج يبدأ اتصال DoH خاصًا به إلى محلِّل لم يُعدّه النظام إشارة تستحق النظر.
• أبقِ قوائم الحظر القائمة على IP عند حافة الشبكة؛ فهي لا تزال تعمل، وتكلفتها معدومة.

دور FireAI وHisnLabs

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

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

يمكنك الاطلاع على القرارات التقنية وراء ذلك، أو تجربة FireAI لمدة 17 يومًا، على FireAI من HisnLabs.