Użyj tożsamości celu dla Java TLS przez SOCKS

Najpierw połącz się przez SOCKS, następnie nałóż SSLSocket z nazwą hosta witryny i jawnymi kontrolami punktu końcowego HTTPS.

Punkt końcowy SOCKS doprowadza cię do witryny. Drugą stroną TLS w tym połączeniu jest sama witryna, więc przekaż nazwę hosta celu warstwowej fabryce gniazd:

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

Fragment zakłada standardowe importy Java networking i TLS, istniejącą domyślną konfigurację zaufania oraz połączenie SOCKS niewymagające danych logowania proxy. Wykonuje uścisk dłoni; aplikacja nadal musi wysłać żądanie HTTP w formacie oczekiwanym przez serwer. Dla publicznych celów HTTPS na dozwolonych publicznych trasach lista proxy SOCKS oferuje kandydujące punkty końcowe; dopasuj wersję serwera i obsługę nazw hostów do tej ścieżki gniazda Java.

Odczytaj dwie tożsamości w przykładzie

127.0.0.1:1080 to punkt końcowy proxy, osiągalny z tego procesu Java. destination i destinationPort identyfikują witrynę. createUnresolved zachowuje tę nazwę hosta dla ścieżki SOCKS, zamiast rozwiązywać ją od razu po stronie klienta.

Warstwowy createSocket otrzymuje tożsamość celu. setEndpointIdentificationAlgorithm("HTTPS") jawnie żąda kontroli nazwy hosta. Zaufanie do łańcucha certyfikatów surowego SSLSocket samo w sobie nie dowodzi, że weryfikacja nazwy hosta jest włączona. Zastąpienie nazwy proxy lub loopback, aby stłumić niezgodność, może uwierzytelnić niewłaściwy punkt końcowy.

Utrzymuj zaufanie i sprzątanie na ich etapach

Domyślna fabryka korzysta ze skonfigurowanego układu zaufania JVM. Aplikacja z własnymi wymaganiami może zamiast tego użyć swojej prawidłowo zainicjowanej fabryki SSLContext. Ten wybór jest niezależny od trasy SOCKS; menedżer zaufania akceptujący każdy certyfikat nie naprawia błędnej nazwy peera.

Odmowa SOCKS następuje przed TLS; niezaufany certyfikat lub błędna nazwa hosta zawodzi podczas TLS; potem może nastąpić błąd HTTP. Logowanie do proxy autoryzuje żądanie tunelu, a nie uwierzytelnia witryny w nim.

Zamknięcie warstwowego gniazda z włączonym automatycznym zamykaniem zamyka jego transport. Zewnętrzny zakres zasobów również zamyka ten transport, jeśli opakowanie lub uścisk dłoni zawiodą przed normalnym zakończeniem.

Powiązane artykuły