بازگشت به وبلاگ

ECH فعال است، اما SNI هنوز قابل مشاهده است: چگونه رمزنگاری نام سایت را در سال 2026 بررسی کنیم

رمزگذاری نام سایت در TLS در مارس 2026 به استاندارد تبدیل شد، اما همیشه فعال نمی‌شود: مرورگر به طور خاموش به SNI باز می‌گردد. بررسی می‌کنیم که چگونه در یک دقیقه ECH را از طریق crypto.cloudflare.com و dig بررسی کنیم، چرا شروع نمی‌شود، چگونه دروازه‌های شرکتی آن را قطع می‌کنند و در سطح کشور خاموش می‌کنند — و چرا برای تجزیه و دور زدن مسدودیت‌ها بی‌فایده است.

📅۱۰ شهریور ۱۴۰۵
ECH فعال است، اما SNI هنوز قابل مشاهده است: چگونه رمزنگاری نام سایت را در سال 2026 بررسی کنیم
```html

ECH — رمزگذاری نام سایت در TLS-Handshake — در مارس 2026 به عنوان استاندارد شناخته شد (RFC 9849, Standards Track). فایرفاکس و کروم به طور پیش‌فرض آن را فعال می‌کنند و Cloudflare کلیدها را تقریباً به تمام مشتریان خود ارائه می‌دهد. با این حال، برای اکثر کاربران ECH به طور خاموش کار نمی‌کند: مرورگر به یک handshake معمولی باز می‌گردد و ارائه‌دهنده همچنان می‌بیند که شما به کجا می‌روید.

در زیر — نحوه بررسی اینکه آیا 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 برود، ناظر به سادگی نام دامنه را قبل از handshake می‌بیند و resolver فیلتر می‌تواند پارامتر 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 به همه دامنه‌ها داده نمی‌شود — تعجب نکنید اگر یک سایت خاص آن را نداشته باشد.

اگر dig خطا می‌دهد ignoring invalid type HTTPS — شما نسخه قدیمی ابزار را دارید، از فرم عددی TYPE65 استفاده کنید، همانطور که در فرمان بالا آمده است.

چرا ECH برای شما فعال نمی‌شود: پنج دلیل به ترتیب

  1. DNS رمزگذاری شده غیرفعال است. بدون DoH، مرورگر نمی‌تواند ECHConfig را به صورت معتبر دریافت کند. در فایرفاکس: تنظیمات → حریم خصوصی → DNS از طریق HTTPS در حالت «افزایش یافته» یا «حداکثر حفاظت». در کروم: تنظیمات → امنیت → استفاده از DNS امن.
  2. دامنه به سادگی رکورد HTTPS با ech= ندارد — با فرمانی از بلوک بالا بررسی می‌شود. این به شما بستگی ندارد، این تصمیم مالک سایت و CDN اوست.
  3. Resolver پارامتر را حذف می‌کند. سرورهای DNS شرکتی و ارائه‌دهنده معمولاً رکوردهای HTTPS را بدون ech= ارائه می‌دهند. بررسی کنید که رکورد را مستقیماً از یک resolver عمومی (@1.1.1.1) درخواست کرده و با پاسخ سیستم مقایسه کنید.
  4. پرچم‌های مرورگر ریست شده‌اند. در فایرفاکس، network.dns.echconfig.enabled و network.dns.http3_echconfig.enabled در about:config پاسخ می‌دهند — هر دو باید true باشند.
  5. در وسط یک دروازه بازرسی‌کننده قرار دارد. درباره این — بخش بعدی است.

چگونه ECH را می‌شکنند: دو طرح متفاوت

فایروال شرکتی: کاهش خاموش

فروشندگان تجهیزات شبکه دستورالعمل‌های آماده‌ای برای مقابله با ECH منتشر کرده‌اند — آنها آماده نیستند که دید ترافیک را از دست بدهند. به عنوان مثال، سیسکو از پایگاه داده برنامه‌های 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) می‌گذرد. این به صورت قطع اتصال پیاده‌سازی نشده است، بلکه به آرامی بسته‌های داده را رد می‌کند: صفحه معلق می‌ماند و به دلیل زمان‌بر بودن قطع می‌شود. هم TCP-based HTTP/2 و هم QUIC/HTTP-3 تحت تأثیر قرار می‌گیرند. روسکوم‌نadzor در آن زمان به طور مستقیم اعلام کرد که استفاده از TLS ECH قوانین روسیه را نقض می‌کند و به مالکان سایت‌ها توصیه کرد که از CDN Cloudflare خارج شوند — هزاران منبع کاملاً قانونی که در یک پوشش عمومی قرار داشتند، به یکباره تحت فیلتر قرار گرفتند.

فایرفاکس در چنین شرایطی تقریباً پس از یک دقیقه دوباره تلاش می‌کند، اما بدون ECH — یعنی در نهایت SNI باز را ارائه می‌دهد، که مشخصات به دلایل امنیتی توصیه نمی‌کند. اگر شما مشاهده می‌کنید که «سایت به مدت یک دقیقه بارگذاری می‌شود، سپس باز می‌شود» — این تقریباً به طور قطع همین است.

زمانی که ECH کافی نیست و چه چیزی به جای آن قرار دهید

بیایید به وظایف به طور صادقانه بپردازیم.

  • حریم خصوصی از ارائه‌دهنده در اینترنت خانگی. ECH + DoH — یک بهبود خوب و رایگان است. در جایی که آن را قطع نمی‌کنند، کار می‌کند.
  • دور زدن فیلترینگ. ECH برای این منظور طراحی نشده است و عمل نشان داده است: به محض اینکه شروع به مزاحمت برای فیلترها کرد، توانستند آن را شناسایی کرده و به طور کامل خاموش کنند. نمی‌توان به آن به عنوان ابزاری برای دسترسی تکیه کرد.
  • تجزیه، چند حساب کاربری، اتوماسیون. ECH هیچ چیزی ارائه نمی‌دهد: سایت هدف IP شما، JA4 شما و تاریخچه درخواست‌های شما را می‌بیند. فقط منبع IP و کیفیت اثر انگشت اهمیت دارد.

در تمام مواردی که ECH نمی‌تواند کار کند، لایه‌ای ساده‌تر اما مطمئن‌تر کار می‌کند: انتقال TLS-Handshake به خارج از شبکه قابل مشاهده. زمانی که ترافیک از طریق پروکسی می‌رود، ناظر در کانال شما فقط اتصال به گره پروکسی را می‌بیند — هیچ SNI از سایت هدف در آن وجود ندارد، صرف نظر از اینکه آیا دامنه ECH را پشتیبانی می‌کند یا خیر. برای دسترسی روزمره و کار با خدماتی که به شهرت IP حساس هستند، پروکسی‌های مسکونی مناسب هستند؛ برای برنامه‌های موبایل و پلتفرم‌هایی که به نوع اتصال به شدت حساس هستند — موبایل.

و فراموش نکنید که درباره DNS: پروکسی در مرورگر تضمین نمی‌کند که نام‌ها از طریق آن حل شوند. نشت DNS دقیقاً همان چیزی را که سعی کردید پنهان کنید، افشا می‌کند — اینکه چگونه این را بررسی کنید، در دستورالعمل جداگانه‌ای درباره بررسی پروکسی برای نشت DNS توضیح داده شده است. اگر سوال دقیقاً در مورد تجزیه و تحلیل عمیق ترافیک در کانال باشد، باید به خود حمل و نقل نگاه کنید، نه به ECH.

چک لیست کوتاه

  1. باز کردن crypto.cloudflare.com/cdn-cgi/trace و مشاهده خط sni=.
  2. اگر plaintext — DoH را در مرورگر فعال کنید و دوباره بررسی کنید.
  3. کمک نکرد — وجود کلید را در دامنه بررسی کنید: dig +short TYPE65 دامنه @1.1.1.1، به دنبال FE0D باشید.
  4. کلید وجود دارد، اما ECH اعمال نمی‌شود — پاسخ resolverهای عمومی و سیستمی را مقایسه کنید: احتمالاً پارامتر در مسیر حذف می‌شود.
  5. اتصال به مدت یک دقیقه معلق می‌ماند و باز می‌شود — ECH در سطح شبکه خاموش می‌شود؛ ECH در اینجا کمک نمی‌کند، به حمل و نقل دیگری نیاز است.

نتیجه‌گیری

ECH — این آخرین شکاف به دقت بسته شده در حریم خصوصی TLS است، نه ابزاری برای دسترسی و به ویژه نه ابزاری برای اتوماسیون. این به DNS رمزگذاری شده وابسته است، در وسط بدون هیچ خطایی در صفحه غیرفعال می‌شود و در جایی که شروع به مزاحمت می‌کند، به طور کامل خاموش می‌شود. بررسی آن ارزش دارد — دو فرمان بالا یک دقیقه زمان می‌برد. اما ساختن دور زدن مسدودیت‌ها یا محافظت در برابر سیستم‌های ضد ربات بر اساس آن بی‌معناست: این وظایف در سطح IP و اثر انگشت TLS که سرور در طرف دیگر می‌بیند، حل می‌شوند.

```