Nola har dezakeen proxy ataka batek HTTP eta SOCKS batera
Azaltzen du nola nahita mistoa den entzule batek HTTP eta SOCKS bereiz ditzakeen, protokolo bakarreko entzule arrunt batek ezin duen bitartean.
Proxy entzule misto batek HTTP eta SOCKS har ditzake TCP ataka bakarrean, zerbitzariak protokoloaren hasierako byteak aztertzen dituelako. Ataka-zenbakiak ez du detekzio hori egiten.
HTTP proxy eskaera bat HTTP metodoarekin hasten da, hala nola GET edo CONNECT. SOCKS agurra protokolo-eremu bitarrekin hasten da. Sarrera horietarako diseinatutako softwareak konexioa kudeatzaile egokira bidera dezake.
Hau inplementazio-ezaugarri esplizitua da. Squid-en HTTP entzule arrunta ez da mistoa bihurtzen bere ataka 1080ra aldatzeagatik, eta SOCKS soilik den entzule batek ez du HTTP ikasten nabigatzailearen ezarpenetik.
TLSek beste muga bat gehitzen du: proxy konexio zifratua TLSrekin hasten da, ez HTTP metodo ikusgarri batekin. Puntu berean hori onartzeko, nahita egindako tratamendu gehigarria behar da; testu laueko HTTP eta SOCKS ezagutzeak ez du gaitasun hori frogatzen.
Erabili puntuarentzat dokumentatutako bezero-protokoloa. Biak funtzionatzen badute, zerbitzari horren entzule mistoaren froga da, ez protokoloa bezero guztietan zehaztu gabe uzteko arrazoia.
Gliderren entzule mistoak adibide zehatza ematen du: byte bat begiratzen du kontsumitu gabe, 0x05 bere SOCKS5 kudeatzailera bidaltzen du, eta bestela bere HTTP analizatzailea deitzen du. Analizatzaile horrek oraindik sarrerako eskaera baliozkotzen du; bidaltzeko hautaketak ez du edozein sarrera HTTP baliodun bihurtzen.
TCP entzulea partekatzeak ez du berez SOCKS5 UDP elkartzerik ematen. Gliderrek bere UDP entzulea bereiz abiarazten du. TCP protokoloaren hautaketa eta geroagoko datagramen errela gaitasun bereiziak dira.