موزیلا اعلام کرده است که برای کاربران شاخه پایدار فایرفاکس از مکانیزم ECH (Encrypted Client Hello) پشتیبانی می کند که به توسعه فناوری ESNI (نمایش نام سرور رمزگذاری شده) ادامه می دهد و برای رمزگذاری اطلاعات در مورد پارامترهای جلسات TLS طراحی شده است. مانند نام دامنه درخواستی. کد کار با ECH ابتدا به نسخه فایرفاکس 85 اضافه شد، اما به طور پیش فرض غیرفعال شد. کروم با شروع کروم 115 به تدریج شروع به پشتیبانی از ECH کرد.
از آنجایی که علاوه بر ارتباط با سرور اطلاعات دامنه درخواستی از طریق DNS فاش میشود. برای محافظت کامل، علاوه بر ECH، باید از DNS over HTTPS یا DNS over TLS برای رمزگذاری ترافیک DNS استفاده کنید. فایرفاکس بدون فعال کردن DNS over HTTPS در تنظیمات، از ECH استفاده نخواهد کرد. میتوانید پشتیبانی ECH را در مرورگر خود در این صفحه بررسی کنید.
یکی از عواملی که پشتیبانی ECH را به طور پیش فرض در فایرفاکس فعال کرد، گنجاندن پشتیبانی از ECH توسط Cloudflare در چند روز پیش در شبکه تحویل محتوای خود بود. از جنبه عملی، از آنجایی که دادههای مربوط به میزبانهای درخواستی هنگام استفاده از ECH از تجزیه و تحلیل پنهان است، فیلتر کردن و مسدود کردن سایتهای ناخواسته با استفاده از Cloudflare CDN اکنون نیاز به مسدود کردن کل شبکه Cloudflare، مسدود کردن تمام درخواستها از ECH یا سازماندهی رهگیری HTTPS با استفاده از گواهیهای ریشه جعلی دارد. در سیستم کاربر
در ابتدا، برای سازماندهی کار بر روی یک آدرس IP از چندین سایت HTTPS، از پسوند TLS SNI استفاده شد که در آن نام میزبان درخواستی در پیام ClientHello ارسال شده قبل از ایجاد یک کانال ارتباطی رمزگذاری شده نشان داده شد. این ویژگی توزیع درخواستها را در میان میزبانهای مجازی در مراحل اولیه پردازش اتصال ممکن میسازد، اما همچنین در سمت ISP امکان فیلتر کردن ترافیک HTTPS و تجزیه و تحلیل سایتهایی را که کاربر باز میکند، در سمت ISP امکانپذیر میسازد، که امکان دستیابی به محرمانه بودن کامل در هنگام استفاده را فراهم نمیکند. HTTPS.
برای حل این مشکل و جلوگیری از نشت اطلاعات در مورد سایت درخواستی، یک پسوند ESNI بعدا پیشنهاد شد که رمزگذاری داده ها را با نام میزبان پیاده سازی می کند. در طول اجرای ESNI، مشخص شد که مکانیسم پیشنهادی تمام منابع احتمالی نشت دادههای میزبان را پوشش نمیدهد و استفاده از آن برای اطمینان از محرمانه بودن کامل جلسات HTTPS کافی نیست. به طور خاص، هنگام از سرگیری جلسه ای که قبلاً ایجاد شده بود، نام دامنه در متن واضح همچنان در بین پارامترهای پسوند PSK (کلید پیش مشترک) TLS مشخص می شد. علاوه بر این، تلاشها برای پیادهسازی ESNI مشکلات سازگاری و مقیاسبندی را شناسایی کردهاند که مانع از پذیرش گسترده ESNI شدهاند.
با در نظر گرفتن کاستی های شناسایی شده ESNI، یک مکانیسم جهانی ECH ایجاد شد که امکان رمزگذاری پارامترهای هر پسوند TLS را فراهم می کند. از نظر فنی، تفاوت اصلی بین ECH و ESNI این است که به جای فیلدهای مجزا، کل پیام ClientHello به یکباره رمزگذاری می شود. ECH شامل تقسیم ClientHello به دو پیام جداگانه است - پیام ClientHelloInner رمزگذاری شده (SNI Inner) و پیام رمزگذاری نشده زیربنایی ClientHelloOuter (SNI Outer). یک SNI Outer رمزگذاری نشده، دادههای غیرمحرمانه مانند نسخه TLS و فهرستی از رمزهای استفاده شده و همچنین یک نام دامنه معمولی را حمل میکند که با نام واقعی دامنه درخواستی همپوشانی ندارد. برای مثال، برای همه کلاینتهای Cloudflare، SNI Outer رمزگذاری نشده، میزبان مشترک «cloudflare-ech.com» را مشخص میکند، اما نام واقعی میزبان درخواستی در SNI داخلی رمزگذاریشده منتقل میشود و برای تجزیه و تحلیل در دسترس نیست.
ECH همچنین از یک طرح توزیع کلید رمزگذاری متفاوت استفاده میکند: اطلاعات کلید عمومی به جای رکوردهای TXT در رکوردهای HTTPSSVC DNS منتقل میشود. رمزگذاری سرتاسریِ احراز هویتشده بر اساس مکانیسم HPKE (رمزگذاری کلید عمومی ترکیبی) برای دریافت و رمزگذاری کلید استفاده میشود. ECH همچنین از ارسال مجدد کلید امن از سرور پشتیبانی میکند که در صورت چرخش کلید میتواند مورد استفاده قرار گیرد. سرور و برای حل مشکلات مربوط به بازیابی کلیدهای قدیمی از حافظه نهان DNS.
منبع: opennet.ru
