ECH — تشفير اسم الموقع في مصافحة TLS — حصل في مارس 2026 على حالة المعيار (RFC 9849, Standards Track). يتضمنه Firefox وChrome بشكل افتراضي، وتقوم Cloudflare بتوزيع المفاتيح تقريبًا على جميع عملائها. ومع ذلك، فإن معظم المستخدمين لا يعمل لديهم ECH بشكل صامت: يتجه المتصفح إلى المصافحة العادية، ولا يزال مزود الخدمة يرى إلى أين تذهب.
فيما يلي كيفية التحقق بنفسك في دقيقة واحدة مما إذا كان SNI مشفرًا لديك، ولماذا غالبًا ما لا يتم تشفيره، وفي أي سيناريوهات يكون ECH عديم الفائدة بشكل أساسي (مفاجأة: بالنسبة لمكافحة الكشف والتجميع — تقريبًا دائمًا).
ما الذي يخفيه ECH — وما لا يخفيه
في TLS 1.3 العادي، كل شيء مشفر باستثناء الرسالة الأولى — ClientHello. في هذه الرسالة، يوجد حقل SNI بنص واضح مع النطاق الذي تتصل به. تعمل معظم أنظمة التصفية بناءً على SNI: عنوان IP واحد لآلاف المواقع عبر CDN، والنطاق مرئي.
يقوم ECH بتقسيم ClientHello إلى قسمين:
- ClientHelloOuter — يذهب بشكل علني، ولكن مع نطاق مزيف كغلاف. في Cloudflare، هذا هو
cloudflare-ech.com. - ClientHelloInner — النطاق الحقيقي، ALPN وقائمة التشفيرات، مشفرة بمفتاح عمومي من الخادم.
المفتاح لهذا التشفير يأخذه المتصفح ليس من الاتصال، ولكن من DNS — من سجل HTTPS (النوع 65)، المعامل ech=. ومن هنا تأتي النتيجة الرئيسية التي يتم نسيانها: ECH غير ممكن بدون DNS مشفر. إذا كان طلب DNS يذهب عبر UDP/53 مفتوح، فإن المراقب يرى ببساطة اسم النطاق قبل المصافحة، ويمكن لمحلل التصفية قطع المعامل ech= من الاستجابة — ولن يتم تفعيل ECH.
ما لا يخفيه ECH على الإطلاق:
- عنوان IP الوجهة — مرئي دائمًا؛
- حجم وتوقيتات حركة المرور;
- بصمة TLS للعميل (JA3/JA4) — مجموعة التشفيرات والامتدادات تبقى في الجزء العلني;
- لك بالنسبة للموقع نفسه — يرى الخادم بعد فك التشفير كل ما رآه سابقًا.
النقطة الأخيرة هي السبب في أن ECH لا علاقة له بتجاوز أنظمة مكافحة الروبوتات. تعمل Cloudflare وDataDome وAkamai على جانب الخادم: لا يهمهم ما إذا كان SNI مشفرًا في الطريق. إذا كانت المهمة هي عدم الظهور أثناء التشغيل الآلي، فإن طبقة مختلفة تمامًا تعمل: تغيير بصمة TLS نفسها، وهو ما ناقشناه في المادة حول تجاوز بصمة JA4 عبر curl-cffi.
التحقق رقم 1: هل يعمل ECH الآن (10 ثواني)
افتح في المتصفح:
https://crypto.cloudflare.com/cdn-cgi/trace
ابحث عن السطر sni=. هناك حالتان محتملتان:
sni=encrypted— يعمل ECH، اسم الموقع مخفي في الطريق;sni=plaintext— لم يتم تطبيق ECH، النطاق ذهب بنص واضح.
نفس العنوان عبر curl في الطرفية سيعيد دائمًا sni=plaintext — curl العادي لا يدعم ECH، وهذا مؤشر مريح: هكذا يبدو "مغلق".
التحقق رقم 2: هل لدى النطاق مفتاح ECH (dig، بدون متصفح)
سيتم تفعيل ECH فقط إذا كان لدى النطاق في DNS سجل HTTPS مع المعامل ech=. دعنا نتحقق من السجل الخام:
dig +short TYPE65 example.com @1.1.1.1
في الاستجابة، ابحث عن البايتات FE0D — هذا هو رمز امتداد ECH، يليه ECHConfig. مثال عملي: في وقت إعداد المادة، كان لدى crypto.cloudflare.com ونطاقنا proxycove.com سجل بطول 133–136 بايت يحتوي على كل من FE0D واسم مزيف cloudflare-ech.com في شكل hex. أما بالنسبة لـ cloudflare.com نفسه، فالسجل قصير، 61 بايت: فقط ALPN وتلميحات IP، بدون ECH. أي أنه حتى داخل بنية Cloudflare، لا يتم توزيع ECH على جميع النطاقات بشكل عشوائي — لا تتفاجأ إذا لم يكن لدى موقع معين ECH.
إذا كان dig يشتكي ignoring invalid type HTTPS — لديك إصدار قديم من الأداة، استخدم الشكل الرقمي TYPE65، كما في الأمر أعلاه.
لماذا لا يتم تفعيل ECH لديك: خمس أسباب بالترتيب
- تم إيقاف تشغيل DNS المشفر. بدون DoH، لن يحصل المتصفح على ECHConfig بشكل موثوق. في Firefox: الإعدادات → الخصوصية → DNS عبر HTTPS في وضع "مرتفع" أو "أقصى حماية". في Chrome: الإعدادات → الأمان → استخدام DNS آمن.
- النطاق ببساطة ليس لديه سجل HTTPS مع
ech=— يتم التحقق منه بالأمر من القسم أعلاه. هنا لا يعتمد الأمر عليك، هذا قرار مالك الموقع وCDN الخاص به. - المحلل يقطع المعامل. خوادم DNS المؤسسية ومزودي الخدمة عادة ما تقدم سجلات HTTPS بدون
ech=. تحقق من ذلك، بطلب السجل مباشرة من محلل عام (@1.1.1.1) ومقارنة الاستجابة مع النظامية. - تم إعادة تعيين علامات المتصفح. في Firefox، تتعلق
network.dns.echconfig.enabledوnetwork.dns.http3_echconfig.enabledبـabout:config— يجب أن تكون كلاهماtrue. - يوجد بوابة تفتيش في المنتصف. حول هذا — القسم التالي.
كيف يتم كسر ECH: مخططان مختلفان
جدار ناري مؤسسي: انخفاض هادئ
أصدرت شركات معدات الشبكات وصفات جاهزة ضد ECH — فهي غير مستعدة لفقدان رؤية الحركة. على سبيل المثال، تحدد Cisco، منذ قاعدة التطبيقات VDB 416 (أكتوبر 2025)، "خوادم ECH" كتطبيق منفصل وتقترح نهجين: اعتراض الاتصال مع إعادة إنشاء الشهادة وقطع امتداد encrypted_client_hello من ClientHello، أو العمل بشكل أبسط — على مستوى DNS: حظر سجلات HTTPS لنطاقات ECH، وقطع DoH/DoT/DoQ، وحظر النطاق الكاناري use-application-dns.net والسماح بـ DNS فقط على خوادم الشركات.
تكمن حيلة المخطط الأول في أنه لا يبدو كحظر. الخادم، عند عدم رؤية امتداد ECH، يستجيب كالمعتاد، ويعتبر العميل ECH "مغلقًا بأمان" ويتصل مرة أخرى مع SNI مفتوح. تم فتح الموقع، لا توجد أخطاء — ولكن اسم النطاق ذهب إلى سجل البوابة.
مستوى الدولة: الاتصال ببساطة يموت
المثال الروسي دقيق في دقته. اعتبارًا من 5 نوفمبر 2024، تعمل التصفية فقط عند تطابق علامتين معًا: SNI بقيمة cloudflare-ech.com بالإضافة إلى وجود امتداد ECH. بشكل منفصل، لا يؤدي أي منهما إلى حظر — يمر ECH إلى نطاقات الغلاف الأخرى (مثل النطاقات التجريبية defo.ie أو tls-ech.dev). يتم تنفيذ ذلك ليس عن طريق قطع الاتصال، ولكن بـ إسقاط الحزم بهدوء: تتجمد الصفحة وتفشل بسبب انتهاء المهلة. تشمل هذه المشكلة كل من HTTP/2 المعتمد على TCP وQUIC/HTTP-3. في ذلك الوقت، صرح روسكومنادزور مباشرة أن استخدام TLS ECH ينتهك التشريعات الروسية، وأوصى مالكي المواقع بالابتعاد عن CDN Cloudflare — وقد وقع تحت التصفية آلاف الموارد القانونية تمامًا، المدرجة في الغلاف العام.
في مثل هذه الحالة، يحاول Firefox إعادة الاتصال بعد دقيقة تقريبًا بدون ECH — مما يعني أنه في النهاية يقدم SNI مفتوحًا، وهو ما لا توصي به المواصفة لأسباب تتعلق بالأمان. إذا كنت تلاحظ "الموقع يستغرق دقيقة كاملة للتحميل، ثم يفتح" — فمن المحتمل جدًا أن يكون هذا هو السبب.
متى لا يكفي ECH وماذا يجب استخدامه بدلاً منه
دعنا نفصل المهام بصدق.
- الخصوصية من المزود على الإنترنت المنزلي. ECH + DoH — تحسين جيد ومجاني. يعمل حيث لا يتم قطعه.
- تجاوز التصفية. لم يتم تصميم ECH لهذا الغرض، وقد أكدت الممارسة ذلك: بمجرد أن بدأ في إزعاج المرشحات، تعلموا تحديده وإسكاتها بالكامل. لا يمكن الاعتماد عليه كأداة للوصول.
- التجميع، تعدد الحسابات، التشغيل الآلي. لا يقدم ECH شيئًا: يرى الموقع المستهدف عنوان IP الخاص بك، JA4 الخاص بك وتاريخ طلباتك. الأهمية تكمن فقط في مصدر IP وجودة البصمة.
في جميع الحالات التي لا يتعامل فيها ECH، تعمل طبقة أكثر خشونة ولكن موثوقة: إخراج مصافحة TLS خارج الشبكة المرئية. عندما تمر الحركة عبر وكيل، يرى المراقب على قناتك فقط الاتصال بعقدة الوكيل — لا يوجد SNI للموقع المستهدف على الإطلاق، بغض النظر عما إذا كان النطاق يدعم ECH أم لا. للوصول اليومي والعمل مع الخدمات الحساسة لسمعة IP، ستكون الوكلاء السكنيون مناسبة؛ للتطبيقات المحمولة والمنصات التي تكون متطلبة بشكل خاص بشأن نوع الاتصال، ستكون المحمولة مناسبة.
ولا تنسَ DNS: الوكيل في المتصفح لا يضمن أن الأسماء يتم حلها من خلاله أيضًا. تسرب DNS يكشف بالضبط ما كنت تحاول إخفاءه — كيف يتم التحقق من ذلك، ناقشنا في تعليمات منفصلة حول التحقق من الوكيل من تسرب DNS. إذا كانت المسألة تتعلق بالتحليل العميق لحركة المرور على القناة، يجب النظر إلى النقل نفسه وليس ECH.
قائمة مراجعة قصيرة
- فتح
crypto.cloudflare.com/cdn-cgi/traceوالتحقق من السطرsni=. - إذا كان
plaintext— قم بتفعيل DoH في المتصفح والتحقق مرة أخرى. - إذا لم يساعد — تحقق من وجود مفتاح لدى النطاق:
dig +short TYPE65 domain @1.1.1.1، وابحث عنFE0D. - إذا كان المفتاح موجودًا، ولكن ECH لا يتم تطبيقه — قارن استجابة المحللين العامين والنظاميين: من المحتمل أن يتم قطع المعامل في الطريق.
- إذا كان الاتصال يتجمد لمدة دقيقة ثم يفتح — يتم إسكات ECH على مستوى الشبكة؛ ECH هنا لن يساعد، تحتاج إلى نقل آخر.
الاستنتاج
ECH هو الثغرة الأخيرة المغلقة بعناية في خصوصية TLS، وليس وسيلة للوصول، وبالتأكيد ليس أداة للتشغيل الآلي. إنه يعتمد على DNS مشفر، يتم تعطيله في المنتصف دون أي خطأ على الشاشة، ويتم إسكاتها بالكامل حيث يبدأ في إزعاج. من الجدير التحقق منه — الأمرين أعلاه يستغرقان دقيقة. لكن بناءً عليه لتجاوز الحجب أو الحماية من أنظمة مكافحة الروبوتات هو بلا جدوى: يتم حل هذه المهام على مستوى من يرى خادم IP الخاص بك وبصمة TLS الخاصة بك على الطرف الآخر.