Klien SOCKS5 dimulai dengan versi 5, lalu mengirim versi 1 selama autentikasi kata sandi. Itu belum tentu penurunan versi atau proxy yang salah.

Pertukaran pertama menegosiasikan metode autentikasi SOCKS5. Saat nama pengguna/kata sandi dipilih, RFC 1929 mendefinisikan subnegosiasi terpisah yang bidang versinya 0x01.

Permintaan autentikasi itu mencakup panjang dan byte untuk nama pengguna dan kata sandi. Server mengembalikan versi subnegosiasi dan status. Klien baru mengirim permintaan tujuan SOCKS5 setelah autentikasi berhasil.

Pisahkan kedua pertukaran saat membaca jejak atau mengimplementasikan klien. Mengulang 0x05 di mana-mana karena layanan disebut SOCKS5 menghasilkan pesan autentikasi yang salah.

Status kata sandi yang berhasil juga tidak berarti tujuan yang diminta diizinkan. Balasan SOCKS berikutnya masih dapat menolak koneksi itu.

Terakhir, metode nama pengguna/kata sandi ini tidak mengenkripsi kredensialnya. Bita versi menandai format pesan, bukan mode masuk yang terenkripsi atau lebih kuat.

Artikel terkait