آموزش و مقالات شبکه، وب، سرور و اینترنت

آموزش‌های کلادفلر به‌زودی در این بخش قرار داده می‌شود.

Oblivious DNS over HTTPS (ODoH)؛ حریم خصوصی بیشتر در DNS

نوشته شده توسط

گیک شبکه

در

وقتی شما می‌خواید یه سایتی مثل cloudflare.com رو باز کنید، کامپیوتر شما که آدرس عددی یا همون IP اون سایت رو بلد نیست. پس یه سوال از یه سرور مخصوص به اسم DNS Resolver می‌پرسه. این سوال اینه: «هی، آدرس cloudflare.com چنده؟». اون سرور هم جواب میده و کامپیوتر شما با اون آدرس به سایت وصل میشه.

حالا مشکل کجاست؟ در حالت عادی و قدیمی، این سوال و جواب‌ها بدون هیچ رمزنگاری و به صورت متن ساده فرستاده میشن. یعنی هر کسی وسط راه شما و اون سرور DNS باشه (مثلا شرکت اینترنتی شما یا همون ISP) می‌تونه ببینه شما دارید آدرس چه سایتی رو می‌پرسید. این یعنی هم می‌فهمن شما کی هستی (چون IP شما رو دارن) و هم می‌فهمن دنبال چه سایتی می‌گردی. این قضیه یه حفره بزرگ حریم خصوصی به حساب میاد.

برای حل این مشکل، پروتکل‌هایی مثل DNS over HTTPS (DoH) و DNS over TLS (DoT) به وجود اومدن. کار اینا اینه که همون سوال و جواب‌ها رو رمزنگاری می‌کنن. اینجوری دیگه کسی وسط راه نمی‌تونه بفهمه شما چی می‌پرسید. خیلی هم عالیه و الان مرورگرهایی مثل فایرفاکس و سیستم‌عامل iOS ازش پشتیبانی می‌کنن.

اما هنوز یه مسئله‌ای هست. با اینکه سوال شما رمزنگاری شده، ولی بالاخره به دست اون سرور DNS Resolver (مثلا سرور 1.1.1.1 کلاودفلر) می‌رسه. اون سرور برای اینکه بهتون جواب بده، باید سوال شما رو باز کنه. پس اون سرور هم IP شما رو می‌بینه و هم سوال شما رو. یعنی یه نهاد واحد (همون شرکت صاحب DNS Resolver) هنوز می‌تونه بفهمه که یک IP مشخص، دنبال چه سایت‌هایی بوده. درسته که شرکت‌هایی مثل کلاودفلر سیاست‌های حفظ حریم خصوصی سفت و سختی دارن و میگن این اطلاعات رو نگه نمی‌دارن، ولی بعضی‌ها ترجیح میدن به جای اعتماد به سیاست‌نامه‌ها، یه راهکار فنی داشته باشن که این امکان رو از پایه بگیره.

ورود ODoH: راهکاری برای جدا کردن سوال از هویت

اینجاست که Oblivious DNS over HTTPS (ODoH) وارد میدون میشه. ODoH یه استاندارد جدیده که مهندس‌هایی از شرکت‌های کلاودفلر، اپل و فستلی (Cloudflare, Apple, and Fastly) روی اون کار کردن. ایده اصلیش خیلی ساده‌ست: جدا کردن آدرس IP شما از سوالی که می‌پرسید، طوری که هیچ نهاد واحدی نتونه هر دو رو با هم ببینه.

این پروتکل از اواخر سال ۲۰۲۰ توسط سرویس 1.1.1.1 کلاودفلر پشتیبانی میشه. حتی سرویس iCloud Private Relay اپل هم بر پایه ODoH کار می‌کنه و کلاودفلر یکی از شرکای اون‌هاست.

ODoH چطوری کار می‌کنه؟

برای اینکه ODoH کار کنه، دو تا بازیگر جدید بین شما (کلاینت) و اون سرور اصلی DNS (که بهش میگیم Resolver) اضافه میشن: یه پراکسی (Proxy) و یه هدف (Target).

بذارید نقش هر کدوم رو توضیح بدم:

  1. کلاینت (Client): این همون دستگاه شماست (کامپیوتر، موبایل). قبل از اینکه سوال DNS رو بفرسته، اون رو با استفاده از کلید عمومیِ «هدف» رمزنگاری می‌کنه.
  2. پراکسی (Proxy): کلاینت شما اون بسته رمزنگاری شده رو مستقیم برای سرور DNS نمی‌فرسته. اول می‌فرستدش برای پراکسی. پراکسی مثل یه واسطه عمل می‌کنه. بسته رو از شما می‌گیره و برای «هدف» می‌فرسته. نکته مهم اینه که پراکسی هیچ دیدی به محتوای بسته شما نداره، چون رمزنگاری شده. پس نمی‌تونه سوال شما رو بخونه یا تغییرش بده. پراکسی فقط IP شما رو می‌بینه.
  3. هدف (Target): این همون سروریه که قراره به سوال شما جواب بده. بسته رمزنگاری شده رو از پراکسی تحویل می‌گیره. چون کلید خصوصی رو داره، می‌تونه بسته رو باز کنه و سوال شما رو بخونه. اما نکته مهم اینه که «هدف» دیگه IP اصلی شما رو نمی‌بینه! فقط IP پراکسی رو می‌بینه. بعد از اینکه جواب رو پیدا کرد، جواب رو هم رمزنگاری می‌کنه و پس می‌فرسته برای پراکسی.
  4. بازگشت جواب: پراکسی جواب رمزنگاری شده رو می‌گیره و برای شما می‌فرسته. شما هم با کلیدی که دارید، جواب رو باز می‌کنید.

پس نتیجه چی میشه؟

  • پراکسی می‌دونه شما (IP شما) یه درخواستی داشتید، ولی نمی‌دونه درخواستتون چی بوده.
  • هدف می‌دونه یه درخواستی برای یه سایت مشخص اومده، ولی نمی‌دونه این درخواست از طرف کی بوده (فقط IP پراکسی رو می‌بینه).

تا زمانی که پراکسی و هدف با هم تبانی نکنن و اطلاعاتشون رو به هم ندن، هیچ‌کس به تنهایی نمی‌تونه هم به هویت شما (IP) و هم به سوال DNS شما دسترسی داشته باشه. این یعنی حریم خصوصی شما با یه تضمین فنی حفظ میشه.

نکته جالب اینه که کلاینت‌ها کنترل کامل روی انتخاب پراکسی و هدف دارن. یعنی شما می‌تونید هر پراکسی و هدفی که دوست دارید رو انتخاب کنید و هر وقت خواستید تغییرشون بدید.

رمزنگاری اضافه و کلیدها از کجا میان؟

شاید بپرسید مگه DoH خودش رمزنگاری HTTPS/TLS نداشت؟ پس این رمزنگاری اضافه برای چیه؟ سوال خوبیه. ببینید، ما اینجا دو تا اتصال TLS جدا داریم: یکی بین شما و پراکسی، و یکی بین پراکسی و هدف. اگه فقط به همون TLS اکتفا می‌کردیم، پراکسی وقتی بسته رو از شما می‌گرفت و می‌خواست برای هدف بفرسته، محتوای DNS شما براش مشخص میشد.

برای همین ODoH یه لایه رمزنگاری اضافه از نوع کلید عمومی هیبریدی (Hybrid Public Key Encryption – HPKE) روی خود پیام DNS می‌کشه. این رمزنگاری سرتاسری بین شما و «هدف» انجام میشه و پراکسی رو کاملا دور می‌زنه.

حالا سوال بعدی: شما کلید عمومیِ «هدف» رو از کجا پیدا می‌کنید؟ این کلید از طریق خود DNS به دست میاد. در یک رکورد خاص به اسم HTTPS resource record قرار می‌گیره و با استفاده از DNSSEC هم امنیتش تضمین میشه که کسی نتونه یه کلید جعلی به شما بده.

شرکای ODoH چه کسانی هستن؟

کلاودفلر برای راه‌اندازی این سرویس با چند تا شرکت پیشرو که به حریم خصوصی اهمیت میدن همکاری کرده. چون یکی از اجزای اصلی ODoH، پراکسیه، این شرکت‌ها به عنوان شرکای پراکسی فعالیت می‌کنن. بعضی از این شرکا عبارتند از: PCCW، SURF و Equinix.

بیانیه‌هایی هم از طرف این شرکت‌ها منتشر شده:

مایکل گلین از PCCW Global گفته: «ODoH یه مفهوم انقلابی جدیده که برای قرار دادن حریم خصوصی کاربر در مرکز همه چیز طراحی شده… این مدل برای اولین بار پراکسی کلاینت رو به طور کامل از رزولورها جدا می‌کنه».

جوست ون دایک از SURF گفته: «ما با کلاودفلر برای پیاده‌سازی حریم خصوصی بهتر کاربر از طریق ODoH همکاری می‌کنیم. حرکت به سمت ODoH یک تغییر پارادایم واقعیه، جایی که حریم خصوصی یا آدرس IP کاربر در معرض دید هیچ ارائه‌دهنده‌ای قرار نمی‌گیره و منجر به حریم خصوصی واقعی میشه».

آیا ODoH سرعت اینترنت رو کم می‌کنه؟

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

  • هزینه رمزنگاری اضافه: بررسی‌ها نشون داده که خود فرآیند رمزنگاری و رمزگشایی اضافه با HPKE خیلی ناچیزه. برای ۱۰ هزار دامنه مختلف این تست انجام شده و هزینه اضافه در صدک ۹۹ کمتر از ۱ میلی‌ثانیه بوده.
  • تاثیر کلی روی سرعت: برای اینکه تاثیر کلی رو بسنجن، اومدن زمان پاسخ به کوئری‌های DNS رو در سه حالت مقایسه کردن:
  1. DoH معمولی و مستقیم
  2. ODoH (با پراکسی)
  3. DoH روی شبکه Tor (به عنوان یه راهکار دیگه برای حفظ حریم خصوصی)

نتایج روی یه نمودار توزیع تجمعی نشون داده شد. اگه بخوایم ساده بگیم، نتایج این بود:

نوع اتصالزمان پاسخ در ۵۰٪ مواقع (میانه)
DoH معمولیکمتر از ۱۴۶ میلی‌ثانیه
ODoHکمتر از ۲۲۸ میلی‌ثانیه
DoH روی Torخیلی بیشتر (در نمودار مشخصه که کندتره)

این اعداد میگن که در نصف مواقع، استفاده از ODoH باعث یه تاخیر کمتر از ۱۰۰ میلی‌ثانیه نسبت به DoH معمولی میشه. در مقایسه با راهکارهای حفظ حریم خصوصی دیگه مثل Tor، سرعت ODoH خیلی بهتره و زمان پاسخ رو تقریبا نصف می‌کنه. این خیلی نکته مهمیه، چون معمولا بین حریم خصوصی و سرعت یه بده‌بستان وجود داره، ولی اینجا بهبود قابل توجهی دیده میشه.

یه نکته جالب دیگه توی این اندازه‌گیری‌ها این بود که انتخاب پراکسی و هدف با کمترین تاخیر (latency)، همیشه بهترین نتیجه رو نمیده. حتی در مواردی انتخاب پراکسی با کمترین تاخیر، عملکرد رو بدتر کرده! البته این اندازه‌گیری‌ها بیشتر در آمریکای شمالی انجام شده و باید دید در سطح جهانی عملکرد چطور خواهد بود.

نظرات و بحث‌های مختلف در مورد ODoH

مثل هر تکنولوژی جدید دیگه‌ای، در مورد ODoH هم بحث‌ها و نظرات متفاوتی وجود داره. بعضی از کاربرها و متخصص‌ها توی فروم‌ها و شبکه‌های اجتماعی مثل ردیت (Reddit) دیدگاه‌های جالبی مطرح کردن:

  • نگرانی در مورد اعتماد: یه عده میگن که قبلا باید به ISP خودمون اعتماد می‌کردیم، بعد با DoH باید به یه شرکت سوم مثل کلاودفلر یا گوگل اعتماد می‌کردیم، و حالا با ODoH باید هم به کلاودفلر (به عنوان هدف) و هم به یه شرکت پراکسی مثل PCCW یا Equinix اعتماد کنیم که با هم تبانی نمی‌کنن. سوال اصلی اینه که «چه کسی از نگهبانان، نگهبانی می‌کنه؟» و چطور می‌تونیم مطمئن باشیم این شرکت‌ها با هم همکاری نمی‌کنن. یه کاربری گفته: «فکر کنم بیشتر به Quad9 اعتماد دارم تا به کلاودفلر به اضافه یه پراکسی از شرکتی که اسمش رو هم نشنیدم».
  • مشاهده ترافیک توسط ISP: یه دیدگاه خیلی مهم دیگه اینه که حتی اگه شما از ODoH استفاده کنید و سوال DNS شما مخفی بمونه، ISP شما هنوز می‌تونه ببینه که شما به چه آدرس IP وصل میشید. یعنی بعد از اینکه آدرس سایت رو به صورت مخفیانه گرفتید، برای وصل شدن به اون سایت، باید یه درخواست به IP اون بفرستید. این درخواست دیگه مخفی نیست و ISP شما می‌تونه با دیدن IP مقصد بفهمه شما دارید به کدوم سایت سر می‌زنید. پس ODoH جلوی جمع‌آوری اطلاعات توسط وب‌سایت مقصد یا ISP رو به طور کامل نمی‌گیره.
  • راهکار جایگزین: بعضی‌ها معتقدن یه راهکار خصوصی‌تر اینه که کلا شرکت‌های سوم رو حذف کنیم و خودمون یه Recursive Resolver راه‌اندازی کنیم (مثلا با استفاده از نرم‌افزارهایی مثل Unbound یا BIND). اینطوری دیگه اطلاعات DNS ما دست هیچ شرکتی نمیفته.
  • آیا می‌تونم پراکسی خودم رو داشته باشم؟ یه سوال جالب این بود که «آیا می‌تونم پراکسی ODoH خودم رو راه‌اندازی کنم؟». جواب این بود که از نظر فنی بله، ولی اگه فقط شما از اون پراکسی استفاده کنید، هدف اصلی که مخفی شدن بین کلی کاربر دیگه هست از بین میره و باز هم قابل ردیابی میشید.
  • ODoH به عنوان یک استاندارد نوظهور: بعضی کاربرها هم از دیدن گزینه ODoH در تنظیمات روترهای جدید مثل Flint 2 خوشحال و متعجب شدن، چون ODoH هنوز یه استاندارد خیلی جدیده و هنوز به صورت گسترده پیاده‌سازی نشده.

چطور می‌تونیم ODoH رو امتحان کنیم؟

کلاودفلر کدهای مربوط به ODoH رو به صورت متن‌باز (Open Source) منتشر کرده. هم پیاده‌سازی سمت سرور و هم سمت کلاینت در زبان‌های برنامه‌نویسی راست (Rust) و گو (Go) موجوده. این یعنی هر کسی می‌تونه خودش یه سرویس ODoH راه‌اندازی کنه یا با کلاینت‌های موجود اون رو تست کنه.

سرور 1.1.1.1 کلاودفلر هم آماده دریافت کوئری‌های ODoH روی آدرس odoh.cloudflare-dns.com هست.

حتی می‌تونید با یه دستور ساده مثل dig مشخصات و کلید عمومی سرویس ODoH کلاودفلر رو ببینید:

dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com

علاوه بر این، ابزارهایی مثل dnscrypt-proxy هم از ODoH پشتیبانی می‌کنن و میشه از اون‌ها برای ارسال کوئری‌های ODoH استفاده کرد.

جزئیات فنی بیشتر برای کنجکاوها (بر اساس RFC 9230 و مستندات فنی)

اگه دوست دارید یه کم عمیق‌تر بشیم، بیاید به جزئیات فنی پروتکل نگاهی بندازیم. این بخش بر اساس سند رسمی RFC 9230 که ODoH رو تعریف می‌کنه و مستندات فنی دیگه هست.

ساختار پروتکل

  • سه بازیگر اصلی: همونطور که گفتیم، سه طرف داریم:
    • Oblivious Client: کلاینتی که کوئری‌ها رو به هدف می‌فرسته، اما از طریق یه پراکسی.
    • Oblivious Proxy: یه سرور HTTP که کوئری‌ها و جواب‌های رمزنگاری شده رو بین کلاینت و هدف رد و بدل می‌کنه.
    • Oblivious Target: یه سرور HTTP که کوئری‌های رمزنگاری شده رو از پراکسی می‌گیره، اون‌ها رو باز می‌کنه و جواب‌های رمزنگاری شده رو برمی‌گردونه.
  • تبادل HTTP:
    • درخواست (Request): کلاینت یه درخواست HTTP POST به آدرس پراکسی می‌فرسته. هدر Content-Type این درخواست باید application/oblivious-dns-message باشه. آدرس هدف هم توی URL درخواست به صورت متغیرهایی به اسم targethost و targetpath قرار می‌گیره.
    • پاسخ (Response): هدف هم جواب رو با همین Content-Type برای پراکسی می‌فرسته و پراکسی هم بدون تغییر اون رو به کلاینت تحویل میده.
  • قالب پیام‌ها:
    • پیام‌های ODoH (هم سوال و هم جواب) یه ساختار مشخص دارن. یه بخش اصلی به اسم dns_message دارن که خود پیام DNS توشه و یه بخش padding که برای سخت‌تر کردن تحلیل ترافیک استفاده میشه.
    • این پیام بعد از رمزنگاری داخل یه ساختار دیگه قرار می‌گیره که شامل message_type (نوع پیام: سوال یا جواب)، key_id (شناسه کلید استفاده شده) و خود encrypted_message (پیام رمزنگاری شده) هست.

پیکربندی و مدیریت کلیدها در سیستم‌های پیشرفته (مثل BIG-IP)

شرکت‌هایی مثل F5 که تجهیزات شبکه تولید می‌کنن، امکان پیکربندی ODoH رو روی دستگاه‌هاشون فراهم کردن. مراحل کلی این پیکربندی به این صورته:

  1. ساخت پروفایل HPKE: اول باید یه پروفایل برای رمزنگاری HPKE بسازید و الگوریتم‌های رمزنگاری (KEM, KDF, AEAD) رو مشخص کنید.
  2. ساخت کلید HPKE: بعد یه کلید بر اساس اون پروفایل ساخته میشه. این کلیدها می‌تونن به صورت خودکار در بازه‌های زمانی مشخص (مثلا هر ۳۰ روز) عوض بشن (Rollover).
  3. تعریف هدف ODoH: یه سرور مجازی به عنوان «هدف» تعریف میشه که به درخواست‌های ODoH گوش میده.
  4. پیکربندی Listener و Wide IP: در نهایت Listener ها و رکوردهای DNS مربوطه (مثل SVCB/HTTPS) تنظیم میشن تا کلاینت‌ها بتونن کلید عمومی هدف رو پیدا کنن و درخواست‌هاشون رو بفرستن.

این سیستم‌ها حتی پیام‌های خطا و لاگ‌های مشخصی برای ODoH دارن. مثلا اگه کلیدها با هم نخونن، خطای HTTP 401 برگردونده میشه یا اگه پیام قابل رمزگشایی نباشه، خطای 400 اتفاق میفته.

پرسش و پاسخ

حالا بریم سراغ چند تا سوال که ممکنه براتون پیش اومده باشه.

سوال ۱: پس ODoH همون DoH هست که فقط یه واسطه (پراکسی) بهش اضافه شده؟

نه دقیقا. علاوه بر اضافه شدن پراکسی، یه لایه رمزنگاری اضافه هم روی خود پیام DNS کشیده میشه (با استفاده از HPKE). این رمزنگاری اضافه خیلی مهمه، چون باعث میشه خود پراکسی هم نتونه محتوای درخواست شما رو ببینه. اگه این لایه اضافه نبود، پراکسی می‌تونست هم IP شما رو ببینه و هم درخواست شما رو، و کل هدف پروتکل از بین می‌رفت.

سوال ۲: اگه ISP من هنوز می‌تونه ببینه به چه IP وصل میشم، پس فایده ODoH چیه؟

این نکته خیلی مهمیه. ODoH از این جلوگیری می‌کنه که یک نهاد واحد (مثل یه شرکت ارائه دهنده DNS) بتونه یه پروفایل کامل از تاریخچه وب‌گردی شما بر اساس درخواست‌های DNS بسازه. درسته که ISP شما هنوز می‌بینه به چه IP هایی وصل میشید، ولی دیگه نمی‌تونه به راحتی و با نگاه کردن به لاگ‌های DNS، لیست تمام سایت‌هایی که شما حتی فقط اسمشون رو چک کردید (ولی شاید بهشون سر نزدید) رو در بیاره. ODoH یه لایه مهم به حریم خصوصی اضافه می‌کنه، ولی یه راهکار کامل برای ناشناس بودن در اینترنت نیست.

سوال ۳: آیا ODoH کند نیست؟

طبق اندازه‌گیری‌های اولیه، ODoH یه مقدار کمی تاخیر نسبت به DoH معمولی داره (حدود ۸۰ تا ۱۰۰ میلی‌ثانیه در نصف مواقع). ولی در مقایسه با راهکارهای حفظ حریم خصوصی دیگه مثل استفاده از شبکه Tor برای ارسال کوئری‌های DNS، خیلی سریع‌تره. پس یه بده‌بستان منطقی بین افزایش حریم خصوصی و یه مقدار کاهش سرعت وجود داره.

سوال ۴: من باید به کی اعتماد کنم؟ به ISP خودم یا به کلاودفلر و یه شرکت پراکسی که نمی‌شناسم؟

این دقیقا سوال اصلیه. ایده ODoH اینه که شما مجبور نباشید به یک نفر به طور کامل اعتماد کنید. شما دارید اعتمادتون رو بین دو نهاد مجزا (پراکسی و هدف) تقسیم می‌کنید. فرض پروتکل اینه که این دو با هم همکاری و تبانی نمی‌کنن. انتخاب اینکه این مدل برای شما بهتره یا اعتماد به یک نهاد مثل ISP یا حتی راه‌اندازی سرور شخصی، یه تصمیم شخصیه و به سطح نگرانی شما از حریم خصوصی بستگی داره.

سوال ۵: آیا من می‌تونم همین الان از ODoH استفاده کنم؟

بله. شما می‌تونید از نرم‌افزارهایی مثل dnscrypt-proxy استفاده کنید که از ODoH پشتیبانی می‌کنن. همچنین اگه از سرویس iCloud Private Relay اپل استفاده می‌کنید، شما در حال حاضر دارید از یه تکنولوژی مبتنی بر ODoH بهره می‌برید. با گذشت زمان، انتظار میره پشتیبانی از این پروتکل در سیستم‌عامل‌ها و مرورگرهای بیشتری به صورت پیش‌فرض فعال بشه.

منابع

  • [2] Oblivious DNS over HTTPS · Cloudflare 1.1.1.1 docs
  • [4] RFC 9230 – Oblivious DNS over HTTPS
  • [6] Oblivious DNS: Plugging the Internet’s Biggest Privacy Hole – CITP Blog
  • [8] Oblivious DoH : Enhanced DNS Privacy
  • [10] Oblivious HTTP (OHTTP) explained | Mozilla Support
  • [1] Improving DNS Privacy with Oblivious DoH in 1.1.1.1
  • [3] Configuring Oblivious DNS Over HTTP (ODoH) protocol
  • [5] Cloudflare and Apple design a new privacy-friendly DNS protocol – Oblivious DNS-over-HTTPS (ODoH) : r/pihole
  • [7] Oblivious DNS | Proceedings of the 2019 Applied Networking Research Workshop
  • [9] Oblivious DNS (ODoH) – does it work? – Routers / VPN, DNS, Leaks – GL.iNet

دیدگاه‌ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

نوشته‌های بیشتر