Hoe één proxy-poort zowel HTTP als SOCKS kan accepteren
Legt uit hoe een bewust gemengde listener HTTP en SOCKS kan onderscheiden, terwijl een normale listener met één protocol dat niet kan.
Een gemengde proxy-listener kan HTTP en SOCKS op één TCP-poort accepteren omdat de server de eerste protocolbytes inspecteert. Het poortnummer voert die detectie niet uit.
Een HTTP-proxyverzoek begint met een HTTP-methode, zoals GET of CONNECT. Een SOCKS-groet begint met binaire protocolvelden. Software die voor deze invoer is ontworpen, kan de verbinding naar de juiste handler doorsturen.
Dit is een expliciete implementatie-eigenschap. Een normale Squid HTTP-listener wordt niet gemengd omdat zijn poort naar 1080 wordt gewijzigd, en een listener met alleen SOCKS leert geen HTTP uit een browserinstelling.
TLS voegt een andere grens toe: een versleutelde proxyverbinding begint met TLS, niet met een zichtbare HTTP-methode. Die op hetzelfde eindpunt ondersteunen vereist extra bewuste afhandeling; het herkennen van platte tekst HTTP en SOCKS bewijst die mogelijkheid niet.
Gebruik het clientprotocol dat voor het eindpunt is gedocumenteerd. Als beide werken, is dat bewijs over de gemengde listener van die server, geen reden om het protocol in elke client ongespecificeerd te laten.
De gemengde listener van Glider geeft een concreet voorbeeld: hij gluurt naar één byte zonder die te verbruiken, stuurt 0x05 naar zijn SOCKS5-handler en roept anders zijn HTTP-parser aan. Die parser valideert het inkomende verzoek nog steeds; de keuze van doorsturen maakt van willekeurige invoer geen geldige HTTP.
Het delen van de TCP-listener levert op zichzelf geen SOCKS5 UDP-associatie. Glider start zijn UDP-listener apart. De keuze van TCP-protocol en de latere datagram-doorsturing zijn afzonderlijke mogelijkheden.