Ncat se HTTP-proxy-modus teenoor ’n vaste TCP-aflos

client → local TCP relay → existing forward proxy → destination

In hierdie reëling het die aflos een vaste opstroom. Dit stuur die kliënt se versoek onveranderd aan die bestaande vorentoe-proxy. Daardie proxy lees die absolute URL of CONNECT-teiken, pas beleid toe en open die bestemmingsverbinding.

Om die aflos direk na ’n webwerf te rig, verander die kontrak. ’n Vorentoe-proxy moet bestemmings kies en HTTP-raming en verbindingsgedrag hanteer; om net ’n gasheernaam uit die eerste reël te haal, is nie genoeg nie.

Nmap se Ncat bied afsonderlik ’n HTTP-bewuste luistermodus:

ncat --listen 127.0.0.1 3128 --proxy-type http

Hierdie loopback-voorbeeld gebruik Ncat se proxy-implementering, nie ’n funksie wat elke nc deel nie. Die proxy aan die luisterkant hanteer HTTP-metodes en CONNECT. Sy kliëntkant-SOCKS-opsies vestig nie ’n SOCKS-bediener in luistermodus nie. ’n Aanhoudende gedeelde diens vereis ook doelbewuste verbindingshantering, toegangsbeheer en logboeke.

Vir waarneming, bepaal die enkripsiegrens. ’n Aflos op ’n gewone HTTP-proxyverbinding kan proxyversoeke en -antwoorde sien. Ná CONNECT is die bestemming se HTTPS TLS-grepe, nie leesbare bladsyinhoud nie. TLS na die proxy verberg selfs die aanvanklike proxy-uitruiling op daardie skakel. Gebruik kliënt-/proxy-diagnostiek vir geïnterpreteerde transaksies, en beskerm logboeke wat geloofsbriewe of sensitiewe URL’s kan bevat.