Използвайте идентичността на дестинацията за 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 грешка. Влизането в проксито оторизира заявката за тунел, а не удостоверява сайта вътре в него.

Затварянето на наслоения сокет с включено автоматично затваряне затваря неговия транспорт. Външният обхват на ресурса също затваря този транспорт, ако обвиването или ръкостискането се провалят преди нормалното завършване.

Подобни статии