Используйте идентичность пункта назначения для Java TLS через SOCKS

Сначала подключитесь через SOCKS, затем наложите SSLSocket с именем хоста сайта и явными проверками конечной точки HTTPS.

Конечная точка SOCKS доставляет вас на сайт. Партнёр TLS внутри этого соединения — сам сайт, поэтому передайте имя хоста назначения в фабрику слоистых сокетов:

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

Фрагмент предполагает стандартные импорты Java networking и TLS, существующую конфигурацию доверия по умолчанию и SOCKS-соединение без учётных данных прокси. Он выполняет рукопожатие; приложению всё ещё нужно отправить HTTP-запрос в ожидаемом сервером формате. Для публичных целей HTTPS на разрешённых публичных маршрутах список SOCKS-прокси предлагает подходящие конечные точки; согласуйте версию сервера и поддержку имён хостов с этим путём сокета Java.

Прочитайте две идентичности в примере

127.0.0.1:1080 — это конечная точка прокси, доступная из этого процесса Java. destination и destinationPort определяют сайт. createUnresolved сохраняет это имя хоста для пути SOCKS, а не разрешает его заранее на клиенте.

Слоистый createSocket получает идентичность назначения. setEndpointIdentificationAlgorithm("HTTPS") явно запрашивает проверки имени хоста. Доверие к цепочке сертификатов необработанного SSLSocket само по себе не доказывает, что проверка имени хоста включена. Подмена имени прокси или loopback ради подавления несоответствия может аутентифицировать неверную конечную точку.

Держите доверие и очистку на их этапах

Фабрика по умолчанию использует настроенный порядок доверия JVM. Приложение с частными требованиями может вместо этого использовать свою правильно инициализированную фабрику SSLContext. Этот выбор отделён от маршрута SOCKS; менеджер доверия, принимающий каждый сертификат, не исправляет неверное имя партнёра.

Отказ SOCKS происходит до TLS; недоверенный сертификат или неверное имя хоста терпит неудачу во время TLS; после этого может последовать ошибка HTTP. Вход в прокси авторизует запрос туннеля, а не аутентифицирует сайт внутри него.

Закрытие слоистого сокета с включённым автозакрытием закрывает его транспорт. Внешняя область ресурсов также закрывает этот транспорт, если обёртывание или рукопожатие не удались до нормального завершения.

Похожие статьи