مقایسه ODoH و وی پی ان: مرزهای امنیت دی ان اس دو مرحله ای

با گسترش استانداردهای رمزگذاری نام دامنه نظیر DNS-over-HTTPS (یا DoH استاندارد RFC 8484) و DNS-over-TLS (یا DoT استاندارد RFC 7858)، امنیت ارتباط میان دستگاه کاربر و سرورهای تحلیل گر نام ارتقا یافت. این پروتکل ها توانستند مانع از شنود بسته های متنی پورت ۵۳ توسط ارائه دهندگان اینترنت و حاضرین در شبکه های وای فای عمومی شوند.

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

برای شکستن این تمرکز اطلاعاتی، کارگروه مهندسی اینترنت یا IETF پروتکل Oblivious DNS over HTTPS (یا ODoH استاندارد RFC 9230) و استاندارد OHTTP (یا RFC 9458) را طراحی و استانداردسازی کرد. اگرچه ODoH موفق به تفکیک ریاضیاتی آدرس کاربر از محتوای درخواست شد، اما برخی کاربران به اشتباه تصور می کنند که ODoH می تواند نیاز به تونل های لایه سوم شبکه را برطرف سازد.

بررسی فنی نشان می دهد که معماری دو مرحله ای ODoH مسئله حریم خصوصی را فقط در لایه سرورهای تحلیل گر حل می کند، در حالی که بدون تونل شبکه، کل ترافیک اصلی دستگاه همچنان در معرض رصد باقی می ماند.

ساختار فنی Oblivious DoH: تفکیک هویت از محتوای پیام

اصل بنیادین در پروتکل Oblivious DoH این است: هیچ نهادی نباید همزمان از هویت کاربر و نام دامنه درخواستی آگاه باشد.

برای جداسازی ارتباط میان آدرس آی پی و نام دامنه، استاندارد RFC 9230 مدلی سه بخشی شامل دستگاه کاربر (Client)، سرور واسط (Relay) و سرور تحلیل گر مقصد (Target) را پیاده سازی می کند:

[ دستگاه کاربر ]
        |
        | ۱. ارسال درخواست رمزنگاری شده با HPKE
        v
[ سرور واسط ODoH Relay ] (آدرس آی پی کاربر را می بیند، محتوا را نمی تواند بخواند)
        |
        | ۲. حذف آی پی کاربر و ارسال بسته به سرور مقصد
        v
[ سرور مقصد ODoH Target ] (محتوا را رمزگشایی می کند، نام سایت را می بیند، آی پی را نمی بیند)
        |
        | ۳. تبدیل نام به آی پی، رمزنگاری پاسخ با کلید نشست
        +-----> بازگشت به Relay -----> ارسال نهایی به دستگاه کاربر

۱. رمزنگاری ترکیبی با کلید عمومی (HPKE)

پیش از ارسال درخواست، دستگاه کاربر کلید عمومی سرور مقصد (odohconfig) را از مسیرهای معتبر امنیتی دریافت می کند.

دستگاه کاربر با بهره گیری از استاندارد HPKE (یا RFC 9180)، داده های باینری پرس و جو را درون یک کلید متقارن موقت رمزگذاری می کند. سپس این بسته مهر و موم شده به سرور واسط یا Relay فرستاده می شود.

۲. عملکرد سرور واسط بدون دسترسی به محتوا (Relay)

سرور Relay بسته رمزگذاری شده را از طریق یک نشست استاندارد HTTPS دریافت می کند. از آنجا که Relay کلید خصوصی سرور مقصد را در اختیار ندارد، از نظر فنی امکان خواندن محتوای بسته را نخواهد داشت.

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

۳. پردازش در سرور مقصد (Target)

سرور مقصد بسته را دریافت می کند در حالی که فرستنده آن سرور Relay ثبت شده است و شناسه ای از کاربر اولیه وجود ندارد.

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

با این روش، سرور واسط می داند شما چه کسی هستید اما نمی داند به دنبال چه سایتی می گردید؛ و سرور مقصد می داند چه سایتی مورد تقاضاست اما نمی داند تقاضا دهنده چه کسی است.

محدودیت های ساختاری پروتکل Oblivious DoH

با وجود نبوغ فنی در پیاده سازی ODoH برای تفکیک پرس و جوهای دی ان اس، بررسی زنجیره ارتباطی کلی نشان دهنده چند ضعف ساختاری است:

۱. افشای آی پی در ترافیک اصلی وب

تحلیل نام دامنه تنها گام مقدماتی است. به محض این که سیستم عامل آدرس عددی سرور وب را دریافت کند، ارتباط مستقیم شبکه ای بر پایه TCP یا QUIC با سرور سایت آغاز می شود.

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

فناوری ODoH مانع از ثبت عادات وب گردی شما توسط شرکت های تحلیل گر دی ان اس می شود، اما سایت مقصد و اپراتور اینترنت همچنان تمام ترافیک انتقالی شما را مشاهده می کنند.

۲. ریسک تبانی میان سرورهای واسط و مقصد

امنیت در استاندارد RFC 9230 مشروط به این است که مدیران سرور Relay و سرور Target هیچ گونه هماهنگی یا تبانی با یکدیگر نداشته باشند.

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

۳. افزایش تاخیر و اختلال در مکان یابی شبکه ای

عبور دادن بسته های دی ان اس از دو سرور مستقل زمان رفت و برگشت (RTT) را افزایش می دهد. یک ارتباط معمول DoH با یک مرحله انجام می شود در حالی که ODoH نیازمند طی دو مسیر مستقل در شبکه است.

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

مقایسه جامع: پروتکل های دی ان اس و تونل های لایه سه

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

ضرورت محافظت در لایه سوم شبکه

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

یک شبکه خصوصی مجازی در لایه سوم این چالش را در ریشه شبکه برطرف می کند:

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

پیاده سازی امنیت در زیرساخت شبکه ای VPNRice

طراحی شبکه پایدار ایجاب می کند که دستاوردهای پروتکل های نوین با محافظت کامل در لایه های زیرین پیوند بخورند.

ساختار سیستماتیک VPNRice ایمنی ارتباطات را در تمام بخش ها تامین می کند:

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

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