فحص SNI: كيف يرى الرقباء الموقع المقصود حتى مع HTTPS

تخيل أنك تُرسل رسالة في مظروف مختوم قوي لا يمكن فتحه إلا بمفتاح سري. لكن عنوان المستقبِل مكتوب على ظهر المظروف بوضوح — وأي شخص في مركز البريد يمكنه قراءته دون فتح الرسالة من الداخل. هذا هو الفرق بين تشفير محتوى الرسالة وتشفير المعلومات الوصفية عنها. هذا بالضبط ما يحدث عندما تزور موقعاً آمناً باستخدام HTTPS: المحتوى محمي، لكن اسم الموقع الذي تقصده قد يكون مرئياً للمراقبين.

كيف يحدث هذا؟ والأهم من ذلك — هل يمكن إصلاحه؟

لماذا HTTPS وحده لا يكفي

عندما تستخدم HTTPS، يحدث تفاوض معقد بينك وبين الخادم قبل أن يبدأ أي تشفير للبيانات. يُسمى هذا التفاوض بـ "TLS handshake" (مصافحة TLS). في هذه المرحلة الأولية — قبل أن يتم إنشاء القناة الآمنة — يحتاج جهاز الخادم إلى معرفة أي موقع تريد زيارته. لماذا؟ لأن الخادم الواحد قد يستضيف مئات أو آلاف المواقع المختلفة.

تخيل مبنى كبير يحتوي على آلاف المكاتب، لكن عنوان المبنى واحد فقط. عندما توصل رسالة إلى هذا العنوان، يجب أن تخبر أمين المبنى: "أريد أن أصل إلى المكتب رقم 47، وليس المكتب رقم 200." هذا هو دور SNI (Server Name Indication).

ما هي معلومات SNI

SNI هي ميزة تقنية تتيح لعدة مواقع الجلوس على نفس عنوان IP (رقم الهوية الرقمية للخادم). عندما ترسل SNI، تقول للخادم: "أنا أريد الاتصال بـ example.com وليس example.org" — حتى قبل بدء التشفير. المشكلة: هذه الرسالة غير مشفرة. أي شخص يراقب اتصالك بالإنترنت — سواء كان مزود الخدمة أو حكومة أو فاحص على شبكة محلية — يمكنه قراءة اسم الموقع الذي تقصده.

هذا يعني أن الرقيب قد لا يحتاج حتى إلى فتح المحتوى المشفر. يمكنه ببساطة قراءة اسم الموقع من معلومات SNI وقول: "هذا الموقع محظور" ثم قطع الاتصال. المحتوى نفسه يبقى سراً، لكن الوجهة معروفة.

لماذا كان هذا التصميم ضرورياً

قد تتساءل: لماذا لم يشفّر المهندسون معلومات SNI من البداية؟ السبب بسيط: الشروط التقنية لعصر التسعينيات والعقد الأول من القرن الحادي والعشرين. عندما تم تطوير هذا النظام، لم تكن هناك طريقة سهلة وفعالة لجعل الخادم يفك تشفير اسم الموقع قبل إنشاء قناة اتصال آمنة — كان هذا دورياً: تحتاج إلى معرفة الموقع لبدء التشفير، لكنك لا تستطيع تشفير معلومات الموقع قبل معرفته.

كان هناك أيضاً افتراض تاريخي: أن الأشخاص الذين يراقبون الإنترنت محصورون على مستوى محلي، وليسوا على المستوى الوطني. لكن هذا الافتراض تغيّر.

من يستخدم فحص SNI للحجب

عدة دول تستخدم SNI كأداة فحص رئيسية. الصين، روسيا، إيران، تركيا، والعديد من الدول الأخرى لديها أنظمة مراقبة تتفحص رسائل SNI وتحجب الاتصالات بناءً على أسماء المواقع. هذا أسهل وأرخص وأسرع من محاولة فك تشفير محتوى HTTPS نفسه. في الواقع، بعض أنظمة الحجب تفعل شيئاً بسيطاً جداً: عندما ترى معلومات SNI من موقع محظور، تقطع الاتصال فوراً.

الحلول الناشئة: ECH و ESNI

المجتمع التقني بدأ يأخذ هذه المشكلة على محمل الجد. يُطوّر حل يُسمى Encrypted Client Hello (ECH) — أو الاسم السابق، ESNI (Encrypted Server Name Indication). الفكرة: تشفير معلومات SNI نفسها باستخدام مفتاح عام يحصل عليه متصفحك من خادم DNS.

هذا يعني أن اسم الموقع الذي تقصده سيكون مشفراً بنفس الطريقة التي يشفّر بها محتوى الويب نفسه. الرقيب لن يستطيع رؤية أي شيء سوى "آه، هذا الشخص يستخدم HTTPS لشيء ما" دون معرفة ماهية هذا الشيء.

لكن هناك حاجز: أولاً، هذه التقنية حديثة وليست مدعومة في كل مكان بعد. ثانياً، بعض أنظمة الحجب تستطيع اكتشاف استخدام ECH نفسه وحجبه. ثالثاً، المتصفح يجب أن يتواصل مع خادم DNS أولاً للحصول على المفتاح العام — وهذا الاتصال قد يراقب أيضاً.

الخلاصة والخطوات التالية

SNI هي ثغرة حقيقية في نموذج الأمان، لكنها ليست "خطأ" بقدر ما هي "مقايضة تصميمية." الحلول موجودة أو قادمة — ECH يحسّن الوضع بشكل كبير — لكن لا يوجد حل سحري. كل حل له متطلباته الخاصة والقيود.

إذا كنت تريد فهماً أعمق، ابحث عن كيفية عمل DNS نفسه، وكيف يمكن مراقبة استعلامات DNS حتى لو استخدمت HTTPS (هذه مشكلة منفصلة لكن متعلقة)، وكيف تعمل VPNات والخوادم الوسيطة في إخفاء SNI بتغيير من يرى الاتصال من الأساس.