Utilitzeu la identitat de la destinació per a Java TLS sobre SOCKS
Connecteu primer per SOCKS i després superposeu un SSLSocket amb el nom d'amfitrió del lloc web i comprovacions explícites de l'extrem HTTPS.
L'extrem SOCKS us porta al lloc web. L'homòleg TLS dins d'aquesta connexió és el mateix lloc web, així que passeu el nom d'amfitrió de la destinació a la fàbrica de sockets superposada:
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 fragment assumeix imports estàndard de Java networking i TLS, una configuració de confiança per defecte existent i una connexió SOCKS que no necessita credencials de servidor intermediari. Fa l'apretada de mans; l'aplicació encara ha d'enviar una petició HTTP en el format que espera el servidor. Per a objectius HTTPS públics en rutes públiques permeses, la llista de servidors intermediaris SOCKS ofereix extrems candidats; feu coincidir la versió del servidor i el suport de noms d'amfitrió amb aquest camí de socket Java.
Llegiu les dues identitats de l'exemple
127.0.0.1:1080 és l'extrem del servidor intermediari, abastable des d'aquest procés Java. destination i destinationPort identifiquen el lloc web. createUnresolved conserva aquest nom d'amfitrió per al camí SOCKS en lloc de resoldre'l anticipadament al client.
El createSocket superposat rep la identitat de la destinació. setEndpointIdentificationAlgorithm("HTTPS") sol·licita explícitament les seves comprovacions de nom d'amfitrió. La confiança en la cadena de certificats d'un SSLSocket cru no estableix per si sola que la verificació del nom d'amfitrió estigui activada. Substituir el nom del servidor intermediari o el loopback per suprimir una discrepància pot autenticar l'extrem equivocat.
Manteniu la confiança i la neteja amb les seves etapes
La fàbrica per defecte utilitza la disposició de confiança configurada de la JVM. Una aplicació amb requisits privats pot fer servir en el seu lloc la seva fàbrica SSLContext inicialitzada adequadament. Aquesta elecció és independent de la ruta SOCKS; un gestor de confiança que accepta tots els certificats no repara un nom d'homòleg equivocat.
Un rebuig SOCKS es produeix abans de TLS; un certificat no fiable o un nom d'amfitrió equivocat falla durant TLS; després pot seguir una error HTTP. L'inici de sessió al servidor intermediari autoritza la petició de túnel en lloc d'autenticar el lloc web que hi ha a dins.
Tancar el socket superposat amb el tancament automàtic activat tanca el seu transport. L'àmbit de recurs extern també tanca aquest transport si l'embolcall o l'apretada de mans fallen abans de la finalització normal.