HTTPS प्रोक्सी लेबलले तपाईंको क्लाइन्ट र प्रोक्सीबीचको ढुवानी मात्र वर्णन गर्छ, त्यसभन्दा बढी केही होइन। यसले पछाडिको वेबसाइट त्यही जडानले इन्क्रिप्ट भएको पनि भन्दैन, र प्रोक्सीले पृष्ठ पढ्न सक्छ भनेर पनि भन्दैन। दुई जडान छुट्याएपछि प्रमाणपत्रका त्रुटिहरू रहस्यमय रहन छोड्छन् र VPN सँगको तुलना ठोस हुन्छ।

दुई छेउका जोडी, दुई प्रमाणीकरण

सामान्य टनेल मोडमा दुई TLS सम्बन्ध हुन्छन्। पहिलो तपाईंको क्लाइन्टबाट प्रोक्सीसम्म जान्छ र प्रोक्सीलाई प्रमाणित गर्छ। दोस्रो तपाईंको क्लाइन्टबाट टनेलभित्रको वेबसाइटसम्म जान्छ र वेबसाइटलाई प्रमाणित गर्छ। ती स्वतन्त्र रूपमा असफल हुन्छन् र स्वतन्त्र रूपमा कन्फिगर हुन्छन्।

तिनका फरक विश्वास निर्णय, फरक प्रमाणपत्र शृंखला र फरक असफलता सन्देश छन्। संस्थागत CA प्रयोग गर्ने प्रोक्सी र सार्वजनिक शृंखला प्रयोग गर्ने सार्वजनिक वेबसाइटलाई वैध रूपमा फरक प्रमाणीकरण कन्फिगरेसन आवश्यक पर्न सक्छ, र त्यो गलत कन्फिगरेसन होइन।

तिनलाई एउटै सकेट साझा गर्ने दुई जडानका रूपमा लिनुहोस्, किनकि ती त्यस्तै हुन्।

CONNECT ले वास्तवमा के टनेल गर्छ

क्लाइन्टले होस्ट र पोर्टको नाम दिएर CONNECT अनुरोध पठाउँछ, र प्रोक्सीले त्यो लक्ष्यमा TCP जडान खोल्छ। प्रोक्सीले जवाफ दिएपछि आउने बाइटहरू कुनै व्याख्याविना रिले गरिन्छन्, त्यसैले वेबसाइटको TLS ह्यान्डशेक प्रोक्सीबाट अछूतो गुज्रन्छ। यसरी प्रोक्सीले गन्तव्यको नाम र जडानको मेटाडेटा थाहा पाउँछ, तर त्यो व्यवस्थाबाट डिक्रिप्ट गरिएका पृष्ठहरू पाउँदैन।

त्यो भिन्नता नै टनेल मोडको सम्पूर्ण सुरक्षा तर्क हो, र त्यही यसको सीमा पनि हो।

प्रोक्सी हपमा TLS नभएको HTTP प्रोक्सीले पनि CONNECT मार्फत HTTPS वेबसाइट बोक्छ। क्लाइन्ट-देखि-प्रोक्सी आदानप्रदान खुला हुन्छ जबकि वेबसाइट जडान हुँदैन, र सम्पूर्ण कुरालाई HTTPS प्रोक्सी भन्नु त्यो भिन्नता लुकाउँछ।

कुन प्रमाणपत्र असफल भयो

प्रमाणीकरण असफल हुँदा, कुनै पनि विश्वास सेटिङ बदल्नु अघि त्रुटिमा नाम दिइएको छेउ पढ्नुहोस्। दुई असफलता टर्मिनलमा उस्तै देखिन्छन् र पूर्ण रूपमा फरक सुधारतर्फ संकेत गर्छन्, त्यसैले पहिलो प्रश्न सधैं कुन जडानले अस्वीकार गर्यो भन्ने हुन्छ।

curl ले ठ्याक्कै यही कारणले विकल्पहरू अलग राख्छ। प्रोक्सीको CA फाइलले प्रोक्सीको प्रमाणीकरण कन्फिगर गर्छ, CA फाइलले सर्भरको प्रमाणीकरण कन्फिगर गर्छ, र लागू हुने ट्रस्ट स्टोरको व्यवहार पनि curl कसरी बनाइयो भन्नेमा निर्भर गर्छ।

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

जाँच दबाउनु मर्मत होइन। यसले दुईमध्ये कुनै पनि छेउको बारेमा केही प्रमाणित गर्दैन।

निरीक्षण अर्कै व्यवस्था हो

TLS निरीक्षण टनेलिङ होइन। निरीक्षण गर्ने मध्यस्थले वेबसाइटतर्फको विश्वास सम्बन्ध अन्त्य गर्छ र क्लाइन्टलाई आफ्नै प्रमाणपत्र प्रस्तुत गर्छ, त्यसैले क्लाइन्टले साइटको सट्टा मध्यस्थलाई प्रमाणित गर्छ। स्वीकृत डिजाइनअन्तर्गत यो वैध हुन सक्छ, र यो बाइट-बाइट रिलेभन्दा मौलिक रूपमा फरक दाबी हो। हरेक प्रोक्सीले निरीक्षण गर्छ भन्ने नमान्नुहोस्, र इन्क्रिप्टेड प्रोक्सी हपले त्यो हटाउँछ भन्ने पनि नमान्नुहोस्।

तपाईंको ट्रस्ट स्टोरमा रहेको संस्थागत CA कुन व्यवस्थामा हुनुहुन्छ भन्ने संकेत हो, प्रमाण होइन। प्रमाणपत्र शृंखलाबाट अनुमान गर्नुको सट्टा डिजाइन सोध्नुहोस्।

ती दुई व्यवस्थाले पृष्ठ को पढ्न सक्छ भन्ने प्रश्नमा फरक उत्तर दिन्छन्।

एउटै चार लाइनमा प्रोक्सी र VPN तुलना गर्नुहोस्

दुवै परिनियोजन एउटै तरिकाले वर्णन गरेपछि मात्र तुलना उपयोगी हुन्छ।

LineWhat to state
Protected segmentsWhich hops are encrypted, and between which endpoints
Verified identitiesWhat each end proves, and against which trust anchor
Trusted intermediariesWho can read or alter traffic by design
Traffic includedWhich processes and destinations the policy actually covers

एउटा अनुरोधका लागि कन्फिगर गरिएको प्रोक्सीले त्यो अनुरोध समेट्छ। यसले यन्त्रको हरेक प्रक्रिया आफूबाट जान दिँदैन, र उदाहरणको आदेश ठ्याक्कै त्यति साँघुरो छ। VPN को कभरेज यसको राउटिङ र अनुप्रयोग नीतिमा निर्भर हुन्छ, ती पनि मान्नुको सट्टा जाँच्नुपर्छ। कुनै पनि विकल्पले केवल स्थापना भयो भन्ने कारणले सबै कुरा समेट्दैन।

प्रत्येक विकल्पका लागि चार लाइन लेख्नुहोस् र बहस प्रायः आफैं टुंगिन्छ। उपयोगी तुलना कुन लेबल बढी इन्क्रिप्टेड सुनिन्छ भन्ने होइन। बरु कुन खण्ड सुरक्षित छन्, तिनका छेउमा को प्रमाणित हुन्छ, कुन मध्यस्थमा तपाईं विश्वास गर्नुहुन्छ, र नीतिले वास्तवमा कुन ट्राफिक समेट्छ भन्ने हो।

सम्बन्धित लेखहरू