Hoe een proxy-poort beide HTTP en SOCKS kan aanvaar
Verduidelik hoe 'n doelbewus gemengde luisteraar HTTP en SOCKS kan onderskei, terwyl 'n gewone eenprotokol-luisteraar dit nie kan nie.
'n Gemengde proxy-luisteraar kan HTTP en SOCKS op een TCP-poort aanvaar omdat die bediener die eerste protokolgrepe ondersoek. Die poortnommer doen nie daardie opsporing nie.
'n HTTP-proxyversoek begin met 'n HTTP-metode, soos GET of CONNECT. 'n SOCKS-groet begin met binêre protokolvelde. Sagteware wat vir hierdie insette ontwerp is, kan die verbinding na die toepaslike hanteerder stuur.
Dit is 'n eksplisiete implementeringskenmerk. 'n Gewone Squid HTTP-luisteraar word nie gemeng omdat sy poort na 1080 verander word nie, en 'n luisteraar wat net SOCKS doen, leer nie HTTP uit 'n blaaier se instelling nie.
TLS voeg nog 'n grens by: 'n geënkripteerde proxyverbinding begin met TLS, nie met 'n sigbare HTTP-metode nie. Om dit op dieselfde eindpunt te ondersteun, vereis bykomende doelbewuste hantering; die herkenning van gewone HTTP en SOCKS bewys nie daardie vermoë nie.
Gebruik die kliëntprotokol wat vir die eindpunt gedokumenteer is. As albei werk, is dit bewyse oor daardie bediener se gemengde luisteraar, nie 'n rede om die protokol in elke kliënt ongespesifiseer te laat nie.
Glider se gemengde luisteraar bied 'n konkrete voorbeeld: dit loer na een greep sonder om dit te verteer, stuur 0x05 na sy SOCKS5-hanteerder, en anders roep dit sy HTTP-ontleder op. Daardie ontleder valideer steeds die inkomende versoek; die keuse van versending maak nie arbitrêre insette geldige HTTP nie.
Die deel van die TCP-luisteraar verskaf nie self SOCKS5 UDP-assosiasie nie. Glider begin sy UDP-luisteraar afsonderlik. TCP-protokolkeuse en die latere datagram-aangee is afsonderlike vermoëns.