Використовуйте ідентичність призначення для 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. Вхід у проксі авторизує запит тунелю, а не автентифікує сайт усередині нього.

Закриття шаруватого сокета з увімкненим автозакриттям закриває його транспорт. Зовнішня область ресурсів також закриває цей транспорт, якщо обгортання або рукостискання зазнають невдачі до нормального завершення.

Схожі статті