Một ứng dụng khách SOCKS5 bắt đầu bằng phiên bản 5, sau đó gửi phiên bản 1 trong quá trình xác thực mật khẩu. Đó không nhất thiết là hạ cấp hay proxy sai.

Lần trao đổi đầu tiên thương lượng phương thức xác thực SOCKS5. Khi chọn tên người dùng/mật khẩu, RFC 1929 định nghĩa một thương lượng con riêng có trường phiên bản là 0x01.

Yêu cầu xác thực đó gồm độ dài và byte cho tên người dùng và mật khẩu. Máy chủ trả về phiên bản của thương lượng con và một trạng thái. Chỉ sau khi xác thực thành công, ứng dụng khách mới gửi yêu cầu đích SOCKS5.

Hãy tách hai lần trao đổi khi đọc dấu vết hoặc triển khai ứng dụng khách. Lặp lại 0x05 ở mọi nơi vì dịch vụ có tên SOCKS5 sẽ tạo ra thông điệp xác thực sai.

Trạng thái mật khẩu thành công cũng không có nghĩa là đích được yêu cầu được cho phép. Phản hồi SOCKS tiếp theo vẫn có thể từ chối kết nối đó.

Cuối cùng, phương thức tên người dùng/mật khẩu này không mã hóa thông tin đăng nhập của nó. Byte phiên bản biểu thị định dạng thông điệp, không phải chế độ đăng nhập được mã hóa hay mạnh hơn.

Bài viết liên quan