Як один проксі-порт може приймати і HTTP, і SOCKS
Пояснює, як навмисно змішаний слухач може розрізняти HTTP і SOCKS, тоді як звичайний однопротокольний слухач цього не може.
Змішаний проксі-слухач може приймати HTTP і SOCKS на одному TCP-порту, тому що сервер перевіряє перші байти протоколу. Номер порту не виконує цього визначення.
Запит HTTP-проксі починається з методу HTTP, наприклад GET або CONNECT. Привітання SOCKS починається з двійкових полів протоколу. Програмне забезпечення, розраховане на такі вхідні дані, може спрямувати з'єднання відповідному обробнику.
Це явна особливість реалізації. Звичайний HTTP-слухач Squid не стає змішаним через те, що його порт змінюють на 1080, а слухач лише з SOCKS не дізнається HTTP з налаштування браузера.
TLS додає ще одну межу: зашифроване проксі-з'єднання починається з TLS, а не з видимого методу HTTP. Його підтримка на тій самій кінцевій точці потребує додаткової навмисної обробки; розпізнавання відкритого HTTP і SOCKS не доводить цієї можливості.
Використовуйте клієнтський протокол, задокументований для кінцевої точки. Якщо працюють обидва, це свідчення про змішаний слухач того сервера, а не причина залишати протокол невизначеним у кожному клієнті.
Змішаний слухач Glider дає конкретний приклад: він заглядає в один байт, не споживаючи його, надсилає 0x05 своєму обробнику SOCKS5, а інакше викликає свій HTTP-парсер. Цей парсер і далі перевіряє вхідний запит; вибір надсилання не робить довільні дані допустимим HTTP.
Спільне використання TCP-слухача саме по собі не забезпечує UDP-асоціацію SOCKS5. Glider запускає свій UDP-слухач окремо. Вибір протоколу TCP і подальша передача дейтаграм — окремі можливості.