یک کلاینت SOCKS5 با نسخه 5 آغاز می‌شود، سپس در هنگام احراز هویت رمز عبور نسخه 1 را می‌فرستد. این لزوماً یک تنزل یا پروکسی اشتباه نیست.

اولین تبادل، روش احراز هویت SOCKS5 را مذاکره می‌کند. وقتی نام کاربری/رمز عبور انتخاب می‌شود، RFC 1929 یک مذاکره فرعی جداگانه تعریف می‌کند که فیلد نسخه آن 0x01 است.

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

هنگام خواندن یک ردپا یا پیاده‌سازی یک کلاینت، دو تبادل را جدا نگه دارید. تکرار 0x05 در همه‌جا به این دلیل که سرویس SOCKS5 نام دارد، پیام احراز هویت نادرست تولید می‌کند.

وضعیت موفق رمز عبور نیز به معنای مجاز بودن مقصد درخواستی نیست. پاسخ SOCKS بعدی باز هم می‌تواند آن اتصال را رد کند.

در پایان، این روش نام کاربری/رمز عبور اعتبارنامه‌های خود را رمزگذاری نمی‌کند. بایت نسخه یک قالب پیام را مشخص می‌کند، نه یک حالت ورود رمزگذاری‌شده یا قوی‌تر.

مقالات مرتبط