Squid से एक अतिरिक्त HTTPS पोर्ट की अनुमति दें
जब स्वीकृत HTTPS सेवा पोर्ट 8443 इस्तेमाल करे, तो Squid 6.13 की दोनों पोर्ट ACL अपडेट करें और गंतव्य का नियम सीमित रखें।
पोर्ट 8443 पर HTTPS सेवा सही तरह से कॉन्फ़िगर किए गए Squid प्रॉक्सी से भी विफल हो सकती है, भले ही 443 पर सामान्य HTTPS काम करता हो। क्लाइंट का प्रॉक्सी प्रोटोकॉल बदलने से पहले CONNECT अस्वीकृति और गंतव्य पोर्ट नीति जाँचें।
Squid 6.13 की सामान्य पहुँच नीति में दो जाँचें अहम हैं: गंतव्य को Safe_ports और CONNECT को SSL_ports से गुजरना चाहिए। पोर्ट को केवल एक ACL में जोड़ने पर दूसरी अस्वीकृति लागू रह सकती है।
मौजूदा परिभाषाओं को सोच-समझकर बढ़ाएँ
सामान्य वेब पोर्ट और एक अतिरिक्त HTTPS पोर्ट की अनुमति देने वाली नीति के लिए:
acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443
संबंधित परिभाषाएँ बदलें या संपादित करें, ताकि पुराने मानों का कोई अनपेक्षित समूह बना न रहे। असुरक्षित पोर्ट और CONNECT को रोकने वाले सामान्य नियमों तथा इच्छित क्लाइंट प्रतिबंधों को बनाए रखें।
अपवाद सीमित रखें
अगर अतिरिक्त पोर्ट केवल एक नियंत्रित गंतव्य के लिए चाहिए, तो क्लाइंट को अनुमति देने वाले नियम से पहले लक्षित अस्वीकृति जोड़ें:
acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_target
यह पता दस्तावेज़ के लिए एक उदाहरण है। उस गंतव्य का उपयोग करें जिसका आप प्रबंधन करते हैं या जहाँ पहुँचने की अनुमति आपके पास है, और उसके पते के वास्तविक बदलावों का ध्यान रखें। इससे 8443 पर हर गंतव्य की अनुमति देने के बजाय अतिरिक्त पोर्ट का अपवाद सीमित रहता है।
पूरे सक्रिय कॉन्फ़िगरेशन का पार्सिंग करें और नियमों का क्रम जाँचें। सही लिखा गया अस्वीकृति नियम भी इच्छित प्रतिबंध नहीं लगाएगा, अगर उसे मेल खाने वाले क्लाइंट अनुमति नियम के बाद रखा गया हो।
स्वीकृत होस्टनाम को उसके वास्तविक प्रमाणपत्र और पोर्ट के साथ जाँचें, फिर ऐसे नियंत्रित गंतव्य को जाँचें जिसे अभी भी अस्वीकृत रहना चाहिए। गंतव्य की पहचान संबंधी त्रुटियों और प्रॉक्सी नीति की त्रुटियों को अलग करने के लिए TLS सत्यापन चालू रखें। किसी कस्टम पोर्ट पर एक अनुरोध चलाने के लिए पूरा CONNECT सुरक्षा नियम न हटाएँ।