Bagaimana Satu Port Proksi Boleh Menerima HTTP dan SOCKS Serentak

Pendengar proksi bercampur boleh menerima HTTP dan SOCKS pada satu port TCP kerana pelayan memeriksa bait protokol awal. Nombor port tidak melakukan pengesanan itu.

Permintaan proksi HTTP bermula dengan kaedah HTTP, seperti GET atau CONNECT. Salam SOCKS bermula dengan medan protokol binari. Perisian yang direka untuk input ini boleh menghantar sambungan kepada pengendali yang sesuai.

Ini ialah ciri pelaksanaan yang eksplisit. Pendengar HTTP Squid biasa tidak menjadi bercampur kerana portnya ditukar kepada 1080, dan pendengar SOCKS sahaja tidak mempelajari HTTP daripada tetapan pelayar.

TLS menambah satu lagi sempadan: sambungan proksi yang disulitkan bermula dengan TLS, bukan kaedah HTTP yang kelihatan. Menyokongnya pada titik akhir yang sama memerlukan pengendalian sengaja tambahan; mengenali HTTP teks biasa dan SOCKS tidak membuktikan keupayaan itu.

Gunakan protokol klien yang didokumenkan untuk titik akhir. Jika kedua-duanya berfungsi, itu bukti tentang pendengar bercampur pelayan tersebut, bukan alasan untuk membiarkan protokol tidak dinyatakan dalam setiap klien.

Pendengar bercampur Glider memberikan contoh konkrit: ia mengintai satu bait tanpa memakannya, menghantar 0x05 kepada pengendali SOCKS5-nya, dan jika tidak, memanggil penghurai HTTP-nya. Penghurai itu masih mengesahkan permintaan yang masuk; pilihan penghantaran tidak menjadikan input sewenang-wenangnya sebagai HTTP yang sah.

Berkongsi pendengar TCP tidak dengan sendirinya menyediakan persatuan UDP SOCKS5. Glider memulakan pendengar UDP-nya secara berasingan. Pemilihan protokol TCP dan penghantaran semula datagram kemudian ialah keupayaan berasingan.