Koristite identitet odredišta za Java TLS preko SOCKS-a

Prvo se povežite kroz SOCKS, zatim slojite SSLSocket s imenom hosta web-mjesta i izričitim provjerama HTTPS krajnje točke.

SOCKS krajnja točka dovodi vas do web-mjesta. TLS partner unutar te veze je samo web-mjesto, stoga predajte ime hosta odredišta slojevitoj tvornici socketa:

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

Isječak pretpostavlja standardne Java mrežne i TLS uvoze, postojeću zadanu konfiguraciju povjerenja i SOCKS vezu kojoj nisu potrebni proxy podaci za prijavu. Izvodi rukovanje; aplikacija još mora poslati HTTP zahtjev u formatu koji poslužitelj očekuje. Za javne HTTPS ciljeve na dopuštenim javnim rutama popis SOCKS proxyja nudi kandidat-krajnje točke; uskladite verziju poslužitelja i podršku za imena hostova s ovom Java socket stazom.

Pročitajte dva identiteta u primjeru

127.0.0.1:1080 je krajnja točka proxyja, dostupna iz ovog Java procesa. destination i destinationPort identificiraju web-mjesto. createUnresolved zadržava to ime hosta za SOCKS stazu umjesto da ga odmah razriješi na klijentu.

Slojeviti createSocket prima identitet odredišta. setEndpointIdentificationAlgorithm("HTTPS") izričito traži provjere imena hosta. Povjerenje u lanac certifikata sirovog SSLSocket-a samo po sebi ne dokazuje da je provjera imena hosta omogućena. Zamjena imena proxyja ili loopbacka radi gušenja nepodudarnosti može autentificirati pogrešnu krajnju točku.

Zadržite povjerenje i čišćenje uz njihove faze

Zadana tvornica koristi konfigurirani raspored povjerenja JVM-a. Aplikacija s privatnim zahtjevima može umjesto toga koristiti svoju ispravno inicijaliziranu SSLContext tvornicu. Taj je izbor odvojen od SOCKS rute; upravitelj povjerenja koji prihvaća svaki certifikat ne popravlja pogrešno ime partnera.

Odbijanje SOCKS-a događa se prije TLS-a; nepouzdan certifikat ili pogrešno ime hosta pada tijekom TLS-a; nakon toga može uslijediti HTTP pogreška. Prijava na proxy ovlašćuje zahtjev tunela, a ne autentificira web-mjesto unutar njega.

Zatvaranje slojevitog socketa s omogućenim automatskim zatvaranjem zatvara njegov prijenos. Vanjski opseg resursa također zatvara taj prijenos ako omatanje ili rukovanje ne uspije prije normalnog dovršetka.

Povezani članci