تشفير نفق WSS ينتهي عند مُنهي TLS، لا عند التطبيق

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

طبقتان تبدوان وكأنهما واحدة

WebSocket الآمن هو TLS يُجرى فوقه مصافحة WebSocket، كما يصف RFC 6455 في أقسام الاتصال والأمان. تصادق طبقة TLS على الخادم وتشفّر التدفق، ثم تؤطّر طبقة WebSocket ما يقرره التطبيق إرساله.

هذان قراران مستقلان، والرسم الذي يضع قفلًا واحدًا على المسار كله يخفي الثاني. اسأل من يُنهي اتصال TLS. ثم اسأل ماذا يضع العميل داخل كل رسالة. كل ما تبقى عن النشر يتبع من هذين الجوابين.

التصميم A: النقل هو التشفير الوحيد

في التصميم الأبسط، يأخذ العميل حزم IP خام ويغلفها في رسائل WebSocket. لا شيء في الداخل مشفّر، لذا يقرأ المكوّن الذي يحمل جلسة TLS حمولات نصية صريحة. وعندما يكون ذلك المكوّن خادم النفق الخاص بك، فهذه هي نقطة النهاية المقصودة والتصميم متماسك، لأن الخادم كان سيرى حركة المرور على أي حال.

يصبح الأمر ترتيبًا مختلفًا عندما يجلس وكيل تفتيش على المسار ويُنهي TLS بشهادة يثق بها العميل. يحمل ذلك الوكيل الآن النص الصريح نفسه الذي كان الخادم سيحمله، ولا يغيّر أي قدر من تأطير WebSocket ذلك. قرّر مخزن ثقة العميل هذه النتيجة قبل فتح النفق بوقت طويل، لأنه اختار قبول تلك الشهادة لذلك الاسم. ويرى الوكيل أيضًا المضيف المطلوب وحجم كل رسالة، وهذا يكفي لبصم نشاط كثير دون فك تشفير أي شيء آخر.

التصميم B: الحمولة تحمل مفاتيحها الخاصة

في التصميم الثاني، يشفّر العميل حزمه ويصادق عليها ببروتوكول VPN له هوية نظير وتبادل مفاتيح خاصان به، ثم يحمل النتيجة داخل رسائل WebSocket. إنهاء TLS الخارجي هنا يكشف نصًا مشفّرًا، لا حركة مرور. يمكن للوكيل رؤية أحجام الرسائل وتوقيتها، ولا شيء آخر في الحمولة. هذا تعرّض أصغر بكثير، وهو مع ذلك بيانات وصفية يجدر تسميتها في مراجعة بدلًا من التلويح بها بعيدًا.

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

ملصق VPN أو أيقونة عميل مألوفة أو صفحة تسويقية ليست دليلًا على وجود هذا التصميم. قراءة تنسيق الحمولة هي الدليل.

تتبّع أين يظهر النص الصريح فعليًا

يمنحك مخطط URL حقيقة واحدة، فاحصل على الباقي من الواجهات. نفّذ الفحوص أدناه بالترتيب، لأن كل واحد يضيّق التالي:

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

ابدأ بالاتصال الخارجي. جلسة TCP طويلة العمر إلى منفذ TLS هي ما يبدو عليه حامل WebSocket، وجلسة ثانية إلى مضيف غير ذي صلة تستحق التفسير قبل أن تنظر أعمق. ثم اعثر على واجهة النفق على العميل، لأن جهاز tun أو tap يخبرك بأن العميل يتعامل مع حزم IP بدلًا من توكيل تدفق تطبيق واحد.

الالتقاط على واجهة النفق يحسم عادةً مسألة الحمولة. رؤوس قابلة للقراءة هناك تعني أن الحزم الداخلية لم تُشفّر بشكل منفصل قط، بينما الحمولات عالية الإنتروبيا تعني أنها شُفّرت. أعد الالتقاط على الواجهة الخارجية وقارن الاثنين: إذا بدا كلاهما عشوائيًا، فالطبقة الداخلية تقوم بعمل لا تستطيع الخارجية إلغاءه.

راجع الثقة التي منحتها فعليًا

شهادة جذر مؤسسية مثبّتة هي حقيقة عن مخزن ثقة العميل، وليست بيانًا عما يسجّله أي وكيل أو يفتّشه. أثبت السياسة المنشورة ومسار الاتصال الحقيقي بدلًا من استنتاج السلوك من وجود سلطة شهادات.

على الأجهزة المُدارة، اسأل المسؤول أي مكوّن يُنهي TLS، وما إذا كان العميل يتحقق من شهادة مثبّتة أم من شهادة عامة، وما هو تنسيق الحمولة. هذه الأجوبة الثلاثة تنتج نتيجة يمكنك الدفاع عنها لاحقًا.

اكتب النتيجة كحدّ بدلًا من حكم. "ينتهي TLS عند وكيل التفتيش، والحمولة الداخلية مشفّرة بشكل منفصل بمفاتيح لا تحملها إلا نقاط النهاية" عبارة قابلة للفحص تصمد أمام تغيير البائع. أما "WebSockets آمنة" فلا.