Ponti SOCKS con socat: preservare il nome host TLS del sito

Usa un listener TCP di loopback per una destinazione SOCKS preservando l'identità HTTP e TLS nell'applicazione.

Un'applicazione non ha l'opzione SOCKS, ma può connettersi a un indirizzo TCP scelto. Un adattatore a bersaglio fisso può fornire la conversazione SOCKS per una destinazione. Non deve diventare un altro proxy inoltro generico.

Per le build di socat che offrono SOCKS4A, una disposizione illustrativa è:

socat TCP4-LISTEN:9443,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4A:127.0.0.1:service.example.net:443,socksport=1080

L'endpoint SOCKS è la porta locale 1080. L'adattatore ascolta sulla porta locale 9443 e chiede a quell'endpoint service.example.net:443. Sono valori di esempio, non una distribuzione completa del servizio.

L'adattatore ha un solo bersaglio fisso

Ogni connessione TCP accettata richiede lo stesso servizio. Un'applicazione che si connette a 9443 fornisce i suoi normali byte di protocollo; socat fornisce la negoziazione SOCKS4A. Inviare una nuova richiesta HTTP CONNECT a 9443 non selezionerebbe un'altra destinazione—inoltrerebbe quei byte al servizio fisso.

SOCKS4A fornisce un nome host all'endpoint SOCKS per la risoluzione remota. Questo differisce dalla forma SOCKS4 che usa un indirizzo scelto dal client. L'upstream scelto—compreso un candidato pubblico dalla lista di proxy SOCKS4—deve supportare la gestione dei nomi host SOCKS4A e l'autenticazione richiesta; questo esempio non è una ricetta di accesso con password SOCKS5.

Connettiti localmente, identifica il servizio reale

Cambiare un URL HTTPS in https://127.0.0.1:9443/ cambia il nome host che il client può usare per TLS e HTTP. Un certificato per service.example.net non diventerà un certificato valido per il loopback.

Dove il client supporta un routing di connessione separato, conserva l'identità dell'URL originale. Curl può illustrare questa distinzione:

curl --noproxy '*' \
  --connect-to service.example.net:443:127.0.0.1:9443 \
  https://service.example.net/

Il socket va all'adattatore locale mentre la verifica TLS e la destinazione HTTP restano service.example.net. Altre applicazioni necessitano del proprio controllo equivalente supportato; non ogni client ne fornisce uno.

Il binding loopback limita l'esposizione di rete, ma altri processi locali idonei possono ancora raggiungerlo. Mantieni la durata del servizio e gli utenti appropriati. Conserva la verifica TLS invece di sopprimere l'errore di identità causato da un URL loopback.

Articoli correlati