Користете го идентитетот на одредиштето за 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 мрежни и 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 грешка. Најавувањето на проксито го овластува барањето за тунел, а не ја автентицира страницата внатре во него.

Затворањето на слојниот сокет со овозможено автоматско затворање го затвора неговиот транспорт. Надворешниот опсег на ресурси исто така го затвора тој транспорт ако завиткувањето или ракувањето не успеат пред нормалното завршување.

Поврзани статии