Usa a identidade do destino para Java TLS sobre SOCKS

Conecta primeiro por SOCKS e despois superpón un SSLSocket co nome de host do sitio e comprobacións explícitas do extremo HTTPS.

O extremo SOCKS lévao ao sitio. O par TLS dentro desa conexión é o propio sitio, así que pasa o nome de host do destino á fábrica de sockets superposta:

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.
    }
}

O fragmento supón importacións estándar de redes Java e TLS, unha configuración de confianza predeterminada existente e unha conexión SOCKS que non necesita credenciais de proxy. Realiza o apretón de mans; a aplicación aínda debe enviar unha solicitude HTTP no formato que espera o servidor. Para obxectivos HTTPS públicos en rutas públicas permitidas, a lista de proxies SOCKS ofrece extremos candidatos; axusta a versión do servidor e a compatibilidade de nomes de host a esta ruta de socket Java.

Le as dúas identidades do exemplo

127.0.0.1:1080 é o extremo do proxy, accesible desde este proceso Java. destination e destinationPort identifican o sitio. createUnresolved conserva ese nome de host para a ruta SOCKS en lugar de resolvelo de inmediato no cliente.

O createSocket superposto recibe a identidade do destino. setEndpointIdentificationAlgorithm("HTTPS") solicita explicitamente as súas comprobacións de nome de host. A confianza na cadea de certificados dun SSLSocket sen procesar non establece por si soa que a verificación do nome de host estea activada. Substituír o nome do proxy ou o loopback para suprimir unha discrepancia pode autenticar o extremo incorrecto.

Mantén a confianza e a limpeza coas súas etapas

A fábrica predeterminada usa a disposición de confianza configurada da JVM. Unha aplicación con requisitos privados pode usar no seu lugar a súa fábrica SSLContext inicializada correctamente. Esa elección é independente da ruta SOCKS; un xestor de confianza que acepta todos os certificados non repara un nome de par incorrecto.

Un rexeitamento SOCKS ocorre antes de TLS; un certificado non fiable ou un nome de host incorrecto falla durante TLS; despois pode seguir un erro HTTP. O inicio de sesión no proxy autoriza a solicitude de túnel en lugar de autenticar o sitio que hai dentro.

Pechar o socket superposto co peche automático activado pecha o seu transporte. O ámbito de recurso externo tamén pecha ese transporte se o envoltorio ou o apretón de mans fallan antes da finalización normal.

Artigos relacionados