Die Identität des Ziels für Java-TLS über SOCKS verwenden

Zuerst über SOCKS verbinden, dann ein SSLSocket mit dem Website-Hostnamen und expliziten HTTPS-Endpunktprüfungen aufsetzen.

Der SOCKS-Endpunkt bringt dich zur Website. Der TLS-Peer in dieser Verbindung ist die Website selbst, also übergib den Ziel-Hostnamen an die geschichtete Socket-Factory:

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

Das Fragment setzt Standard-Importe für Java-Netzwerk und TLS, eine vorhandene Standard-Vertrauenskonfiguration und eine SOCKS-Verbindung ohne Proxy-Anmeldedaten voraus. Es führt den Handshake aus; die Anwendung muss weiterhin eine HTTP-Anfrage im vom Server erwarteten Format senden. Für öffentliche HTTPS-Ziele auf zulässigen öffentlichen Routen bietet die SOCKS-Proxy-Liste Kandidaten-Endpunkte; stimme Serverversion und Hostnamen-Unterstützung auf diesen Java-Socket-Pfad ab.

Die beiden Identitäten im Beispiel lesen

127.0.0.1:1080 ist der Proxy-Endpunkt, erreichbar aus diesem Java-Prozess. destination und destinationPort identifizieren die Website. createUnresolved behält diesen Hostnamen für den SOCKS-Pfad, statt ihn vorab beim Client aufzulösen.

Das geschichtete createSocket erhält die Identität des Ziels. setEndpointIdentificationAlgorithm("HTTPS") fordert ausdrücklich dessen Hostnamenprüfungen an. Das Zertifikatskettenvertrauen eines rohen SSLSocket belegt für sich genommen nicht, dass die Hostnamenprüfung aktiviert ist. Ersetzt man den Proxy-Namen oder Loopback, um eine Abweichung zu unterdrücken, kann der falsche Endpunkt authentifiziert werden.

Vertrauen und Aufräumen bei ihren Phasen halten

Die Standard-Factory nutzt die konfigurierte Vertrauensregelung der JVM. Eine Anwendung mit eigenen Anforderungen kann stattdessen ihre ordnungsgemäß initialisierte SSLContext-Factory verwenden. Diese Wahl ist vom SOCKS-Pfad getrennt; ein Trust-Manager, der jedes Zertifikat akzeptiert, repariert keinen falschen Peer-Namen.

Eine SOCKS-Ablehnung erfolgt vor TLS; ein nicht vertrauenswürdiges Zertifikat oder ein falscher Hostname scheitert während TLS; danach kann ein HTTP-Fehler folgen. Die Proxy-Anmeldung autorisiert die Tunnelanfrage, statt die Website darin zu authentifizieren.

Das Schließen des geschichteten Sockets bei aktiviertem automatischem Schließen schließt seinen Transport. Der äußere Ressourcenbereich schließt diesen Transport ebenfalls, wenn das Umhüllen oder der Handshake vor dem normalen Abschluss scheitert.

Ähnliche Artikel