Bruk destinasjonens identitet for Java TLS over SOCKS

Koble til via SOCKS først, og legg deretter på en SSLSocket med nettstedets vertsnavn og eksplisitte HTTPS-endepunktkontroller.

SOCKS-endepunktet bringer deg til nettstedet. TLS-motparten inne i den forbindelsen er nettstedet selv, så send destinasjonens vertsnavn til den lagdelte socketfabrikken:

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 forutsetter standard Java-nettverks- og TLS-importer, en eksisterende standard tillitskonfigurasjon og en SOCKS-tilkobling som ikke trenger proxy-påloggingsinformasjon. Det utfører håndtrykket; applikasjonen må fortsatt sende en HTTP-forespørsel i formatet serveren forventer. For offentlige HTTPS-mål på tillatte offentlige ruter tilbyr SOCKS-proxylisten kandidatendepunkter; tilpass serverens versjon og vertsnavnstøtte til denne Java-socketveien.

Les de to identitetene i eksempelet

127.0.0.1:1080 er proxy-endepunktet, tilgjengelig fra denne Java-prosessen. destination og destinationPort identifiserer nettstedet. createUnresolved beholder vertsnavnet for SOCKS-veien i stedet for å slå det opp på forhånd hos klienten.

Det lagdelte createSocket mottar destinasjonens identitet. setEndpointIdentificationAlgorithm("HTTPS") ber uttrykkelig om vertsnavnkontrollene sine. Tillit til sertifikatkjeden til en rå SSLSocket beviser ikke i seg selv at vertsnavnvalidering er aktivert. Å erstatte proxyens navn eller loopback for å undertrykke et avvik kan autentisere feil endepunkt.

Hold tillit og opprydding sammen med fasene

Standardfabrikken bruker JVM-ens konfigurerte tillitsordning. En applikasjon med private krav kan i stedet bruke sin riktig initialiserte SSLContext-fabrikk. Det valget er atskilt fra SOCKS-ruten; en tillitsbehandler som godtar hvert sertifikat, reparerer ikke et feil motpartnavn.

En SOCKS-avvisning skjer før TLS; et ikke-klarert sertifikat eller feil vertsnavn feiler under TLS; en HTTP-feil kan følge etterpå. Proxy-pålogging autoriserer tunnel-forespørselen i stedet for å autentisere nettstedet inni den.

Lukking av den lagdelte socketen med automatisk lukking aktivert lukker transporten. Den ytre ressursblokken lukker også den transporten hvis innpakningen eller håndtrykket feiler før normal fullføring.

Relaterte artikler