Hvordan én proxy-port kan godta både HTTP og SOCKS
Forklarer hvordan en bevisst blandet lytter kan skille HTTP og SOCKS, mens en vanlig lytter for én protokoll ikke kan.
En blandet proxy-lytter kan godta HTTP og SOCKS på én TCP-port fordi serveren inspiserer de innledende protokollbyttene. Portnummeret utfører ikke den gjenkjenningen.
En HTTP-proxyforespørsel begynner med en HTTP-metode, for eksempel GET eller CONNECT. En SOCKS-hilsen begynner med binære protokollfelt. Programvare utformet for disse inngangene kan sende tilkoblingen videre til riktig behandler.
Dette er en eksplisitt implementasjonsfunksjon. En vanlig Squid HTTP-lytter blir ikke blandet fordi porten endres til 1080, og en lytter som bare kan SOCKS, lærer ikke HTTP av en nettleserinnstilling.
TLS legger til en annen grense: en kryptert proxy-tilkobling begynner med TLS, ikke med en synlig HTTP-metode. Å støtte det på samme endepunkt krever ekstra bevisst håndtering; å gjenkjenne klartekst-HTTP og SOCKS fastslår ikke den egenskapen.
Bruk klientprotokollen som er dokumentert for endepunktet. Hvis begge virker, er det et bevis om den blandede lytteren til den serveren, ikke en grunn til å la protokollen være uspesifisert i hver klient.
Den blandede lytteren til Glider gir et konkret eksempel: den titter på én byte uten å bruke den, sender 0x05 til sin SOCKS5-behandler og kaller ellers HTTP-parseren sin. Den parseren validerer fortsatt den innkommende forespørselen; valget av sending gjør ikke vilkårlig inngang til gyldig HTTP.
Å dele TCP-lytteren gir ikke i seg selv SOCKS5 UDP-tilknytning. Glider starter UDP-lytteren sin separat. Valg av TCP-protokoll og den senere datagram-videresendingen er separate egenskaper.