Kako lahko ena proxy vrata sprejmejo hkrati HTTP in SOCKS
Pojasnjuje, kako lahko namerno mešani poslušalec loči HTTP od SOCKS, medtem ko običajen enoprotokolni poslušalec tega ne zmore.
Mešani proxy poslušalec lahko sprejema HTTP in SOCKS na enih vratih TCP, ker strežnik pregleda začetne bajte protokola. Številka vrat tega prepoznavanja ne izvede.
Zahteva proxy HTTP se začne z metodo HTTP, na primer GET ali CONNECT. Pozdrav SOCKS se začne z binarnimi polji protokola. Programska oprema, zasnovana za te vhode, lahko poveže povezavo z ustreznim upravljalnikom.
To je izrecna značilnost izvedbe. Običajen poslušalec HTTP Squid ne postane mešan zato, ker se njegova vrata spremenijo na 1080, in poslušalec samo za SOCKS se HTTP iz nastavitve brskalnika ne nauči.
TLS doda še eno mejo: šifrirana proxy povezava se začne s TLS, ne z vidno metodo HTTP. Podpora zanjo na isti končni točki zahteva dodatno namerno obravnavo; prepoznavanje navadnega HTTP in SOCKS te zmožnosti ne dokazuje.
Uporabite odjemalski protokol, dokumentiran za končno točko. Če delujeta oba, je to dokaz o mešanem poslušalcu tega strežnika, ne pa razlog, da bi protokol v vsakem odjemalcu pustili nedoločen.
Mešani poslušalec Gliderja ponuja konkreten primer: pokuka na en bajt, ne da bi ga porabil, pošlje 0x05 svojemu upravljalniku SOCKS5, sicer pa pokliče svoj razčlenjevalnik HTTP. Ta razčlenjevalnik še vedno preverja dohodno zahtevo; izbira pošiljanja ne naredi poljubnega vhoda veljavnega HTTP.
Deljenje poslušalca TCP samo po sebi ne zagotavlja pridružitve UDP pri SOCKS5. Glider zažene svoj poslušalec UDP ločeno. Izbira protokola TCP in poznejše posredovanje podatkovnih gramov sta ločeni zmožnosti.