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 त्रुटि आ सकती है। प्रॉक्सी लॉगिन टनल अनुरोध को अधिकृत करता है, भीतर की वेबसाइट को प्रमाणित नहीं करता।

स्वतः-बंद सक्षम होने पर परतदार सॉकेट बंद करने से उसका परिवहन बंद हो जाता है। बाहरी संसाधन क्षेत्र भी उस परिवहन को बंद करता है यदि सामान्य पूर्णता से पहले रैपिंग या हैंडशेक विफल हो जाए।

संबंधित लेख