SOCKS5 प्रमाणीकरण विधियाँ (RFC 1929)

SOCKS5 (RFC 1928 में परिभाषित) किसी प्रमाणीकरण विधि का अनुमान नहीं लगाता है — यह बातचीत करता है। जैसे ही प्रॉक्सी के लिए TCP कनेक्शन खुलता है, क्लाइंट एक अभिवादन भेजता है जिसमें वह प्रमाणीकरण विधियाँ सूचीबद्ध करता है जिन्हें वह समर्थन करता है, और प्रॉक्सी एक का चयन करता है।

क्लाइंट का अभिवादन है: एक संस्करण बाइट (0x05), विधियों की संख्या, फिर उतने ही विधि पहचानकर्ता। सामान्य विधियाँ हैं 0x00 "कोई प्रमाणीकरण आवश्यक नहीं", 0x02 "उपयोगकर्ता नाम/पासवर्ड", और 0xFF "कोई स्वीकार्य विधियाँ नहीं"। सर्वर दो बाइट्स के साथ उत्तर देता है: संस्करण और एकल विधि जिसे उसने चुना। यदि यह 0x00 लौटाता है, तो आप तुरंत कनेक्ट करते हैं; यदि यह 0x02 लौटाता है, तो क्लाइंट को अब उपयोगकर्ता नाम/पासवर्ड उप-वार्ता चलानी होगी इससे पहले कि वह कोई कनेक्ट अनुरोध कर सके। यदि सर्वर 0xFF लौटाता है, तो प्रस्तुत की गई विधियों में से कोई भी स्वीकार्य नहीं थी और यह कनेक्शन बंद कर देता है। यही कारण है कि एक प्रमाणित s4m SOCKS5 प्रॉक्सी पोर्ट 1080 पर आपके क्लाइंट से विधि 0x02 की पेशकश करने की अपेक्षा करता है।

उपयोगकर्ता नाम/पासवर्ड विधि (0x02) को RFC 1929 में अलग से निर्दिष्ट किया गया है। यह एक छोटा, आत्म-निहित विनिमय है जो विधि वार्ता के बाद और SOCKS अनुरोध से पहले होता है:

• क्लाइंट भेजता है: एक उप-वार्ता संस्करण बाइट (0x01 — ध्यान दें कि यह प्रमाणीकरण संस्करण है, SOCKS संस्करण नहीं), एक बाइट उपयोगकर्ता नाम लंबाई, उपयोगकर्ता नाम, एक बाइट पासवर्ड लंबाई, और पासवर्ड।
• सर्वर दो बाइट्स के साथ उत्तर देता है: संस्करण (0x01) और एक स्थिति बाइट। 0x00 का अर्थ है सफलता; कुछ और का अर्थ है विफलता, और सर्वर कनेक्शन बंद कर देता है।

केवल सफलता स्थिति के बाद क्लाइंट वास्तविक SOCKS5 कनेक्ट अनुरोध में गंतव्य का नाम देता है। क्योंकि उपयोगकर्ता नाम और पासवर्ड दोनों लंबाई-पूर्वनिर्धारित एकल बाइट हैं, प्रत्येक 255 बाइट्स तक सीमित है। हमारे प्रॉक्सी प्रमाणीकरण गाइड को देखें कि यह वास्तविक क्लाइंट के साथ और API के लिए क्रेडेंशियल हैंडलिंग में कैसे काम करता है।

महत्वपूर्ण ईमानदार बिंदु: RFC 1929 उपयोगकर्ता नाम और पासवर्ड को सादा पाठ में भेजता है। बाइट्स को एन्क्रिप्ट या हैश नहीं किया गया है — कोई भी जो आपके और प्रॉक्सी के बीच TCP कनेक्शन को देख सकता है, आपके क्रेडेंशियल्स को पढ़ सकता है। RFC स्वयं इसे स्वीकार करता है और चेतावनी देता है कि यह विधि केवल तभी उपयुक्त है जब वह जोखिम स्वीकार्य हो।

इसका व्यावहारिक अर्थ: SOCKS5 उपयोगकर्ता नाम/पासवर्ड प्रमाणीकरण की सुरक्षा प्रॉक्सी के लिए मार्ग पर भरोसा करने या पूरे SOCKS कनेक्शन को कुछ एन्क्रिप्टेड में लपेटने पर निर्भर करती है। लोग जो उपाय करते हैं उनमें TLS या SSH के माध्यम से SOCKS5 को टनल करना, प्रॉक्सी को एक विश्वसनीय नेटवर्क पर चलाना, या क्रेडेंशियल्स के बजाय (या इसके अलावा) IP व्हाइटलिस्टिंग पर निर्भर रहना शामिल है — जिसे एक समर्पित IP व्यावहारिक बनाता है। अन्य SOCKS5 प्रमाणीकरण विधियाँ सिद्धांत में मौजूद हैं (उदाहरण के लिए RFC 1928 से GSS-API), लेकिन उपयोगकर्ता नाम/पासवर्ड अब तक सबसे व्यापक रूप से लागू किया गया है, इसलिए इसके सादा पाठ स्वभाव को समझना — और प्रॉक्सी क्रेडेंशियल के रूप में एक महत्वपूर्ण पासवर्ड का पुन: उपयोग न करना — महत्वपूर्ण है।