გამოიყენეთ დანიშნულების იდენტობა Java TLS-ისთვის SOCKS-ის გავლით

SOCKS საბოლოო წერტილი საიტამდე მიგიყვანთ. TLS პარტნიორი ამ კავშირის შიგნით თავად საიტია, ამიტომ გადაეცით დანიშნულების ჰოსტის სახელი შრეებრივ socket ფაბრიკას:

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 socket გზას.

წაიკითხეთ ორი იდენტობა მაგალითში

127.0.0.1:1080 არის პროქსის საბოლოო წერტილი, ხელმისაწვდომი ამ Java პროცესიდან. destination და destinationPort იდენტიფიცირებენ საიტს. createUnresolved ინახავს ამ ჰოსტის სახელს SOCKS გზისთვის იმის ნაცვლად, რომ კლიენტზე ადრე გადაწყვიტოს.

შრეებრივი createSocket იღებს დანიშნულების იდენტობას. setEndpointIdentificationAlgorithm("HTTPS") მკაფიოდ ითხოვს მის ჰოსტის სახელის შემოწმებებს. ნედლი SSLSocket-ის სერტიფიკატების ჯაჭვის ნდობა თავისთავად არ ადასტურებს, რომ ჰოსტის სახელის შემოწმება ჩართულია. პროქსის სახელის ან loopback-ის ჩანაცვლება შეუსაბამობის ჩასახშობად შეიძლება არასწორი საბოლოო წერტილი დაამოწმოს.

შეინარჩუნეთ ნდობა და გასუფთავება მათ ეტაპებთან

ნაგულისხმევი ფაბრიკა იყენებს JVM-ის კონფიგურირებულ ნდობის წყობას. კერძო მოთხოვნების მქონე აპლიკაციას შეუძლია ნაცვლად გამოიყენოს თავისი სათანადოდ ინიციალიზებული SSLContext ფაბრიკა. ეს არჩევანი SOCKS მარშრუტისგან დამოუკიდებელია; ნდობის მენეჯერი, რომელიც ყველა სერტიფიკატს იღებს, არასწორ პარტნიორის სახელს არ ასწორებს.

SOCKS-ის უარყოფა ხდება TLS-ამდე; არასანდო სერტიფიკატი ან არასწორი ჰოსტის სახელი მარცხდება TLS-ის დროს; ამის შემდეგ შეიძლება HTTP შეცდომა მოჰყვეს. პროქსიში შესვლა ავტორიზებს გვირაბის მოთხოვნას და არა მის შიგნით არსებული საიტის ავთენტიფიკაციას.

შრეებრივი socket-ის დახურვა ავტომატური დახურვის ჩართული მდგომარეობით ხურავს მის ტრანსპორტს. გარე რესურსის არეალი ასევე ხურავს ამ ტრანსპორტს, თუ გახვევა ან ხელის ჩამორთმევა ვერ მოხერხდა ნორმალურ დასრულებამდე.