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 चे व्याप्ती त्याच्या राउटिंगवर आणि अनुप्रयोग धोरणावर अवलंबून आहे, तीही गृहीत धरण्याऐवजी तपासली पाहिजेत। कोणताही पर्याय केवळ स्थापित झाला म्हणून सर्व काही व्यापत नाही।

प्रत्येक पर्यायासाठी चार ओळी लिहा आणि वाद सहसा स्वतःच सुटतो। उपयुक्त तुलना कोणते लेबल अधिक एन्क्रिप्टेड वाटते ही नाही। तर कोणते विभाग संरक्षित आहेत, त्यांच्या टोकांवर कोणाची पडताळणी होते, कोणत्या मध्यस्थांवर तुम्ही विश्वास ठेवता, आणि धोरण प्रत्यक्षात कोणता रहदारी समाविष्ट करते ही आहे।

संबंधित लेख