Squid 6.13 में TLS फ़ॉरवर्ड-प्रॉक्सी लिसनर
गंतव्य के HTTPS सेशन को बीच में पकड़े बिना Squid 6.13 में TLS वाला फ़ॉरवर्ड-प्रॉक्सी लिसनर जोड़ें।
GnuTLS या OpenSSL से बना Squid 6.13 TLS पर फ़ॉरवर्ड-प्रॉक्सी अनुरोध स्वीकार कर सकता है। यह HTTPS गंतव्य के अलग सेशन में दखल दिए बिना क्लाइंट–प्रॉक्सी लिंक बचाता है।
- उस होस्टनाम के लिए सर्टिफ़िकेट लें जिससे क्लाइंट Squid तक पहुँचेंगे। उसकी निजी कुंजी केवल ज़रूरत वाले सेवा पहचानकर्ताओं तक सीमित रखें।
- दिए गए पते और असली सर्टिफ़िकेट पथ से TLS लिसनर जोड़ें:
https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pemक्लाइंट अनुमति सूची और गंतव्य प्रतिबंध तथा प्रमाणीकरण नीति बनाए रखें। लिसनर पहुँच की अनुमति नहीं देता। मौजूदा http_port भी सक्रिय रहता है; सभी क्लाइंट कनेक्शन को TLS इस्तेमाल करना हो तो पुराने लिसनर को हटाएँ या सीमित करें। एक्सेलरेटर, इंटरसेप्शन या सर्टिफ़िकेट बनाने का मोड नहीं चाहिए।
संबंधित सेवा फिर लोड करने से पहले कॉन्फ़िगरेशन पार्स करें। पार्सर जाँच संरचना और सर्टिफ़िकेट लोडिंग की पुष्टि करती है, नेटवर्क पहुँच की नहीं। सफल रीलोड के बाद अनुमति वाले क्लाइंट से TLS एंडपॉइंट के ज़रिए अनुरोध करें:
curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/असली प्रॉक्सी होस्टनाम और स्वीकृत CA फ़ाइल इस्तेमाल करें। सार्वजनिक भरोसे वाले प्रॉक्सी सर्टिफ़िकेट को कस्टम बंडल की ज़रूरत न भी हो। --proxy-cacert प्रॉक्सी का भरोसा सेट करता है और गंतव्य सत्यापन अलग रखता है; दोनों जाँच बनाए रखें।
असली लिसनर और सर्टिफ़िकेट नाम जाँचें, फिर नियंत्रित स्रोत भी आज़माएँ जिसे रोका जाना चाहिए। सिर्फ़ सफल पार्सिंग क्लाइंट का भरोसा या पहुँच की सीमा सिद्ध नहीं करती।