Jak jeden port proxy może przyjmować zarówno HTTP, jak i SOCKS
Wyjaśnia, jak celowo mieszany nasłuchiwacz może rozróżnić HTTP i SOCKS, podczas gdy zwykły nasłuchiwacz jednego protokołu nie potrafi tego zrobić.
Mieszany nasłuchiwacz proxy może przyjmować HTTP i SOCKS na jednym porcie TCP, ponieważ serwer sprawdza początkowe bajty protokołu. Numer portu nie wykonuje tego rozpoznania.
Żądanie proxy HTTP zaczyna się od metody HTTP, takiej jak GET lub CONNECT. Powitanie SOCKS zaczyna się od binarnych pól protokołu. Oprogramowanie zaprojektowane dla tych danych wejściowych może skierować połączenie do odpowiedniego modułu obsługi.
Jest to wyraźna cecha implementacji. Zwykły nasłuchiwacz HTTP Squid nie staje się mieszany dlatego, że jego port zostaje zmieniony na 1080, a nasłuchiwacz tylko SOCKS nie uczy się HTTP z ustawienia przeglądarki.
TLS dodaje kolejną granicę: zaszyfrowane połączenie proxy zaczyna się od TLS, a nie od widocznej metody HTTP. Obsługa go na tym samym punkcie końcowym wymaga dodatkowego celowego postępowania; rozpoznanie zwykłego HTTP i SOCKS nie dowodzi tej możliwości.
Użyj protokołu klienta udokumentowanego dla punktu końcowego. Jeśli oba działają, jest to dowód dotyczący mieszanego nasłuchiwacza tego serwera, a nie powód, by pozostawiać protokół nieokreślony w każdym kliencie.
Mieszany nasłuchiwacz Glidera daje konkretny przykład: zagląda do jednego bajtu bez jego zużywania, wysyła 0x05 do swojego modułu obsługi SOCKS5, a w przeciwnym razie wywołuje swój parser HTTP. Ten parser nadal sprawdza przychodzące żądanie; wybór wysyłki nie czyni dowolnego wejścia prawidłowym HTTP.
Współdzielenie nasłuchiwacza TCP samo w sobie nie zapewnia skojarzenia UDP SOCKS5. Glider uruchamia swój nasłuchiwacz UDP osobno. Wybór protokołu TCP i późniejsze przekazywanie datagramów to odrębne możliwości.