Gamitin ang pagkakakilanlan ng destinasyon para sa Java TLS sa SOCKS
Kumonekta muna sa SOCKS, pagkatapos patungan ng SSLSocket na may hostname ng website at malinaw na pagsusuri sa HTTPS endpoint.
Dinadala ka ng SOCKS endpoint sa website. Ang TLS peer sa loob ng koneksyong iyon ay ang website mismo, kaya ipasa ang hostname ng destinasyon sa naka-layer na socket factory:
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.
}
}Ipinapalagay ng snippet ang karaniwang Java networking at TLS imports, umiiral na default na trust configuration at SOCKS na koneksyon na hindi nangangailangan ng proxy credentials. Ginagawa nito ang handshake; kailangan pa ring magpadala ng HTTP request ang aplikasyon sa format na inaasahan ng server. Para sa pampublikong HTTPS target sa pinapayagang pampublikong ruta, nag-aalok ang listahan ng SOCKS proxy ng mga kandidatong endpoint; itugma ang bersyon ng server at suporta sa hostname sa landas ng Java socket na ito.
Basahin ang dalawang pagkakakilanlan sa halimbawa
127.0.0.1:1080 ang proxy endpoint, naaabot mula sa Java process na ito. Tinutukoy ng destination at destinationPort ang website. Pinapanatili ng createUnresolved ang hostname na iyon para sa SOCKS na landas sa halip na lutasin agad sa client.
Tinatanggap ng naka-layer na createSocket ang pagkakakilanlan ng destinasyon. Tahasang hinihiling ng setEndpointIdentificationAlgorithm("HTTPS") ang mga pagsusuri sa hostname nito. Ang tiwala sa certificate chain ng raw SSLSocket ay hindi nagpapatunay nang mag-isa na naka-enable ang hostname verification. Ang pagpapalit ng pangalan ng proxy o loopback upang pigilan ang hindi pagkakatugma ay maaaring magpatotoo sa maling endpoint.
Panatilihin ang tiwala at paglilinis kasama ng kanilang mga yugto
Ginagamit ng default na factory ang naka-configure na trust arrangement ng JVM. Ang aplikasyong may pribadong pangangailangan ay maaaring gamitin ang sarili nitong wastong na-initialize na SSLContext factory. Ang pagpiling iyon ay hiwalay sa SOCKS na ruta; ang trust manager na tumatanggap ng bawat certificate ay hindi nag-aayos ng maling pangalan ng peer.
Ang pagtanggi ng SOCKS ay nangyayari bago ang TLS; ang hindi pinagkakatiwalaang certificate o maling hostname ay nabigo sa panahon ng TLS; maaaring sumunod ang HTTP error pagkatapos. Ang pag-login sa proxy ay nagpapahintulot sa tunnel request sa halip na patunayan ang website sa loob nito.
Ang pagsara ng naka-layer na socket na naka-enable ang auto-close ay nagsasara ng transport nito. Isinasara rin ng panlabas na saklaw ng resource ang transport na iyon kung mabigo ang wrapping o handshake bago ang normal na pagkumpleto.