Ako môže jeden proxy port prijímať HTTP aj SOCKS
Vysvetľuje, ako zámerne zmiešaný poslucháč môže rozlíšiť HTTP a SOCKS, kým bežný jednoprotokolový poslucháč to nedokáže.
Zmiešaný proxy poslucháč môže prijímať HTTP aj SOCKS na jednom TCP porte, pretože server skúma počiatočné bajty protokolu. Číslo portu toto rozpoznanie nevykonáva.
Požiadavka HTTP proxy sa začína metódou HTTP, napríklad GET alebo CONNECT. SOCKS pozdrav sa začína binárnymi poľami protokolu. Softvér navrhnutý pre tieto vstupy môže spojenie presmerovať na príslušný obslužný program.
Je to výslovná vlastnosť implementácie. Bežný HTTP poslucháč Squid sa nestane zmiešaným len preto, že sa jeho port zmení na 1080, a poslucháč iba s SOCKS sa HTTP z nastavenia prehliadača nenaučí.
TLS pridáva ďalšiu hranicu: šifrované proxy spojenie sa začína TLS, nie viditeľnou metódou HTTP. Podpora na tom istom koncovom bode si vyžaduje ďalšie zámerné zaobchádzanie; rozpoznanie otvoreného HTTP a SOCKS túto schopnosť nepreukazuje.
Použite klientsky protokol zdokumentovaný pre koncový bod. Ak fungujú oba, je to dôkaz o zmiešanom poslucháčovi daného servera, nie dôvod nechávať protokol v každom klientovi neurčený.
Zmiešaný poslucháč Glideru ponúka konkrétny príklad: nahliadne na jeden bajt bez toho, aby ho spotreboval, pošle 0x05 svojmu obslužnému programu SOCKS5 a inak zavolá svoj HTTP parser. Ten parser stále overuje prichádzajúcu požiadavku; voľba odoslania nerobí z ľubovoľného vstupu platné HTTP.
Zdieľanie TCP poslucháča samo o sebe neposkytuje UDP asociáciu SOCKS5. Glider spúšťa svoj UDP poslucháč oddelene. Voľba protokolu TCP a neskoršie prenášanie datagramov sú oddelené schopnosti.