Kako jedan proxy port može primati i HTTP i SOCKS
Objašnjava kako namjerno mješoviti slušalac može razlikovati HTTP i SOCKS, dok običan jednoprotokolni slušalac to ne može.
Mješoviti proxy slušalac može primati HTTP i SOCKS na jednom TCP portu jer server pregleda početne bajtove protokola. Broj porta ne obavlja to prepoznavanje.
HTTP proxy zahtjev počinje HTTP metodom, kao što su GET ili CONNECT. SOCKS pozdrav počinje binarnim poljima protokola. Softver namijenjen tim ulazima može usmjeriti vezu na odgovarajući rukovalac.
To je izričita karakteristika implementacije. Običan Squid HTTP slušalac ne postaje mješovit zato što mu se port promijeni na 1080, a slušalac samo za SOCKS ne nauči HTTP iz postavke preglednika.
TLS dodaje još jednu granicu: šifrovana proxy veza počinje TLS-om, a ne vidljivom HTTP metodom. Podrška za to na istoj krajnjoj tački zahtijeva dodatno namjerno rukovanje; prepoznavanje običnog HTTP-a i SOCKS-a ne dokazuje tu sposobnost.
Koristite klijentski protokol dokumentovan za krajnju tačku. Ako oba rade, to je dokaz o mješovitom slušaocu tog servera, a ne razlog da protokol ostane neodređen u svakom klijentu.
Gliderov mješoviti slušalac daje konkretan primjer: zaviri u jedan bajt bez da ga troši, prosljeđuje 0x05 svom SOCKS5 rukovaocu, a inače poziva svoj HTTP parser. Taj parser i dalje provjerava dolazni zahtjev; izbor prosljeđivanja ne čini proizvoljan ulaz valjanim HTTP-om.
Dijeljenje TCP slušaoca samo po sebi ne pruža SOCKS5 UDP asocijaciju. Glider pokreće svoj UDP slušalac odvojeno. Odabir TCP protokola i kasniji prijenos datagrama su odvojene sposobnosti.