Usa la identidad del destino para Java TLS sobre SOCKS

Conecta primero por SOCKS y luego superpón un SSLSocket con el nombre de host del sitio y comprobaciones explícitas del extremo HTTPS.

El extremo SOCKS te lleva al sitio web. El par TLS dentro de esa conexión es el propio sitio, así que pasa el nombre de host del destino a la fábrica de sockets superpuesta:

String destination = "example.com";
int destinationPort = 443;
Proxy proxy = new Proxy(
    Proxy.Type.SOCKS,
    new InetSocketAddress("127.0.0.1", 1080)
);

try (Socket transport = new Socket(proxy)) {
    transport.connect(
        InetSocketAddress.createUnresolved(destination, destinationPort),
        5000
    );
    SSLSocketFactory factory =
        (SSLSocketFactory) SSLSocketFactory.getDefault();
    try (SSLSocket tls = (SSLSocket) factory.createSocket(
            transport, destination, destinationPort, true)) {
        SSLParameters parameters = tls.getSSLParameters();
        parameters.setEndpointIdentificationAlgorithm("HTTPS");
        tls.setSSLParameters(parameters);
        tls.setSoTimeout(15000);
        tls.startHandshake();
        // Send the application's HTTPS request through tls.
    }
}

El fragmento supone importaciones estándar de redes Java y TLS, una configuración de confianza predeterminada existente y una conexión SOCKS que no necesita credenciales de proxy. Realiza el apretón de manos; la aplicación todavía debe enviar una petición HTTP en el formato que espera el servidor. Para objetivos HTTPS públicos en rutas públicas permitidas, la lista de proxies SOCKS ofrece extremos candidatos; ajusta la versión del servidor y la compatibilidad de nombres de host a esta ruta de socket Java.

Lee las dos identidades del ejemplo

127.0.0.1:1080 es el extremo del proxy, accesible desde este proceso Java. destination y destinationPort identifican el sitio. createUnresolved conserva ese nombre de host para la ruta SOCKS en lugar de resolverlo de inmediato en el cliente.

El createSocket superpuesto recibe la identidad del destino. setEndpointIdentificationAlgorithm("HTTPS") solicita explícitamente sus comprobaciones de nombre de host. La confianza en la cadena de certificados de un SSLSocket sin procesar no establece por sí sola que la verificación del nombre de host esté habilitada. Sustituir el nombre del proxy o el loopback para suprimir una discrepancia puede autenticar el extremo equivocado.

Mantén la confianza y la limpieza con sus etapas

La fábrica predeterminada usa la disposición de confianza configurada de la JVM. Una aplicación con requisitos privados puede usar en su lugar su fábrica SSLContext inicializada correctamente. Esa elección es independiente de la ruta SOCKS; un gestor de confianza que acepta todos los certificados no repara un nombre de par incorrecto.

Un rechazo SOCKS ocurre antes de TLS; un certificado no confiable o un nombre de host incorrecto falla durante TLS; después puede seguir un error HTTP. El inicio de sesión en el proxy autoriza la petición de túnel en lugar de autenticar el sitio que hay dentro.

Cerrar el socket superpuesto con el cierre automático habilitado cierra su transporte. El ámbito de recurso externo también cierra ese transporte si el envoltorio o el apretón de manos fallan antes de completarse con normalidad.

Artículos relacionados