Ncat’s HTTP-proxymodus versus een vast TCP-relay

Een vast byte-relay laat de HTTP-verwerking aan de bestaande proxy. Ncat’s HTTP-luistermodus is een andere, protocolbewuste dienst.

client → local TCP relay → existing forward proxy → destination

In deze opstelling heeft het relay één vaste upstream. Het geeft het verzoek van de client ongewijzigd door aan de bestaande forward-proxy. Die proxy leest de absolute URL of het CONNECT-doel, past beleid toe en opent de verbinding naar de bestemming.

Het relay rechtstreeks op een website richten verandert het contract. Een forward-proxy moet bestemmingen selecteren en HTTP-framing en verbindingsgedrag afhandelen; een hostnaam uit de eerste regel halen is niet genoeg.

Ncat van Nmap biedt apart een HTTP-bewuste luistermodus:

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

Dit loopback-voorbeeld gebruikt Ncat’s proxy-implementatie, niet een functie die elke nc deelt. De proxy aan de luisterkant behandelt HTTP-methoden en CONNECT. De SOCKS-opties aan de clientkant zetten in luistermodus geen SOCKS-server op. Een permanente gedeelde dienst vereist ook bewuste verbindingsafhandeling, toegangsbeheer en logging.

Localiseer voor observatie de versleutelingsgrens. Een relay op een gewone HTTP-proxyverbinding ziet proxyverzoeken en -antwoorden. Na CONNECT is de HTTPS van de bestemming TLS-bytes, geen leesbare pagina-inhoud. TLS naar de proxy verbergt zelfs de eerste proxy-uitwisseling op die verbinding. Gebruik client- en proxydiagnostiek voor geïnterpreteerde transacties, en bescherm logboeken die inloggegevens of gevoelige URL’s kunnen bevatten.

Gerelateerde artikelen