Како еден прокси порт може да прима и HTTP и SOCKS
Објаснува како намерно мешан слушател може да разликува HTTP и SOCKS, додека обичен еднопротоколен слушател не може.
Мешан прокси слушател може да прима HTTP и SOCKS на еден TCP порт затоа што серверот ги прегледува почетните бајти на протоколот. Бројот на портата не го врши тоа препознавање.
Барањето до HTTP прокси започнува со HTTP метод, како GET или CONNECT. SOCKS поздравот започнува со бинарни протоколски полиња. Софтверот дизајниран за овие влезови може да ја пренасочи врската кон соодветниот обработувач.
Ова е изречна карактеристика на имплементацијата. Обичниот Squid HTTP слушател не станува мешан затоа што неговата порта е сменета на 1080, а слушателот само со SOCKS не учи HTTP од поставката на прелистувачот.
TLS додава уште една граница: шифрираната прокси врска започнува со TLS, а не со видлив HTTP метод. Нејзината поддршка на истата крајна точка бара дополнителна намерна обработка; препознавањето на отворен HTTP и SOCKS не ја докажува таа способност.
Користете го клиентскиот протокол документиран за крајната точка. Ако работат и двете, тоа е доказ за мешаниот слушател на тој сервер, а не причина протоколот да остане неодреден во секој клиент.
Мешаниот слушател на Glider дава конкретен пример: ѕирнува во еден бајт без да го троши, го праќа 0x05 до својот SOCKS5 обработувач, а инаку го повикува својот HTTP парсер. Тој парсер сè уште го валидира дојдовното барање; изборот на праќање не прави произволен влез валиден HTTP.
Споделувањето на TCP слушателот само по себе не обезбедува UDP асоцијација на SOCKS5. Glider го стартува својот UDP слушател одделно. Изборот на TCP протокол и подоцнежното препраќање на датаграми се одделни способности.