Hogyan fogadhat egyetlen proxy port HTTP-t és SOCKS-t is
Elmagyarázza, hogyan tud egy szándékosan vegyes figyelő különbséget tenni HTTP és SOCKS között, míg egy hagyományos egyprotokollos figyelő nem.
Egy vegyes proxy figyelő egyetlen TCP porton fogadhat HTTP-t és SOCKS-t, mert a kiszolgáló megvizsgálja a protokoll kezdő bájtjait. A portszám nem végzi el ezt a felismerést.
Az HTTP proxy kérés egy HTTP metódussal kezdődik, például GET vagy CONNECT. A SOCKS üdvözlés bináris protokollmezőkkel kezdődik. Az ezekre a bemenetekre tervezett szoftver a kapcsolatot a megfelelő kezelőhöz tudja irányítani.
Ez egy kifejezett megvalósítási jellemző. Egy hagyományos Squid HTTP figyelő nem válik vegyessé attól, hogy a portját 1080-ra változtatják, és egy csak SOCKS figyelő nem tanul HTTP-t a böngésző beállításából.
A TLS további határt szab: a titkosított proxy kapcsolat TLS-sel kezdődik, nem látható HTTP metódussal. Ennek támogatása ugyanazon a végponton további szándékos kezelést igényel; a sima HTTP és a SOCKS felismerése nem bizonyítja ezt a képességet.
Használja a végponthoz dokumentált kliensprotokollt. Ha mindkettő működik, az bizonyíték az adott kiszolgáló vegyes figyelőjére, nem ok arra, hogy minden kliensben meghatározatlan maradjon a protokoll.
A Glider vegyes figyelője konkrét példát ad: anélkül pillant egy bájtra, hogy elfogyasztaná, a 0x05-öt a SOCKS5 kezelőjéhez küldi, egyébként pedig meghívja a HTTP elemzőjét. Az az elemző továbbra is érvényesíti a bejövő kérést; a továbbítás megválasztása nem tesz tetszőleges bemenetet érvényes HTTP-vé.
A TCP figyelő megosztása önmagában nem biztosít SOCKS5 UDP társítást. A Glider külön indítja a UDP figyelőjét. A TCP protokoll kiválasztása és a későbbi adatgram-továbbítás külön képességek.