Puentes SOCKS de socat: conserva el nombre de host TLS del sitio

Usa un escucha TCP de loopback para un destino SOCKS mientras conservas la identidad HTTP y TLS en la aplicación.

Una aplicación no tiene opción SOCKS, pero puede conectarse a una dirección TCP elegida. Un adaptador de objetivo fijo puede aportar la conversación SOCKS para un destino. No tiene por qué convertirse en otro proxy de reenvío genérico.

Para compilaciones de socat que ofrecen SOCKS4A, un montaje ilustrativo es:

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

El punto final SOCKS es el puerto local 1080. El adaptador escucha en el puerto local 9443 y pide a ese punto final service.example.net:443. Son valores de ejemplo, no un despliegue completo del servicio.

El adaptador tiene un objetivo fijo

Cada conexión TCP aceptada pide el mismo servicio. Una aplicación que se conecta a 9443 aporta sus bytes de protocolo habituales; socat aporta la negociación SOCKS4A. Enviar una nueva solicitud HTTP CONNECT a 9443 no elegiría otro destino: enviaría esos bytes hacia el servicio fijo.

SOCKS4A entrega un nombre de host al punto final SOCKS para la resolución remota. Eso difiere de la forma SOCKS4 que usa una dirección elegida por el cliente. El upstream elegido—incluido un candidato público de la lista de proxies SOCKS4—debe admitir el manejo de nombres de host SOCKS4A y la autenticación requerida; este ejemplo no es una receta de inicio de sesión con contraseña SOCKS5.

Conecta localmente, identifica el servicio real

Cambiar una URL HTTPS a https://127.0.0.1:9443/ cambia el nombre de host que el cliente puede usar para TLS y HTTP. Un certificado para service.example.net no se convertirá en un certificado válido para loopback.

Donde el cliente admite enrutamiento de conexión separado, conserva la identidad de la URL original. Curl puede ilustrar esa distinción:

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

El socket va al adaptador local mientras la verificación TLS y el destino HTTP siguen siendo service.example.net. Otras aplicaciones necesitan su propio control equivalente admitido; no todos los clientes lo proporcionan.

El enlace de loopback limita la exposición de red, pero otros procesos locales aptos aún pueden alcanzarlo. Mantén la vida útil del servicio y los usuarios adecuados. Conserva la verificación TLS en lugar de suprimir el error de identidad causado por una URL de loopback.

Artículos relacionados