Preberite osem bajtov, nato predajte tunel SOCKS4
Izognite se požiranju pozdrava cilja ali čakanju na neobstoječe bajte z analizo fiksne meje odgovora SOCKS4.
Zahteva za povezavo SOCKS4 uspe, vendar aplikacija nikoli ne vidi uvodnega pozdrava strežnika. Eno od mest za pregled je prvo branje konektorja. Branje šestnajstih bajtov je za osembajtni odgovor SOCKS4 preveliko.
| Polje odgovora | Bajti |
|---|---|
| Polje različice odgovora | 1 |
| Koda rezultata | 1 |
| Polje vrat | 2 |
| Polje naslova | 4 |
Koda rezultata 0x5a kaže, da je bila zahteva odobrena. SOCKS4a spremeni, kako zahteva nosi ime gostitelja; odgovora ne spremeni v šestnajst bajtov.
Po odgovoru isti tok TCP nosi protokol cilja. Poštni strežnik lahko svoj pozdrav pošlje takoj. Branje, ki porabi šestnajst razpoložljivih bajtov, lahko zato vzame celoten odgovor proxyja in prvih osem bajtov tega pozdrava. Če še nič ne sledi, lahko preveliko blokirajoče branje namesto tega doda nepotrebno čakanje.
Natančna dolžina je odgovornost razčlenjevalnika
Enkratno zahtevanje osmih bajtov ni zadosten dokaz, da je prispelo osem bajtov. Branja toka lahko vrnejo manj. Zberite natanko dolžino odgovora v roku, ustavite se pri zaprtem ali neuspelem toku, pregledajte odgovor in naslednje bajte prepustite aplikaciji.
Če konektor uporablja večje medpomnilniško branje, ohranite vse za mejo in predajte naslednjemu porabniku. Zavrženje presežka je enaka izguba podatkov z drugo velikostjo branja.
SOCKS5 potrebuje svoj razčlenjevalnik. Dolžina naslova njegovega odgovora se lahko razlikuje glede na vrsto naslova. Zamenjava vsakega branja proxyja s fiksnim branjem osmih bajtov bi popravila en protokol, a pokvarila drugega.