HTTPS وDoH وECH وشبكة VPN تخفي أشياء مختلفة
كل آلية تزيل مراقبًا مختلفًا من المسار، ولا تزيل أي منها جميعهم. قارن ما هو محمي قبل إضافة نفق آخر.
إضافة VPN إلى متصفح يستخدم أصلًا HTTPS وDoH وECH لا تجمع ثلاث حمايات في واحدة؛ بل تغيّر من يكون في موقع يسمح له بمراقبة ماذا. كل آلية تزيل طرفًا مختلفًا من تبادل مختلف، وكل واحدة تترك شيئًا خلفها. السؤال المفيد ليس أيها الأقوى، بل أي مراقب تحاول إزالته، لأن الجواب يحدد ما إذا كان النفق مفيدًا أصلًا. مقارنة المراقبين المتبقين أنفع من قائمة مزايا.
أربع آليات، أربعة مراقبين
ابدأ بالعلاقات الأربع والطرف الذي صُممت كل واحدة لإبقائه خارجها. الجدول أدناه هو ما أستخدمه في المراجعة، لأنه يفرض على النقاش تسمية مراقب بدل تسمية تقنية.
| الآلية | العلاقة التي يحميها | المراقب الذي لا يزيله |
|---|---|---|
| HTTPS | اتصال TLS الخاص بالتطبيق بنقطته المسمّاة | شبكة الوصول ما زالت ترى عنوان الوجهة |
| DoH | تبادل DNS مع محلّل HTTPS المختار | ذلك المحلّل يرى كل استعلام |
| ECH | حقول ClientHello الحساسة، حيث يُدعم ويُقبل | عناوين الوجهة، وDNS إن لم يكن مغطى |
| VPN | الحزم المغطاة المنقولة إلى نظير VPN | مشغّل VPN يرى الوجهات |
قيمة الجدول فيما يرفض قوله. فهو لا يرتب الآليات، ولا يزعم أن استخدام الأربع جميعًا يزيل المراقبين الأربعة جميعًا. تطبيق ويب سحابي ينهي TLS عند حدوده الخاصة محمي من شبكة الوصول في ذلك التبادل، ولا نفق يحسّن تلك الخاصية بعينها. ما يمكن للنفق تغييره هو أي شبكة ترى الحزم الخارجية وأي مشغّل أصبح الآن على المسار.
ما يخفيه HTTPS فعلًا
يحمي HTTPS تبادل التطبيق بين العميل والنقطة التي تسميها الشهادة. وهو لا يخفي عنوان الوجهة، ولا يخفي أن اتصالًا حدث، ولا يخفي الاسم ما لم يكن ECH حاضرًا. التحقق من الشهادة جزء من الحماية، لا إجراء شكلي حولها.
لا يحتاج VPN إلى إنهاء ذلك TLS، ولا ينبغي معاملة مخرج التمرير كنقطة التطبيق الموثّقة. إذا كان التصميم يجعل المخرج يفك التشفير، فتلك بنية مختلفة ببيان ثقة مختلف.
ما تنقله DoH وECH، وما تتركه
تنقل DoH تبادل DNS إلى محلّل HTTPS، ما يعني أن ذلك المحلّل يرى استعلاماتك بدل محلّل الشبكة المحلية. هذا تغيير حقيقي ومحدود: يصبح المحلّل المختار طرفًا يمكنه ربط الاستعلامات بالعناوين التي تتصل بها بعد ذلك، وهو بالضبط الربط الذي يناقشه RFC 8484. النقل المشفّر لا يجعل المستلم غير مدرك للاستعلامات التي يجيب عنها.
يحمي ECH الجزء الحساس من ClientHello كي لا يستطيع مراقب سلبي على المسار قراءة اسم الخادم المقصود. وهو يعتمد على نشر داعم وعلى قبول من الخادم والشبكة، ويترك قنوات أخرى في مكانها: تبقى عناوين الوجهة مرئية، وقد لا يزال DNS يكشف الاسم.
الشيء الآخر الذي لا يفعله ECH هو إثبات نفسه. الاتصال الذي يستخدم TLS 1.3 ليس دليلًا على قبول ECH، والمتصفح الذي يعرض ECH على خادم لا يدعمه يتراجع بصمت. افحص الحالة الفعلية للاتصال بدل استنتاجها من إصدار البروتوكول.
هذا هو الشكل العام لهذه المقارنة كلها: كل آلية تُتحقق في طبقتها، ولا واحدة منها تُتحقق من نجاح أخرى.
ما ينقله VPN، وما يضيفه
عندما يدخل مرور الويب نفق VPN، ترى شبكة الوصول التبادل الخارجي مع نظير VPN بدل اتصالات التطبيق الفردية، ويتخذ مشغّل VPN موقعًا على المسار التالي. هذا نقل لحدود الثقة، لا إزالة لإحداها. يرى المشغّل الآن الوجهات التي تصل إليها، حتى لو بقي المحتوى مشفرًا من الطرف إلى الطرف. وكون ذلك تحسينًا يتوقف كليًا على أي من هذين الطرفين تثق به أقل.
أبقِ HTTPS الخاص بالتطبيق وحماية المحلّل المقصودة في مكانها أثناء ذلك. النفق ليس بديلًا عن التحقق من الشهادة، وإيقاف حمايات محلّل لأن المرور يمر عبر نفق يزيل ضابطًا دون أن يستبدله.
الاختيار انطلاقًا من المتطلب
اذكر المتطلب الفعلي، لأنه ما يحدد التصميم. الوصول إلى الموارد الخاصة، ونقطة خروج مُدارة، وتهديد معيّن في شبكة الوصول، وتفويض الأجهزة، أربع حاجات مختلفة بأربعة أجوبة مختلفة، والشركة التي تستخدم تطبيقات سحابة عامة فقط ما زالت مضطرة إلى تقرير التفويض والتعامل مع البيانات. يمكن أن تكون الطبقات الإضافية مناسبة دون أن تكون قابلة للتبادل. الاتصال الأكثر تعقيدًا ليس قياسًا لإخفاء الهوية، وليس حجة أمنية بحد ذاته.
مواصفة ECH، RFC 9849، تستحق القراءة لما تغطيه الآلية وما لا تغطيه، وهي صادقة بشأن القنوات التي تتركها وحدها. قارن الآليات بالمراقب الذي تزيله كل واحدة، واكتب ذلك المراقب، ثم قرر ما إذا كانت الطبقة الإضافية تعالجه. إذا كان الجواب أن المراقب كان أصلًا خارج نموذج تهديدك، فالنفق كلفة بلا فائدة.