مقایسه ECH و وی پی ان: جلوگیری از نشت نام دامنه و آی پی

طی دهه گذشته با انتقال گسترده ترافیک اینترنت از پروتکل متنی HTTP به اتصالات رمزگذاری شده HTTPS، امنیت ارتباطات دیجیتال به طور چشمگیری ارتقا یافت. استاندارد TLS 1.3 رمزنگاری بسیار قدرتمندی برای داده های کاربران فراهم می کند. با این حال، در لحظه آغاز هر ارتباط، یک نقص ساختاری مهم پابرجا مانده بود: بخش الحاقی مشخص کننده نام سرور یا SNI. این بخش در بسته اولیه ClientHello به صورت متن آشکار ارسال می شد و پیش از پایان دست دادن رمزنگاری، نام دقیق دامنه مقصد را فاش می کرد.

ارائه دهندگان خدمات اینترنت، مدیران فایروال های سازمانی و تحلیل گران ترافیک در شبکه های بی سیم از این داده های متنی برای ثبت تاریخچه وب گردی کاربران استفاده می کردند.

برای رفع این نقص، کارگروه مهندسی اینترنت یا IETF استاندارد پیام اولیه رمزگذاری شده (Encrypted Client Hello یا ECH) را معرفی کرد که جایگزین پیش نویس پیشین ESNI شد. با وجود پیشرفت های ECH در لایه کاربردی، یک باور نادرست شکل گرفته است مبنی بر این که وجود ECH نیاز به تونل های لایه شبکه را به کلی از بین می برد.

بررسی فنی نشان می دهد که رمزگذاری در لایه کاربرد، داده های جانبی مسیر شبکه را پنهان نمی کند و استفاده از تونل های لایه سوم هنوز برای تضمین محرمانگی کامل ضروری است.

مسیر تحول از SNI به ECH: ساختار کپسول های تودرتو

در شبکه های توزیع محتوا (CDN) و سرورهای میزبان اشتراکی، یک آدرس آی پی مشترک میزبان هزاران وب سایت متفاوت است. برای این که سرور بتواند گواهی دیجیتال X.509 مناسب را ارائه دهد، دستگاه کاربر باید نام دامنه مقصد را اعلام کند. استاندارد RFC 6066 بخش SNI را برای حل این نیاز معرفی کرد، اما آن را بدون رمزنگاری انتقال داد.

راهکار اولیه ESNI تنها بخش نام سرور را با استفاده از کلید عمومی منتشر شده در رکوردهای متنی دی ان اس رمزگذاری می کرد. این روش چند ایراد اساسی داشت: ۱. سایر بخش های بسته دست دادن اولیه مانند اطلاعات ALPN و نسخه های مورد پشتیبانی همچنان به صورت متن آشکار باقی می ماندند و امکان شناسایی اثر انگشت دستگاه را فراهم می کردند. ۲. فاقد قابلیت رازداری مستقیم و سازوکار چرخش پویای کلیدها بود. ۳. تجهیزات واسط شبکه می توانستند این بسته ها را به راحتی شناسایی کنند.

پروتکل Encrypted Client Hello با تقسیم پیام آغازین به دو بسته جداگانه، این ساختار را دگرگون کرد:

• بسته درونی (InnerClientHello): پیام واقعی شامل نام دامنه اصلی (private-forum.example)، تنظیمات حساس ALPN و الحاقات کامل که با الگوریتم رمزنگاری کلید عمومی ترکیبی (HPKE - RFC 9180) و توسط کلید سرور لبه رمزگذاری می شود.
• بسته بیرونی (OuterClientHello): یک پیام عمومی و متنی برای شروع اتصال با یک نام عمومی (public_name مانند cloudflare.com یا fastly.net) که بسته رمزنگاری شده درونی را درون بخش encrypted_client_hello حمل می کند.

دستگاه کاربر                                                    سرور لبه شبکه
    |                                                                |
    |--- OuterClientHello [public_name="cdn-edge.net",               |
    |                      encrypted_inner=(InnerClientHello)] ----->|
    |                                                                | [رمزگشایی با HPKE]
    |                                                                | [بررسی دامنه مقصد]
    |<-- تایید الحاقات، دریافت گواهی رمزگذاری شده، پایان ارتباط -------|

ناظر بیرونی تنها ارتباطی عادی با یک نام عمومی متعلق به شرکت زیرساخت را مشاهده می کند و مقصد نهایی درون داده های رمزنگاری شده پنهان می ماند.

چرا استفاده از ECH به تنهایی کافی نیست

اگرچه ECH بسته های بازرسی عمیق شبکه را که به دنبال نام متنی دامنه هستند متوقف می کند، اما تغییری در اصول مسیریابی بسته ها در لایه های زیرین شبکه ایجاد نمی کند. اتکای صرف به ECH سه مسیر اصلی افشای اطلاعات را باز می گذارد:

۱. آدرس آی پی مقصد و دسته بندی سرورها

هر بسته اطلاعاتی که در شبکه فیزیکی جابجا می شود باید آدرس آی پی مقصد را در لایه سوم داشته باشد تا روترها بتوانند آن را هدایت کنند. با وجود این که شبکه های CDN از آدرس های اشتراکی برای هزاران سایت استفاده می کنند، اما بسیاری از وب سایت ها و سرویس های سازمانی دارای آدرس های اختصاصی یا محدوده های مشخص هستند.

با تحلیل ترافیک شبکه (NetFlow/IPFIX)، ارائه دهنده اینترنت می تواند سرور میزبان را به سادگی مشخص کند. حتی در شبکه های اشتراکی، بررسی معکوس رکوردهای دی ان اس و سوابق گواهی ها مقصد کاربر را بدون نیاز به خواندن نام دامنه آشکار می سازد.

۲. وابستگی اولیه به داده های دی ان اس

مرورگر برای ساخت پیام درونی باید ابتدا کلیدهای رمزگذاری سرور (echconfig) را دریافت کند. این کلیدها از طریق رکوردهای HTTPS در سامانه دی ان اس (RFC 9460) توزیع می شوند.

چنانچه دستگاه از دی ان اس پیش فرض اپراتور روی پورت ۵۳ استفاده کند، درخواست نام دامنه مقصد پیش از شروع نشست به صورت متن آشکار ارسال می شود. حتی با فعال بودن پروتکل DoH، اپراتور آدرس سرور تحلیل گر را ثبت می کند و هنگام بروز اختلال در اتصال می تواند پیام های بازگشتی (retry_configs) را ثبت کند.

۳. تحلیل الگوی ترافیک و اندازه بسته ها

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

از آنجا که هر پایگاه اینترنتی ساختار فایل ها و اسکریپت های ویژه ای دارد، دنباله بسته ها اثر انگشت مشخصی بر جای می گذارد. پژوهش های صورت گرفته در زمینه شناسایی وب سایت ها نشان می دهد که حتی با فعال بودن ECH می توان با درصد دقت بالا مقاصد کاربران را از طریق الگوی ترافیک شناسایی کرد.

مقایسه ساختارها: رمزگذاری لایه کاربرد و تونل های لایه سه

جدول زیر ابعاد حفاظتی فناوری های گوناگون را نشان می دهد:

ضرورت جداسازی ترافیک در لایه سوم شبکه

رمزگذاری لایه انتقال (لایه ۴ و ۷) با این فرض عمل می کند که تجهیزات میانی شبکه تنها داده ها را منتقل می کنند. اما در تحلیل امنیت امروزی، اطلاعات جانبی مانند زمان برقراری ارتباط، آدرس ها و حجم بسته ها اهمیتی هم تراز با خود داده ها دارد.

فناوری ECH در لایه کاربرد مستقر است. این روش آدرس آی پی اصلی شما را تغییر نمی دهد و نمی تواند مانع از ثبت مقاصد ارتباطی شما توسط ارائه دهنده اینترنت شود.

برای دستیابی به حریم خصوصی واقعی، باید ارتباطات را با یک تونل لایه سوم از ساختار فیزیکی شبکه تفکیک کرد:

۱. استفاده از آدرس جایگزین: تمامی بسته های ارسالی درون کپسول جدیدی قرار می گیرند که مقصد آن فقط سرور واسط است. اپراتور اینترنت تنها یک جریان رمزگذاری شده یکپارچه را مشاهده می کند. ۲. حفظ یکپارچگی دی ان اس: استعلام رکوردهای HTTPS برای دریافت echconfig مستقیما در تحلیل گرهای اختصاصی بدون ثبت لاگ انجام می شود تا قبل از شروع نشست هیچ نشتی رخ ندهد. ۳. پوشش یکپارچه: حتی اگر سایتی از ECH پشتیبانی نکند و ارتباط با نام آشکار شکل بگیرد، آن داده درون تونل لایه سه پنهان شده و از دید نظارت محلی در امان می ماند.

ترکیب ECH و هسته RiceGuard در زیرساخت VPNRice

کارشناسان امنیت شبکه باید پروتکل ECH را نه به عنوان یک راهکار جداگانه، بلکه به عنوان حلقه مکمل در ساختار دفاع لایه به لایه در نظر بگیرند.

سامانه VPNRice ارتباطات کاربران را در دو لایه به هم پیوسته ایمن می سازد:

در لایه انتقال، پروتکل RiceGuard تمامی بسته ها را با رمزگذاری استاندارد ChaCha20-Poly1305 محافظت کرده و آنها را از طریق سرورهای پایدار عبور می دهد. اپراتور محلی امکان مشاهده آدرس های آی پی مقصد یا ردیابی درخواست های دی ان اس را ندارد.

همزمان درون این تونل ایمن، مرورگر دستگاه از نسخه TLS 1.3 همراه با ECH استفاده می کند. این هماهنگی مانع از آن می شود که حتی سرورهای لبه و شرکت های میزبانی مشترک بتوانند ارتباطات مختلف کاربر را به یکدیگر پیوند دهند. با تلفیق جداسازی ترافیک در لایه سه و رمزگذاری بسته های اولیه در لایه کاربرد، سیستم VPNRice محیطی امن در تمامی شبکه ها فراهم می کند. دریافت VPNRice.