پرش به محتویات

ECH

ECH (Encrypted Client Hello) پیام TLS ClientHello را رمزنگاری می‌کند، از جمله SNI (Server Name Indication)، به طوری که فقط یک «نام عمومی» ساختگی برای تجهیزات میانی قابل مشاهده است.

بدون ECH، مقدار SNI در هر دست‌دهی به صورت متن ساده منتقل می‌شود و این امکان را به تجهیزات میانی می‌دهد که آن را بازرسی و مسدود کنند. با ECH، نام واقعی سرور درون یک بارِ دادهٔ رمزنگاری‌شده قرار دارد.

توجه داشته باشید که ECH فقط از SNI در دست‌دهی QUIC/TLS محافظت می‌کند. اگر از قبل از مبهم‌سازی استفاده می‌کنید، کل اتصال دیگر به عنوان QUIC قابل تشخیص نیست، بنابراین ECH مزیت اضافه‌ای فراهم نمی‌کند. ECH بیشترین کاربرد را در حالت «بدون پوشش» (bare) دارد، جایی که دست‌دهی QUIC استاندارد است و SNI اصلی‌ترین اثر انگشت متن ساده محسوب می‌شود.

نحوهٔ کارکرد

یک استقرار ECH دو محصول (artifact) دارد که با هم به صورت یک جفت‌کلید تولید می‌شوند:

  • یک کلید خصوصی که روی سرور باقی می‌ماند و برای رمزگشایی ClientHello واقعی استفاده می‌شود.
  • یک فهرست پیکربندی (config list) عمومی که کلاینت‌ها از آن برای رمزنگاری ClientHello خود استفاده می‌کنند. این فهرست همچنین شامل نام عمومی است — همان SNI ساختگی که به صورت متن ساده ظاهر می‌شود.

وقتی یک کلاینت با ECH متصل می‌شود، یک ClientHello ارسال می‌کند که SNI قابل مشاهدهٔ آن همان نام عمومی است (مثلاً decoy.example.com)، در حالی که SNI واقعی و بقیهٔ دست‌دهی درون افزونهٔ ECH رمزنگاری شده‌اند.

تولید کلیدها

Hysteria خودش کلیدهای ECH را تولید نمی‌کند. توصیه می‌کنیم برای ساخت یک جفت‌کلید از sing-box استفاده کنید:

sing-box generate ech-keypair decoy.example.com

آرگومان همان نام عمومی است. لازم نیست دامنه‌ای باشد که مالک آن هستید، اما برای بهترین استتار بهتر است نامی بی‌خطر باشد که به طور باورپذیر ترافیک عادی ارائه می‌دهد. این دستور دو بلوک PEM چاپ می‌کند:

-----BEGIN ECH CONFIGS-----
...
-----END ECH CONFIGS-----
-----BEGIN ECH KEYS-----
...
-----END ECH KEYS-----

کل خروجی را در یک فایل ذخیره کنید (مثلاً ech.pem). سرور بلوک ECH KEYS را از آن می‌خواند؛ نیازی نیست بلوک‌ها را به صورت دستی از هم جدا کنید.

sing-box generate ech-keypair decoy.example.com > ech.pem

راه‌اندازی سرور

یک بلوک ech اضافه کنید که به فایل کلید اشاره می‌کند.

ech:
  keyPath: ech.pem

هنگام راه‌اندازی، سرور فهرست پیکربندی مورد نیاز کلاینت‌ها را در لاگ ثبت می‌کند:

INFO ECH enabled, set the following config list on clients (tls.ech) {"configList": "AEz+DQBIAAAg..."}

آن رشتهٔ base64 را کپی کنید — همان چیزی است که به کلاینت‌ها می‌دهید. (این همان مقدار بلوک ECH CONFIGS است، فقط به صورت base64 در یک خط واحد کدگذاری شده است.)

راه‌اندازی کلاینت

tls.ech را روی فهرست پیکربندی موجود در لاگ سرور تنظیم کنید. مقدار می‌تواند مستقیماً رشتهٔ base64 باشد، یا مسیر فایلی که آن را در بر دارد (چه base64 خام و چه بلوک PEM با عنوان ECH CONFIGS):

tls:
  sni: real.example.com # (1)!
  ech: AEz+DQBIAAAg... # (2)!
  1. نام واقعی سرور شما که برای تأیید گواهی استفاده می‌شود.
  2. فهرست پیکربندی موجود در لاگ سرور، یا مسیر فایلی که آن را در بر دارد.

فهرست پیکربندی را می‌توان از طریق پارامتر پرس‌وجوی ech در یک URI اشتراک‌گذاری نیز حمل کرد.

رفتارهای مهم

  • فعال‌سازی ECH با نسخه‌های قبلی سازگار است. سروری که ECH روی آن فعال است همچنان کلاینت‌هایی را که از ECH استفاده نمی‌کنند می‌پذیرد؛ این کلاینت‌ها صرفاً مانند قبل SNI خود را به صورت متن ساده ارسال می‌کنند. این یعنی می‌توانید ECH را روی سرور فعال کنید بدون اینکه کلاینت‌های موجود از کار بیفتند.

  • شکست ایمن (fail-closed). اگر یک کلاینت برای ECH پیکربندی شده باشد اما سرور آن را رد کند (برای مثال به این دلیل که پس از تولید مجدد کلیدها فهرست پیکربندی منسوخ شده، یا سرور اصلاً ECH پیکربندی‌شده‌ای ندارد)، اتصال شکست می‌خورد.

  • insecure بر ردِ ECH اعمال نمی‌شود. وقتی ECH رد می‌شود، پشتهٔ TLS یک بررسی اجباری گواهی در برابر نام عمومی انجام می‌دهد و tls.insecure را نادیده می‌گیرد. اگر با یک گواهی self-signed در حال آزمایش هستید و سرور در واقع ECH را نمی‌پذیرد، با خطای تأیید گواهی مواجه خواهید شد.