Ncats HTTP-proxyläge kontra en fast TCP-relä

client → local TCP relay → existing forward proxy → destination

I den här uppställningen har reläet en fast uppströmskanal. Det skickar vidare klientens begäran oförändrad till den befintliga vidarebefordrande proxyn. Den proxyn läser den absoluta URL:en eller CONNECT-målet, tillämpar policy och öppnar anslutningen till målet.

Att rikta reläet direkt mot en webbplats ändrar avtalet. En vidarebefordrande proxy måste välja mål och hantera HTTP-inramning och anslutningsbeteende; att extrahera ett värdnamn från första raden räcker inte.

Ncat från Nmap erbjuder separat ett HTTP-medvetet lyssnarläge:

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

Det här loopback-exemplet använder Ncats proxyimplementering, inte en funktion som alla nc delar. Dess proxy på lyssnarsidan hanterar HTTP-metoder och CONNECT. Dess SOCKS-alternativ på klientsidan sätter inte upp en SOCKS-server i lyssnarläge. En varaktig delad tjänst kräver också medveten anslutningshantering, åtkomstkontroll och loggning.

För att observera, hitta krypteringsgränsen. Ett relä på en vanlig HTTP-proxyanslutning ser proxyförfrågningar och -svar. Efter CONNECT är målets HTTPS TLS-byte, inte läsbart sidinnehåll. TLS till proxyn döljer till och med det inledande proxyutbytet på den länken. Använd klient- och proxydiagnostik för tolkade transaktioner och skydda loggar som kan innehålla autentiseringsuppgifter eller känsliga URL:er.