يبدأ عميل SOCKS5 بالإصدار 5، ثم يرسل الإصدار 1 أثناء مصادقة كلمة المرور. هذا ليس بالضرورة تخفيضًا للإصدار أو وكيلًا خاطئًا.

يُتفاوض التبادل الأول على طريقة مصادقة SOCKS5. وعند اختيار اسم المستخدم وكلمة المرور، يحدد RFC 1929 تفاوضًا فرعيًا منفصلًا حقل إصداره 0x01.

يتضمن طلب المصادقة هذا أطوالًا وبايتات لاسم المستخدم وكلمة المرور. ويعيد الخادم إصدار التفاوض الفرعي وحالة. ولا يرسل العميل طلب وجهة SOCKS5 إلا بعد نجاح المصادقة.

أبقِ التبادلين منفصلين عند قراءة أثر شبكة أو تنفيذ عميل. وتكرار 0x05 في كل مكان لأن الخدمة تُسمى SOCKS5 ينتج رسالة مصادقة خاطئة.

كما أن حالة كلمة مرور ناجحة لا تعني أن الوجهة المطلوبة مسموح بها. فقد يرفض رد SOCKS التالي ذلك الاتصال.

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

مقالات ذات صلة