سلسلة SOCKS الأطول لا تخفي القفزة التالية تلقائيًا

السلسلة تغيّر من يفتح كل اتصال. وهي لا تضيف تشفيرًا بمجرد إضافة عنوان SOCKS آخر إلى قائمة.

لنأخذ عميلًا يبني هذه السلسلة بنفسه:

application → SOCKS A → SOCKS B → website

يطلب أولًا من A الاتصال بـ B. وعبر ذلك التدفق يستطيع أن يتفاوض مع B على اتصال بالموقع. وإذا كان النقل بين العميل وA يحمل التفاوضين دون تشفير، فإن مراقبًا قادرًا بما يكفي على ذلك الرابط يمكنه قراءة بايتات الإعداد التي أرسلها العميل. ووجهة TCP الخارجية ليست الدليل الوحيد الممكن لدى المراقب.

افصل السلسلة عن تبادل التطبيق المحمي

يستطيع HTTPS حماية محتوى تطبيق الموقع بعد بدء جلسة TLS. لكنه لا يشفّر بأثر رجعي رسائل إعداد SOCKS السابقة. كما أن مصادقة SOCKS5 باسم المستخدم وكلمة المرور ليست نقلًا مشفّرًا.

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

المسار الأب المُهيَّأ في الخادم بنية أخرى. فإذا اختار A المسار B داخليًا، فليس بالضرورة أن يكون العميل قد أرسل قائمة كاملة بالوسطاء عبر اتصاله الأول. لا تزعم أن كل سلسلة تكشف كل قفزة بالطريقة نفسها.

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