Jak jeden proxy port může přijímat HTTP i SOCKS
Vysvětluje, jak záměrně smíšený posluchač může rozlišit HTTP a SOCKS, zatímco běžný jednoprotokolový posluchač to nedokáže.
Smíšený proxy posluchač může přijímat HTTP i SOCKS na jednom TCP portu, protože server zkoumá počáteční bajty protokolu. Číslo portu toto rozpoznání neprovádí.
Požadavek HTTP proxy začíná metodou HTTP, například GET nebo CONNECT. SOCKS pozdrav začíná binárními poli protokolu. Software navržený pro tyto vstupy může spojení předat příslušnému obslužnému programu.
Jde o výslovnou vlastnost implementace. Běžný HTTP posluchač Squid se nestane smíšeným jen proto, že se jeho port změní na 1080, a posluchač pouze pro SOCKS se HTTP z nastavení prohlížeče nenaučí.
TLS přidává další hranici: šifrované proxy spojení začíná TLS, nikoli viditelnou metodou HTTP. Podpora na stejném koncovém bodu vyžaduje další záměrné ošetření; rozpoznání prostého HTTP a SOCKS tuto schopnost neprokazuje.
Použijte klientský protokol zdokumentovaný pro daný koncový bod. Pokud fungují oba, je to důkaz o smíšeném posluchači daného serveru, ne důvod nechávat protokol v každém klientu neurčený.
Smíšený posluchač Glideru nabízí konkrétní příklad: nahlédne na jeden bajt, aniž by ho spotřeboval, předá 0x05 svému obslužnému programu SOCKS5, a jinak zavolá svůj HTTP parser. Ten parser stále ověřuje příchozí požadavek; volba předání nedělá z libovolného vstupu platné HTTP.
Sdílení TCP posluchače samo o sobě neposkytuje UDP asociaci SOCKS5. Glider spouští svůj UDP posluchač odděleně. Volba protokolu TCP a pozdější přenos datagramů jsou oddělené schopnosti.