HTTPS از راه رسید و اینترنت را بهطور چشمگیری دگرگون کرد. دادههای ما خصوصیتر از همیشه شدند؛ کافی بود مرورگرهای بزرگ، و گوگل، همه را به رعایت این استاندارد وادار کنند.
زیر پوست ماجرا، «کلاینت هلوی رمزنگاریشده» در واقع شکافی را میبندد که سراسر دوران HTTPS وجود داشته است: حتی در یک اتصال کاملاً رمزنگاریشده نیز ارائهدهنده اینترنت شما همیشه میتوانست ببیند از کدام وبسایت بازدید میکنید، هرچند نمیفهمید آنجا چه میکنید.
بهتر از آن، ECH همه این کار را بینیاز از VPN یا فعالکردن گزینههای امنیتی دیگر انجام میدهد؛ قابلیتی که مستقیماً در مرورگر شما جای گرفته است.
همهچیز به شیوه گفتوگوی دستگاه شما با سرور مربوط است
دادهها از شکافهای کوچک نشت میکنند
HTTPS را معمولاً همان چیزی معرفی میکنند که وبگردی را خصوصی کرد. اما چنین نیست؛ دستکم نه بهطور کامل.
هر بار که به یک وبسایت، اپلیکیشن یا خدمت برخط وصل میشوید و همهچیز بیدردسر سر جای خود قرار میگیرد، انبوهی از استانداردها و پروتکلها در پشت صحنه با یکدیگر ارتباط گرفتهاند.
یکی از نخستین گامها، دستدادن TLS است که میان دستگاه شما و سرور، اتصالی رمزنگاریشده برقرار میکند. نخستین پیام این فرایند، که «پیام ClientHello» نام دارد، نام میزبان سایت را در بخشی از فرایند با عنوان فیلد «نشانهگذاری نام سرور» یا SNI در بر میگیرد.
دلیلش این است که سرور باید پیش از رمزنگاریشدن هر چیز، بداند کدام گواهی را بازگرداند. پس از پایان دستدادن، محتوای صفحه، کوکیها و گذرواژهها قفل و محافظت میشوند.
اما این فیلد همیشه بهصورت متن ساده منتقل میشد؛ یعنی حتی در دوران HTTPS نیز دادهای بود که ارائهدهنده اینترنت شما میتوانست آن را ببیند. البته این داده برای سرور وبسایت سودمند است، زیرا پیش از آغاز رمزنگاری به آن امکان میدهد گواهی درست را برای دستگاه شما تشخیص دهد.
«کلاینت هلوی رمزنگاریشده» دقیقاً برای محافظت از همین بخش طراحی شده است؛ استانداردی که با نهاییشدن و انتشار RFC ۹۸۴۹ در مارس ۲۰۲۶ رسمیت یافت.
با این حال، گرچه استاندارد تنها امسال نهایی شد، مرورگرهای بزرگی مانند کروم و فایرفاکس از سال ۲۰۲۳ از ECH پشتیبانی میکردند و اندروید نیز در اوت ۲۰۲۶ پشتیبانی از ECH را افزود.
مشکل را میبینید؟ شکاف، همان فاصله میان رسیدن درخواست و آغاز رمزنگاری است. شاید مسئله بزرگی به نظر نرسد، اما شواهدی وجود دارد که نشان میدهد پیشتر در دنیای واقعی برای گردآوری داده از آن سوءاستفاده شده است. نمونه شاخص، گزارش سال ۲۰۲۱ کمیسیون تجارت فدرال آمریکا بود که فاش کرد ارائهدهندگان اینترنت آمریکایی دادههای رمزنگارینشده وبگردی در سطح دامنه را زیر نظر میگرفتند و با استفاده از آن، پروفایلهای تبلیغاتی مبتنی بر مکان، ویژگیهای جمعیتشناختی و حتی گرایشهای سیاسی میساختند.
کلاینت هلوی رمزنگاریشده چگونه کار میکند
هر بار، یک دستدادن محافظتی

«کلاینت هلوی رمزنگاریشده» از نظر فنی جالب است، زیرا خود دستدادن TLS را که تقریباً در هر اتصالی به کار میرود رمزنگاری نمیکند. در عوض، ECH نسخه دومی از پیام دستدادن میسازد و تقریباً آن را همچون طعمه به کار میگیرد.
یک پیام رمزنگاریشده اطلاعات واقعی، مانند نام میزبان، را در خود دارد؛ در حالی که پیام دیگر با نامی عمومی و جایگزین آشکارا فرستاده میشود. سرور پس از دریافت، نسخه واقعی را باز میکند و روند را بهطور معمول ادامه میدهد، اما ارائهدهنده اینترنت شما فقط همان طعمه را میبیند.
در ادامه، روند کار را با کنار گذاشتن اصطلاحات فنی پیچیده، بهاختصار توضیح دادهام:
- دریافت کلید عمومی سرور: پیش از برقراری اتصال، کارخواه پیکربندی ECH را در DNS جستوجو میکند.
- ساختن دو ClientHello: نسخه واقعی (ClientHelloInner) مقصد واقعی شما را در بر دارد. یک نسخه فریبنده (ClientHelloOuter) در عوض نامی عمومی و جایگزین حمل میکند؛ معمولاً دامنه خود شرکت میزبانی، نه وبسایتی که به آن سر میزنید.
- رمزنگاری نسخه واقعی و پنهانکردن آن در نسخه جعلی: کارخواه ClientHelloInner را با آن کلید عمومی رمزنگاری میکند و متن رمز را در یک افزونه در ClientHelloOuter جای میدهد. تنها هلوی بیرونی آشکار میشود؛ بنابراین هر ناظری یک دستدادن عادی را میبیند که خطاب به نامی نادرست است.
- سرور میکوشد قفل آن را بگشاید: افزونه را با کلیدهای شناختهشدهاش میسنجد. اگر رمزگشایی موفق باشد، ClientHelloInner واقعی شما را بازیابی و به پسزمینهٔ درست میفرستد — ECH پذیرفته شده است. اگر رمزگشایی شکست بخورد یا سرور از ECH پشتیبانی نکند، ClientHello پوششی بهجای آن همچون یک اتصال عادی پردازش میشود. معمولاً پیکربندی بهروزشدهای نیز به کارخواه فرستاده میشود تا فرایند را دوباره امتحان کند.
- کارخواه بررسی میکند کدامیک بهکار رفته است: یک نشانهٔ تأیید کوچک که در پاسخ سرور پنهان شده، به کارخواه میگوید درخواست واقعیاش عبور کرده یا فقط با یک جاینگهدار ارتباط داشته است.
ECH از SNI محافظت میکند و حریم خصوصی شما را بیش از پیش بهبود میبخشد.
ECH یا کار میکند یا نه
کلید جادویی برای فعالسازی وجود ندارد؛ اما میتوانید آن را بررسی کنید

ویژگی ECH این است که در پسزمینه و بیصدا کار میکند و از حریم خصوصی شما پاسداری میکند. بنابراین کلید یا گزینهٔ مشخصی وجود ندارد که بتوانید دنبالش بگردید و با تغییر دادنش ECH را فعال کنید.
بخشی از دلیلش نیز این است که، همانطور که گفته شد، اکنون بیشتر مرورگرها و سیستمعاملهای بزرگ از گونهای از ECH پشتیبانی میکنند. برای نمونه، کروم ECH را در نسخهٔ ۱۱۷ (سپتامبر ۲۰۲۳) پیادهسازی کرد و فایرفاکس آن را در نسخهٔ ۱۱۸ (سپتامبر ۲۰۲۳) افزود. پس اگر از نسخهای از این مرورگرها پس از اواخر ۲۰۲۳ استفاده میکنید، همین حالا نیز محافظت شدهاید.
به همین ترتیب، با آغاز عرضهٔ پشتیبانی ECH برای اندروید ۱۷، هنگامی که دستگاهتان به تازهترین نسخه بهروزرسانی شود، از این تقویت اضافی حریم خصوصی نیز بهرهمند میشوید؛ قابلیتی که دادههایتان را اندکی بیشتر از دید ارائهدهندهٔ خدمات اینترنت پنهان میکند.
اطمینان از اینکه ECH واقعاً کاری انجام میدهد، از صرفِ اطمینان از فعال بودنش سودمندتر است؛ اما یک نکته دارد: باید آن را در سایتی آزمایش کنید که از ECH پشتیبانی میکند، وگرنه نتیجهٔ منفی کاذبی میگیرید که هیچ ارتباطی با تنظیمات شما ندارد. سادهترین آزمون، crypto.cloudflare.com/cdn-cgi/trace است: به آن سر بزنید و در پاسخ متنی ساده، خط sni= را پیدا کنید. اگر ECH در آن اتصال موفق بوده باشد، مقدار آن encrypted خواهد بود؛ بیآنکه نیازی به نصب چیزی یا کار دیگری باشد.
نکتهٔ پایانی این است که ECH فقط نام میزبان را پنهان میکند. جستوجوی DNS شما همچنان متنِ ساده است، مگر اینکه آن را رمزگذاری کنید؛ همچنین تا زمانی که برای جلوگیری از آن اقدام نکنید، مرورگرتان همچنان قابل انگشتنگاری است. مانند همهٔ جنبههای حریم خصوصی، اینجا هم با کیکی بزرگ و چندلایه روبهرو هستیم که همهٔ لایههایش باید با هم کار کنند تا شما را ایمن نگه دارند.
منبع: این مطلب ترجمه و بومیسازی مقالهای از MakeUseOf به قلم Gavin Phillips است. مشاهده مقاله اصلی