زنجیرهٔ طولانی‌تر SOCKS گام بعدی را به‌طور خودکار پنهان نمی‌کند

زنجیره تغییر می‌دهد که هر اتصال را چه کسی باز می‌کند. صرف افزودن نشانی SOCKS دیگری به فهرست، رمزنگاری نمی‌افزاید.

کلاینتی را در نظر بگیرید که این زنجیره را خودش می‌سازد:

application → SOCKS A → SOCKS B → website

نخست از A می‌خواهد به B متصل شود. از طریق همان جریان می‌تواند سپس با B دربارهٔ اتصال به وبگاه مذاکره کند. اگر انتقال از کلاینت به A هر دو مذاکره را بدون رمزنگاری حمل کند، ناظری با توان کافی روی همان پیوند می‌تواند بایت‌های راه‌اندازی را که کلاینت فرستاده بخواند. مقصد بیرونی TCP تنها شاهد ممکن ناظر نیست.

زنجیره را از تبادل محافظت‌شدهٔ برنامه جدا کنید

HTTPS می‌تواند محتوای برنامهٔ وبگاه را پس از آغاز نشست TLS محافظت کند. اما پیام‌های راه‌اندازی SOCKS پیشین را به‌صورت گذشته‌نگر رمزنگاری نمی‌کند. احراز هویت نام کاربری/گذرواژهٔ SOCKS5 نیز انتقال رمزنگاری‌شده نیست.

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

مسیر والدِ تنظیم‌شده در سرور ساختار دیگری است. اگر A در درون خود B را انتخاب کند، لزوماً کلاینت فهرست کامل واسطه‌ها را روی نخستین اتصالش نفرستاده است. ادعا نکنید که هر زنجیره هر گام را به یک شکل افشا می‌کند.

برای ارزیابی سودمند حریم خصوصی، ناظر، پیوند، مذاکرهٔ پراکسی و مرزهای TLS را نام ببرید. وبگاهی که خروجی B را می‌بیند و ناظر شبکهٔ دسترسی که نخستین اتصال کلاینت را می‌پاید به پرسش‌های متفاوتی پاسخ می‌دهند. تنها شمردن گام‌ها به هیچ‌یک پاسخ نمی‌دهد.