Uzu la identecon de la celloko por Java TLS super SOCKS

Unue konektu per SOCKS, poste tavoligu SSLSocket kun la gastigantnomo de la retejo kaj eksplicitaj HTTPS-finpunkto-kontroloj.

La SOCKS-finpunkto portas vin al la retejo. La TLS-partnero en tiu konekto estas la retejo mem, do transdonu la celan gastigantnomon al la tavoligita ingofabriko:

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

La fragmento supozas normajn Java-retaĵajn kaj TLS-importojn, ekzistantan defaŭltan fido-agordon kaj SOCKS-konekton sen prokuraj akreditaĵoj. Ĝi plenumas la manpremon; la aplikaĵo ankoraŭ devas sendi HTTP-peton en la formato atendata de la servilo. Por publikaj HTTPS-celoj sur permesitaj publikaj vojoj, la SOCKS-prokurlisto proponas kandidatajn finpunktojn; agordu la servilan version kaj gastigantnoman subtenon al ĉi tiu Java-ingovojo.

Legu la du identecojn en la ekzemplo

127.0.0.1:1080 estas la prokura finpunkto, atingebla de ĉi tiu Java-procezo. destination kaj destinationPort identigas la retejon. createUnresolved konservas tiun gastigantnomon por la SOCKS-vojo anstataŭ solvi ĝin antaŭtempe ĉe la kliento.

La tavoligita createSocket ricevas la identecon de la celloko. setEndpointIdentificationAlgorithm("HTTPS") eksplicite petas ĝiajn gastigantnomajn kontrolojn. La atestilaĉena fido de kruda SSLSocket per si mem ne pruvas, ke gastigantnoma kontrolado estas ŝaltita. Anstataŭigi la prokuran nomon aŭ loopback por subpremi malkongruon povas aŭtentigi la malĝustan finpunkton.

Tenu fidon kaj purigadon kun iliaj etapoj

La defaŭlta fabriko uzas la agorditan fido-aron de la JVM. Aplikaĵo kun privataj postuloj povas anstataŭe uzi sian taŭge pravigitan SSLContext-fabrikon. Tiu elekto estas aparta de la SOCKS-vojo; fido-administranto akceptanta ĉiun atestilon ne riparas malĝustan partnernomon.

SOCKS-rifuzo okazas antaŭ TLS; nefidinda atestilo aŭ malĝusta gastigantnomo malsukcesas dum TLS; poste povas sekvi HTTP-eraro. Prokura ensaluto rajtigas la tunelpeton anstataŭ aŭtentigi la retejon interne.

Fermi la tavoligitan ingon kun ŝaltita aŭtomata fermo fermas ĝian transporton. La ekstera risurca amplekso ankaŭ fermas tiun transporton se la volvado aŭ manpremo malsukcesas antaŭ normala finiĝo.

Rilataj artikoloj