लंबी SOCKS श्रृंखला अगले हॉप को अपने आप नहीं छिपाती
क्लाइंट द्वारा बनाई गई SOCKS श्रृंखला में बिना एन्क्रिप्शन वाले सेटअप संदेशों की पहचान करें, इससे पहले कि आप मान लें कि कोई अन्य हॉप गंतव्य का मेटाडेटा छिपा देता है।
श्रृंखला यह बदलती है कि हर कनेक्शन कौन खोलता है। केवल सूची में एक और SOCKS पता जोड़ने से एन्क्रिप्शन नहीं जुड़ता।
ऐसे क्लाइंट पर विचार करें जो यह श्रृंखला स्वयं बनाता है:
application → SOCKS A → SOCKS B → website
यह पहले A से B से जुड़ने को कहता है। उस स्ट्रीम के ज़रिए यह फिर B के साथ वेबसाइट से कनेक्शन पर बातचीत कर सकता है। यदि क्लाइंट से A तक का परिवहन दोनों बातचीतों को बिना एन्क्रिप्शन के ले जाता है, तो उस लिंक पर पर्याप्त सक्षम प्रेक्षक क्लाइंट द्वारा भेजे गए सेटअप बाइट पढ़ सकता है। बाहरी TCP गंतव्य प्रेक्षक का एकमात्र संभावित साक्ष्य नहीं है।
श्रृंखला को संरक्षित अनुप्रयोग विनिमय से अलग रखें
HTTPS वेबसाइट की अनुप्रयोग सामग्री की रक्षा कर सकता है, उसका TLS सत्र शुरू होने के बाद। यह पहले भेजे गए SOCKS सेटअप संदेशों को पीछे जाकर एन्क्रिप्ट नहीं करता। SOCKS5 का उपयोगकर्ता नाम/पासवर्ड प्रमाणन भी एन्क्रिप्टेड परिवहन नहीं है।
क्लाइंट और पहले हॉप के बीच एन्क्रिप्टेड व्यवस्था उस लिंक पर दृश्यता बदल देती है। इसमें अब भी एक संचालक और डिक्रिप्ट की गई स्ट्रीम रखने वाला दूसरा छोर होता है। श्रृंखला को ट्रेस न किया जा सके, यह दावा करने के बजाय उस विश्वास-सीमा का वर्णन करें।
सर्वर पर कॉन्फ़िगर किया गया पैरेंट रूट दूसरा टोपोलॉजी है। यदि A भीतर से B चुनता है, तो क्लाइंट ने अपने पहले कनेक्शन पर ज़रूरी नहीं कि मध्यस्थों की पूरी सूची भेजी हो। यह दावा न करें कि हर श्रृंखला हर हॉप को एक ही तरह उजागर करती है।
उपयोगी गोपनीयता मूल्यांकन के लिए प्रेक्षक, लिंक, प्रॉक्सी बातचीत और TLS सीमाओं को नाम दें। B के निकास को देखने वाली वेबसाइट और क्लाइंट के पहले कनेक्शन को देखने वाला एक्सेस-नेटवर्क प्रेक्षक अलग-अलग प्रश्नों का उत्तर देते हैं। केवल हॉप गिनना दोनों में से किसी का उत्तर नहीं देता।