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 رمزنگاری شده‌اند.

تولید کلیدها

از نسخهٔ 2.12.3 به بعد، از مولد داخلی Hysteria استفاده کنید:

hysteria ech --public-name decoy.example.com

گزینهٔ --public-name الزامی است: این مقدار SNI بیرونی است که به صورت متن ساده ارسال می‌شود، نه نام واقعی سرور.

این دستور فایل ech.pem را ایجاد می‌کند و بلوک‌های پیکربندی سرور و کلاینت را به شکلی آمادهٔ کپی و استفاده چاپ می‌کند.

فایل شامل هر دو بلوک PEM است:

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

فایل ech.pem را خصوصی نگه دارید. این فایل حاوی کلید خصوصی است. فقط مقدار base64 چاپ‌شده در تنظیم tls.ech کلاینت را به اشتراک بگذارید. سرور بلوک ECH KEYS را می‌خواند و فهرست پیکربندی عمومی متناظر را از آن به دست می‌آورد.

گزینه‌ها:

گزینه	پیش‌فرض	توضیح
--public-name	الزامی	SNI بیرونی که به صورت متن ساده ارسال می‌شود.
--output, -o	ech.pem	فایل خروجی PEM حاوی کلید خصوصی.
--config-id	یک بایت تصادفی	شناسهٔ پیکربندی، بین 0 تا 255؛ مقدار -1 یک شناسهٔ تصادفی انتخاب می‌کند. هنگام تعویض کلیدها، برای کلیدهایی که هم‌زمان فعال هستند شناسه‌های متفاوتی به کار ببرید.
--max-name-length	0	راهنمای طول نام درونی برای محاسبهٔ پُرکننده (padding)، بین 0 تا 255. صفر به معنای نامشخص بودن است؛ این مقدار طول نام واقعی سرور را محدود نمی‌کند.
--aead	aes-128-gcm	الگوریتم‌های HPKE AEAD به ترتیب اولویت و جداشده با کاما: aes-128-gcm، aes-256-gcm، chacha20-poly1305.
--overwrite	غیرفعال	جایگزینی صریح فایل کلید موجود.

کلیدهای تولیدشده جایگزین گواهی TLS سرور نمی‌شوند. گواهی موجود و تنظیمات اعتبارسنجی کلاینت را حفظ کنید. تعویض کلیدهای ECH مستلزم توزیع پیکربندی عمومی جدید میان کلاینت‌ها است؛ پس از آنکه سرور پذیرش پیکربندی قبلی را متوقف کند، کلاینت‌هایی که فقط از پیکربندی قبلی استفاده می‌کنند نمی‌توانند متصل شوند.

فایل‌های کلید تولیدشده با sing-box generate ech-keypair نیز با Hysteria سازگار هستند.

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

یک بلوک 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 را روی فهرست پیکربندی چاپ‌شده توسط hysteria ech یا موجود در لاگ سرور تنظیم کنید. مقدار می‌تواند مستقیماً رشتهٔ base64 باشد، یا مسیر فایلی که آن را در بر دارد (چه base64 خام و چه بلوک PEM با عنوان ECH CONFIGS):

tls:
  sni: real.example.com # (1)!
  ech: AEz+DQBIAAAg... # (2)!

1. نام واقعی سرور شما که برای تأیید گواهی استفاده می‌شود.
2. فهرست پیکربندی چاپ‌شده توسط hysteria ech یا موجود در لاگ سرور، یا مسیر فایلی که آن را در بر دارد.

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

رفتارهای مهم

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

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

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