Brug destinationens identitet til Java TLS over SOCKS

Forbind først gennem SOCKS, og læg derefter et SSLSocket-lag på med webstedets værtsnavn og eksplicitte HTTPS-endepunktskontroller.

SOCKS-endepunktet bringer dig til webstedet. TLS-modparten inde i den forbindelse er webstedet selv, så send destinationens værtsnavn til den lagdelte socket-fabrik:

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

Uddraget forudsætter standard Java-netværks- og TLS-import, en eksisterende standardtillidskonfiguration og en SOCKS-forbindelse uden proxy-legitimationsoplysninger. Det udfører håndtrykket; applikationen skal stadig sende en HTTP-anmodning i det format, serveren forventer. For offentlige HTTPS-mål på tilladte offentlige ruter tilbyder SOCKS-proxylisten kandidatendepunkter; afstem serverens version og værtsnavnsunderstøttelse med denne Java-socketvej.

Læs de to identiteter i eksemplet

127.0.0.1:1080 er proxy-endepunktet, tilgængeligt fra denne Java-proces. destination og destinationPort identificerer webstedet. createUnresolved bevarer værtsnavnet til SOCKS-ruten i stedet for at slå det op på forhånd hos klienten.

Det lagdelte createSocket modtager destinationens identitet. setEndpointIdentificationAlgorithm("HTTPS") anmoder udtrykkeligt om dens værtsnavnskontroller. Et råt SSLSockets certifikatkædetillid beviser ikke i sig selv, at værtsnavnsvalidering er aktiveret. Hvis man erstatter proxyens navn eller loopback for at undertrykke en uoverensstemmelse, kan det godkende det forkerte endepunkt.

Hold tillid og oprydning sammen med deres faser

Standardfabrikken bruger JVM'ens konfigurerede tillidsordning. En applikation med private krav kan i stedet bruge sin korrekt initialiserede SSLContext-fabrik. Det valg er adskilt fra SOCKS-ruten; en tillidsmanager, der accepterer hvert certifikat, reparerer ikke et forkert modpartnavn.

En SOCKS-afvisning sker før TLS; et ikke-betroet certifikat eller forkert værtsnavn fejler under TLS; en HTTP-fejl kan følge bagefter. Proxy-login autoriserer tunnelanmodningen i stedet for at godkende webstedet inde i den.

Lukning af det lagdelte socket med automatisk lukning aktiveret lukker dets transport. Den ydre ressourceblok lukker også den transport, hvis indpakning eller håndtryk fejler før normal afslutning.

Relaterede artikler