Bagaimana Satu Port Proxy Dapat Menerima HTTP dan SOCKS Sekaligus
Menjelaskan bagaimana listener yang sengaja dicampur dapat membedakan HTTP dan SOCKS, sedangkan listener satu protokol biasa tidak bisa.
Listener proxy campuran dapat menerima HTTP dan SOCKS pada satu port TCP karena server memeriksa byte protokol awal. Nomor port tidak melakukan pendeteksian itu.
Permintaan proxy HTTP dimulai dengan metode HTTP, seperti GET atau CONNECT. Salam SOCKS dimulai dengan bidang protokol biner. Perangkat lunak yang dirancang untuk masukan ini dapat meneruskan koneksi ke penangan yang sesuai.
Ini adalah fitur implementasi yang eksplisit. Listener HTTP Squid biasa tidak menjadi campuran karena portnya diubah ke 1080, dan listener khusus SOCKS tidak mempelajari HTTP dari pengaturan peramban.
TLS menambah batas lain: koneksi proxy terenkripsi dimulai dengan TLS, bukan metode HTTP yang terlihat. Mendukungnya pada endpoint yang sama memerlukan penanganan sengaja tambahan; mengenali HTTP teks biasa dan SOCKS tidak membuktikan kemampuan itu.
Gunakan protokol klien yang didokumentasikan untuk endpoint. Jika keduanya berfungsi, itu bukti tentang listener campuran server tersebut, bukan alasan membiarkan protokol tidak ditentukan di setiap klien.
Listener campuran Glider memberikan contoh konkret: ia mengintip satu byte tanpa mengonsumsinya, mengirim 0x05 ke penangan SOCKS5-nya, dan jika tidak, memanggil parser HTTP-nya. Parser itu tetap memvalidasi permintaan yang masuk; pilihan pengiriman tidak membuat masukan sembarangan menjadi HTTP yang valid.
Berbagi listener TCP tidak dengan sendirinya menyediakan asosiasi UDP SOCKS5. Glider memulai listener UDP-nya secara terpisah. Pemilihan protokol TCP dan relai datagram setelahnya adalah kemampuan yang terpisah.