Use a identidade do destino para Java TLS sobre SOCKS

Conecte primeiro por SOCKS e depois sobreponha um SSLSocket com o nome do host do site e verificações explícitas do endpoint HTTPS.

O endpoint SOCKS leva você ao site. O par TLS dentro dessa conexão é o próprio site, então passe o nome do host do destino para a fábrica de sockets em camadas:

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 trecho pressupõe importações padrão de Java networking e TLS, uma configuração de confiança padrão existente e uma conexão SOCKS que não exige credenciais de proxy. Ele realiza o handshake; a aplicação ainda precisa enviar uma solicitação HTTP no formato esperado pelo servidor. Para alvos HTTPS públicos em rotas públicas permitidas, a lista de proxies SOCKS oferece endpoints candidatos; alinhe a versão do servidor e o suporte a nomes de host a este caminho de socket Java.

Leia as duas identidades no exemplo

127.0.0.1:1080 é o endpoint do proxy, acessível a partir deste processo Java. destination e destinationPort identificam o site. createUnresolved mantém esse nome de host para o caminho SOCKS em vez de resolvê-lo antecipadamente no cliente.

O createSocket em camadas recebe a identidade do destino. setEndpointIdentificationAlgorithm("HTTPS") solicita explicitamente suas verificações de nome de host. A confiança na cadeia de certificados de um SSLSocket bruto não estabelece por si só que a verificação do nome de host esteja habilitada. Substituir o nome do proxy ou o loopback para suprimir uma incompatibilidade pode autenticar o endpoint errado.

Mantenha confiança e limpeza com suas etapas

A fábrica padrão usa a disposição de confiança configurada da JVM. Uma aplicação com requisitos próprios pode, em vez disso, usar sua fábrica SSLContext inicializada corretamente. Essa escolha é separada da rota SOCKS; um gerenciador de confiança que aceita todos os certificados não corrige um nome de par errado.

Uma rejeição SOCKS ocorre antes do TLS; um certificado não confiável ou nome de host errado falha durante o TLS; um erro HTTP pode vir em seguida. O login no proxy autoriza a solicitação de túnel em vez de autenticar o site dentro dele.

Fechar o socket em camadas com o fechamento automático habilitado fecha seu transporte. O escopo de recurso externo também fecha esse transporte se o empacotamento ou o handshake falharem antes da conclusão normal.

Artigos relacionados