Kuidas üks puhverserveri port saab vastu võtta nii HTTP-d kui ka SOCKS-i
Selgitab, kuidas meelega segatud kuulaja suudab eristada HTTP-d ja SOCKS-i, samas kui tavaline ühe protokolli kuulaja seda ei suuda.
Segatud puhverserveri kuulaja saab ühel TCP-pordil vastu võtta HTTP-d ja SOCKS-i, sest server uurib protokolli algbaite. Pordinumber seda tuvastust ei tee.
HTTP-puhverserveri päring algab HTTP-meetodiga, näiteks GET või CONNECT. SOCKS-i tervitus algab binaarsete protokolliväljadega. Nende sisendite jaoks loodud tarkvara saab ühenduse suunata sobivale töötlejale.
See on selgesõnaline teostusomadus. Tavaline Squidi HTTP-kuulaja ei muutu segatuks, kui selle port muudetakse 1080-ks, ja ainult SOCKS-i kuulaja ei õpi HTTP-d brauseri seadest.
TLS lisab veel ühe piiri: krüpteeritud puhverserveri ühendus algab TLS-iga, mitte nähtava HTTP-meetodiga. Selle toetamine samas lõpp-punktis nõuab täiendavat meelega käsitlemist; lihtteksti HTTP ja SOCKS-i äratundmine ei tõesta seda võimet.
Kasutage lõpp-punkti jaoks dokumenteeritud kliendiprotokolli. Kui mõlemad töötavad, on see tõend selle serveri segatud kuulaja kohta, mitte põhjus jätta protokoll igas kliendis määramata.
Glideri segatud kuulaja annab konkreetse näite: see piilub ühte baiti ilma seda tarbimata, saadab 0x05 oma SOCKS5-töötlejale ja muidu kutsub oma HTTP-parseri. See parser valideerib endiselt sissetulevat päringut; saatmise valik ei muuda suvalist sisendit kehtivaks HTTP-ks.
TCP-kuulaja jagamine ei anna iseenesest SOCKS5 UDP-assotsiatsiooni. Glider käivitab oma UDP-kuulaja eraldi. TCP-protokolli valik ja hilisem datagrammide edastus on eraldi võimed.