بررسی تخصصی: آیا پروتکل HTTPS شما را کاملاً ناشناس می‌کند؟

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

پیش از آنکه مرورگر شما بتواند هر چیزی را رمزنگاری کند، باید بداند ترافیک را به کجا بفرستد. این یعنی از یک DNS Resolver که معمولاً همان سروری است که ارائه‌دهنده اینترنت (ISP) از طریق DHCP در اختیارتان قرار داده می‌خواهد تا آدرسی مانند example.com را به یک آدرس IP تبدیل کند.

این پرسش به‌طور پیش‌فرض روی پورت ۵۳ با پروتکل UDP به صورت متن ساده (Plain Text) خارج می‌شود. هر کسی که بین دستگاه شما و تحلیل‌گر DNS روی خط قرار داشته باشد می‌تواند آن را بخواند. ارائه‌دهنده اینترنت شما قطعاً می‌تواند، چرا که خودش همان تحلیل‌گر است.

تحلیل خود سازمان IETF در سند RFC 7626 درباره این مشکل بسیار صریح است: تقریباً تمام ترافیک DNS به صورت رمزنگاری‌نشده ارسال می‌شود و بهترین نقطه برای استراق سمع، دقیقاً فاصله بین دستگاه شما و تحلیل‌گر DNS است.

بنابراین HTTPS یک مشکل خاص یعنی محتوای نشست شما را حل می‌کند، اما مشکل قدیمی‌تر را دست‌نخورده باقی می‌گذارد. این افشای متاداده (Metadata leak) یک باگ در TLS نیست؛ بلکه لایه‌ای است که TLS هرگز برای پوشش دادن آن طراحی نشده بود.

متاداده‌های افشا شده چه خطراتی دارند؟

اوضاع زمانی بدتر می‌شود که به محتوای واقعی لاگ‌های یک تحلیل‌گر DNS نگاه کنید:

• تک‌تک دامنه‌هایی که به آن‌ها سر زده‌اید.
• تمام همگام‌سازی‌های پس‌زمینه برنامه‌هایی که فراموش کرده‌اید نصب کرده‌اید.
• پیکسل‌های ردیابی (Tracker pixels) تعبیه‌شده در پیش‌نمایش ایمیل‌ها.
• دستگاه‌های هوشمند خانگی که به سرورهای خود متصل می‌شوند.

بنیاد مرزهای الکترونیکی (EFF) هشدار داده است که متاداده‌های رمزنگاری‌نشده‌ای از این دست، ماده خام لازم را برای ISPها فراهم می‌کنند تا پرونده‌های تفصیلی از کاربران خود بسازند. دامنه‌ها از نظر معنایی بسیار غنی‌تر از آدرس‌های IP هستند؛ اینکه کسی ببیند شما به آدرس IP 172.217.x.x متصل شده‌اید اطلاعات زیادی افشا نمی‌کند، اما اینکه ببیند شما ابتدا plannedparenthood.org و سپس aa.org و در نهایت ساعت ۲ بامداد یک سایت کاریابی را درخواست کرده‌اید، یک داستان کامل را روایت می‌کند!

[درخواست کاربر]
       │
       ├───> [پورت ۵۳ UDP - متن ساده] ───> استعلام DNS ────> افشای دامنه به ISP ⚠️
       │
       └───> [فرآیند TLS Handshake] ────> پیام SNI (متن ساده) ──> افشای نام میزبان ⚠️
                                                     │
                                                     └───> [مسیر رمزنگاری‌شده HTTPS] ──> محتوا امن است 🔒

مردم تصور می‌کنند استفاده از VPN این مشکل را حل می‌کند. گاهی اوقات این‌طور است، اما در بسیاری از مواقع فقط مشکل را منتقل می‌کند. اگر کلاینت VPN درخواست‌های DNS را به تحلیل‌گر خودِ تونل بفرستد، ISP از مدار خارج می‌شود، اما حالا ارائه‌دهنده VPN همه آن چیزهایی را که ISP می‌دید مشاهده می‌کند. علاوه بر این، بسیاری از تنظیمات دچار نشت DNS (DNS Leak) هستند که باعث می‌شود درخواست‌ها از بیرون تونل رد شوند.

راهکارهای فنی: DNS over HTTPS و تکنولوژی‌های نوظهور

حلی که صنعت فناوری به آن رسید، رمزنگاری خودِ DNS بود:

۱. پروتکل (DNS over HTTPS (DoH – طبق استاندارد RFC 8484 هر درخواست DNS را درون یک درخواست معمولی HTTPS به تحلیل‌گرهایی مانند Cloudflare (1.1.1.1) یا Google (8.8.8.8) می‌پیچد.

۲. پروتکل (DNS over TLS (DoT طبق استاندارد RFC 7858 همین کار را روی یک پورت اختصاصی انجام می‌دهد.

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

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

نوع نشت (Leak)	نحوه عملکرد	راهکار مقابله
Server Name Indication (SNI)	در ابتدای دست‌تکانی TLS، مرورگر نام دامنه‌ای را که گواهی آن را می‌خواهد به صورت علنی ارسال می‌کند.	استفاده از Encrypted Client Hello (ECH)
آدرس IP مقصد (Destination IP)	بسته‌ها باید مسیریابی شوند؛ بنابراین IP مقصد روی جلد تمام بسته‌های TLS مشخص است.	استفاده از شبکه‌های CDN یا شبکه Tor

تحقیقات نشان داده است که حتی ترافیک رمزنگاری‌شده DNS را می‌توان تنها با استفاده از الگوهای موجود در حجم بسته‌ها و زمان‌بندی آن‌ها اثرانگشت‌نگاری (Fingerprint) کرد تا وب‌سایت‌های بازدیدشده فاش شوند. رمزنگاری محتوا به معنای ناشناس بودن رفتار نیست.

چه کارهایی می‌توان انجام داد؟

چند اقدام عملی به ترتیب میزان تلاش لازم:

۱. فعال‌سازی DNS رمزنگاری‌شده: DoH یا DoT را در مرورگر یا سیستم‌عامل خود روشن کنید. سرویس‌دهندگانی مانند Cloudflare، Quad9 و NextDNS آدرس‌های مشخصی دارند.

۲. انتخاب تحلیل‌گر مطمئن: سرویسی را انتخاب کنید که به سیاست حریم خصوصی و عدم ثبت لاگ (No-log Policy) آن بیشتر از ISP خود اعتماد دارید.

۳. تست نشت VPN: اگر از VPN استفاده می‌کنید، حتماً آن را با ابزارهایی مانند dnsleaktest.com بررسی کنید.

۴. فعال‌سازی ECH: گزینه Encrypted Client Hello را در صورت وجود در مرورگر خود فعال کنید.

۵. استفاده از شبکه Tor: برای مواردی که واقعاً حساس هستند از Tor استفاده کنید، زیرا از اساس برای شکستن پیوند بین «هویت شما» و «مقصد شما» طراحی شده است.

جمع‌بندی

آیکون قفل در نوار آدرس دروغ نمی‌گوید؛ فقط به سوال کوچک‌تری نسبت به آنچه شما فکر می‌کردید پاسخ می‌دهد. HTTPS محتوا (Payload) را محافظت می‌کند، اما در اطراف این محتوا هالوژنی از متاداده‌ها (درخواست‌های DNS، SNI، آدرس‌های IP مقصد، زمان‌بندی و اندازه بسته‌ها) وجود دارد که نشان می‌دهد به کجا می‌روید، بدون اینکه بگوید در آنجا چه کرده‌اید.

بیشتر بخوانید:

چگونه در اینترنت ناشناس بمانیم؟
بهترین جایگزین های Tor برای مرور ناشناس
۷ افزونه امنیتی و حریم خصوصی کروم برای افزایش امنیت آنلاین