Gebruik de identiteit van de bestemming voor Java TLS via SOCKS

Maak eerst verbinding via SOCKS en leg daarna een SSLSocket-laag aan met de hostnaam van de website en expliciete HTTPS-eindpuntcontroles.

Het SOCKS-eindpunt brengt je bij de website. De TLS-peer binnen die verbinding is de website zelf, dus geef de hostnaam van de bestemming door aan de gelaagde socketfactory:

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

Het fragment gaat uit van standaard Java-netwerk- en TLS-imports, een bestaande standaardvertrouwensconfiguratie en een SOCKS-verbinding zonder proxyreferenties. Het voert de handshake uit; de toepassing moet nog steeds een HTTP-verzoek sturen in het formaat dat de server verwacht. Voor openbare HTTPS-doelen op toegestane openbare routes biedt de SOCKS-proxylijst kandidaat-eindpunten; stem de serverversie en hostnaamondersteuning af op dit Java-socketpad.

Lees de twee identiteiten in het voorbeeld

127.0.0.1:1080 is het proxy-eindpunt, bereikbaar vanuit dit Java-proces. destination en destinationPort identificeren de website. createUnresolved bewaart die hostnaam voor het SOCKS-pad in plaats van deze meteen op de client op te lossen.

De gelaagde createSocket ontvangt de identiteit van de bestemming. setEndpointIdentificationAlgorithm("HTTPS") vraagt expliciet om de hostnaamcontroles. Het vertrouwen in de certificaatketen van een ruwe SSLSocket bewijst op zichzelf niet dat hostnaamverificatie is ingeschakeld. Het vervangen van de proxynaam of loopback om een afwijking te onderdrukken kan het verkeerde eindpunt authenticeren.

Houd vertrouwen en opruimen bij hun fasen

De standaardfactory gebruikt de geconfigureerde vertrouwensregeling van de JVM. Een toepassing met eigen vereisten kan in plaats daarvan de juist geïnitialiseerde SSLContext-factory gebruiken. Die keuze staat los van de SOCKS-route; een trustmanager die elk certificaat accepteert, herstelt geen verkeerde peernaam.

Een SOCKS-afwijzing vindt plaats vóór TLS; een niet-vertrouwd certificaat of een verkeerde hostnaam mislukt tijdens TLS; daarna kan een HTTP-fout volgen. Aanmelden bij de proxy machtigt het tunnelverzoek in plaats van de website erin te authenticeren.

Het sluiten van de gelaagde socket met automatisch sluiten ingeschakeld sluit het transport. De buitenste resource-scope sluit dat transport ook als het inpakken of de handshake mislukt vóór normale voltooiing.

Gerelateerde artikelen