Använd destinationens identitet för Java TLS över SOCKS

Anslut först via SOCKS och lägg sedan på ett SSLSocket med webbplatsens värdnamn och explicita HTTPS-slutpunktskontroller.

SOCKS-slutpunkten tar dig till webbplatsen. TLS-motparten i den anslutningen är webbplatsen själv, så skicka destinationens värdnamn till den skiktade socketfabriken:

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

Utdraget förutsätter standardimporter för Java-nätverk och TLS, en befintlig standardkonfiguration för förtroende och en SOCKS-anslutning som inte kräver proxyuppgifter. Det utför handskakningen; programmet måste fortfarande skicka en HTTP-förfrågan i det format servern förväntar sig. För offentliga HTTPS-mål på tillåtna offentliga rutter erbjuder SOCKS-proxylistan kandidatslutpunkter; matcha serverns version och värdnamnsstöd mot denna Java-socketväg.

Läs de två identiteterna i exemplet

127.0.0.1:1080 är proxy-slutpunkten, nåbar från denna Java-process. destination och destinationPort identifierar webbplatsen. createUnresolved behåller värdnamnet för SOCKS-vägen i stället för att slå upp det i förväg på klienten.

Det skiktade createSocket tar emot destinationens identitet. setEndpointIdentificationAlgorithm("HTTPS") begär uttryckligen sina värdnamnskontroller. Förtroende för certifikatkedjan hos en rå SSLSocket bevisar inte i sig att värdnamnsverifiering är aktiverad. Att ersätta proxyns namn eller loopback för att dämpa en avvikelse kan autentisera fel slutpunkt.

Håll förtroende och städning vid sina faser

Standardfabriken använder JVM:ens konfigurerade förtroendeordning. Ett program med privata krav kan i stället använda sin korrekt initierade SSLContext-fabrik. Det valet är skilt från SOCKS-rutten; en förtroendehanterare som accepterar varje certifikat reparerar inte ett felaktigt motpartsnamn.

Ett SOCKS-avslag inträffar före TLS; ett ej betrott certifikat eller fel värdnamn misslyckas under TLS; ett HTTP-fel kan följa efteråt. Inloggning till proxyn auktoriserar tunnelbegäran i stället för att autentisera webbplatsen inuti den.

Stängning av det skiktade socketet med automatisk stängning aktiverad stänger dess transport. Det yttre resursomfånget stänger också den transporten om inpackningen eller handskakningen misslyckas före normal slutföring.

Relaterade artiklar