HTTPS वर मूलभूत प्रमाणीकरण विरुद्ध IPsec: प्रत्येक काय संरक्षित करते

विकसक साधने उघडा, अंतर्गत ॲप लोड करा आणि पृष्ठ रेंडर होण्यापूर्वी एक विनंती चार तपासणी बिंदूंमधून जाते ते पहा. प्रथम नाव सोडवले जाते, नंतर TCP कनेक्शन उघडते, नंतर TLS हँडशेक सर्व्हर कोण आहे हे निश्चित करते आणि त्यानंतरच अनुप्रयोग विचारतो की तुम्ही कोण आहात. यांना स्वतंत्र घटना माना, कारण प्रत्येक वेगळ्या पुराव्याने अपयशी होते आणि प्रत्येकाची मालकी वेगळ्या संघाकडे आहे. घटनांमधील बहुतेक गोंधळ 401 ला बोगदा समस्या म्हणून वाचण्यातून, किंवा बोगदा समस्येला चुकीचा पासवर्ड म्हणून वाचण्यातून येतो.

तपासणी बिंदू एक: हा तोच सर्व्हर आहे का ज्याच्याशी तुम्हाला बोलायचे होते

कोणतेही क्रेडेन्शियल पाठवण्यापूर्वी TLS हँडशेक त्या प्रश्नाचे उत्तर देतो. तुमचा क्लायंट ट्रस्ट स्टोअरविरुद्ध प्रमाणपत्र साखळी सत्यापित करतो आणि प्रमाणपत्रातील नाव तुम्ही टाइप केलेल्या होस्टशी जुळते का ते तपासतो. ते अपयशी झाल्यास, ब्राउझर प्रमाणपत्र त्रुटी दाखवतो आणि Authorization हेडर अजिबात पाठवत नाही. म्हणून पासवर्डची मागणी सर्व्हर खरा असल्याचा पुरावा नाही; तो अनुप्रयोगाने उत्तर दिल्याचा पुरावा आहे.

येथे पहिली सीमा दिसते. TLS त्याच्या समाप्ती बिंदूपर्यंत कनेक्शनचे संरक्षण करते. जर लोड बॅलन्सर TLS समाप्त करतो आणि अनुप्रयोगाला साधा HTTP पाठवतो, तर एन्क्रिप्टेड विभाग बॅलन्सरवर संपतो, आणि क्रेडेन्शियल फक्त त्या पहिल्या टप्प्यावर संरक्षित असतात.

तपासणी बिंदू दोन: 401 देवघेवीत प्रत्यक्षात काय प्रवास करते

HTTP मूलभूत प्रमाणीकरण वापरकर्ता ओळख आणि पासवर्ड हेडरमध्ये पाठवते, Base64 ने एन्कोड केलेले, वर्णन केल्याप्रमाणे RFC 7617 मध्ये. Authorization: Basic dXNlcjpwYXNz त्याचे स्वरूप आहे; एन्कोडिंग विनंती वाचू शकणारा कोणीही उलटू शकतो, म्हणून सर्व गोपनीयता खालील वाहतुकीतून येते. curl -v दोन्ही WWW-Authenticate: Basic आव्हान आणि तुम्ही परत पाठवलेले हेडर दाखवते.

ते हेडर अनुप्रयोगाला सांगते की कोण विचारत आहे. ते नेटवर्कला सांगत नाही की कोण कनेक्ट करू शकतो, आणि ते स्वतः काहीही एन्क्रिप्ट करत नाही. अनुप्रयोगाला अजूनही स्टोअरविरुद्ध क्रेडेन्शियल तपासावे लागते आणि त्या खात्याला काय करता येईल हे ठरवावे लागते, जे अधिकृतता आहे आणि प्रमाणीकरणानंतर होते.

त्या मार्गात IPsec बोगदा कुठे बसतो

आता ब्राउझरपासून बाहेरच्या दिशेने चला. गेटवे-ते-गेटवे IPsec बोगदा दोन सुरक्षा गेटवेमधील निवडक रहदारीचे संरक्षण करतो, तुमचा लॅपटॉप आणि अनुप्रयोग प्रक्रियेमधील नाही. बोगदा मोड ESP मूळ पॅकेट गुंडाळतो, गेटवे ते एन्क्रिप्ट आणि प्रमाणित करतात, आणि आतील पत्ते टिकून राहतात जेणेकरून दूरची बाजू विनंती अनुप्रयोगाकडे राउट करू शकेल.

निवड हा तो भाग आहे जिथे लोक अडखळतात. धोरण-आधारित बोगदे रहदारी निवडक वापरतात, जे बऱ्याचदा प्रवेश नियंत्रण सूची म्हणून व्यक्त केले जातात, कोणती पॅकेट बोगद्यात प्रवेश करतात हे ठरवण्यासाठी. मार्ग-आधारित बोगदे त्याऐवजी आभासी इंटरफेस आणि राउटिंग तक्ता वापरतात. Linux मध्ये ip xfrm policy निवडक दाखवते आणि ip xfrm state प्रस्थापित सुरक्षा सहयोग दाखवते; फायरवॉल उपकरणात समतुल्य म्हणजे बोगद्याचा SA तक्ता आणि पॅकेट ट्रेसर.

परिणाम स्पष्टपणे सांगण्यासारखा आहे. पॅकेट पूर्णपणे निरोगी बोगद्यात बसू शकते आणि तरीही अनुप्रयोग नाकारतो असा HTTPS विनंती वाहू शकते, आणि वैध क्रेडेन्शियल बोगदा नसलेल्या मार्गानेही येऊ शकतात जर राउटिंग परवानगी देते.

अपयश ज्या स्तराने कळवले त्याच स्तरावर वाचा

401 म्हणजे अनुप्रयोगाने क्रेडेन्शियल स्वीकारले नाही. 403 म्हणजे त्याने ओळख स्वीकारली आणि क्रिया नाकारली. TLS त्रुटी म्हणजे क्लायंटने सर्व्हर स्वीकारला नाही. मार्ग नसणे किंवा धोरण जुळत नसणे म्हणजे पॅकेट कधीच दूरच्या गेटवेपर्यंत पोहोचले नाही. चार वेगवेगळे अपयश, चार वेगवेगळे मालक, आणि लॉगिन फॉर्मकडे पाहून यापैकी कोणाचेही निदान होत नाही.

प्रत्येक स्तर जो पुरावा निर्माण करतो तो वापरा: स्थिती आणि हेडरसाठी ब्राउझरचे नेटवर्क पॅनेल, प्रमाणपत्र साखळीसाठी openssl s_client -connect host:443, बोगदा रहदारीसाठी गेटवेचे SA काउंटर आणि लॉग, आणि खाते निर्णयासाठी अनुप्रयोग लॉग. दोन स्तर एकाच वेळी त्रुटी कळवतात तेव्हा आधी खालचा दुरुस्त करा, कारण मृत बोगदा प्रमाणीकरण अपयश सहजपणे झाकू शकतो आणि उलटही.

एका सेवेचे सुरुवातीपासून शेवटपर्यंत नकाशा काढा

तुम्ही तपासत असलेल्या सेवेसाठी पाच ओळी लिहा: बोगदा कोणत्या सहकाऱ्यांना जोडतो, निवडक कोणत्या उपजाळांना आणि पोर्टना परवानगी देतात, TLS कुठे संपते आणि प्रमाणपत्र कोणती ओळख सांगते, कोणते अनुप्रयोग खाते आणि भूमिका वापरली जाते, आणि प्रत्येक स्तर कुठे लॉग करतो. त्या एका पानावर ठेवा, कारण नकाशाचा उद्देश एका स्तराची जबाबदारी कुठे संपते आणि पुढचा कुठे सुरू होतो हे दाखवणे आहे.

नंतर प्रत्येक स्तरासाठी एक नकारात्मक प्रकरण तपासा. चुकीचा पासवर्ड वापरा आणि तुम्हाला टाइमआउट नाही तर 401 मिळतो याची खात्री करा. निवडकांच्या बाहेरच्या उपजाळातून कनेक्ट करा आणि पॅकेट बोगद्यातून जात नाही याची खात्री करा. चुकीच्या नावासाठी प्रमाणपत्र सादर करा आणि क्रेडेन्शियल पाठवण्यापूर्वी क्लायंट नकारतो याची खात्री करा. ती तीन निकाल तुम्हाला रचनेबद्दल कोणत्याही खोक्यांच्या आकृतीपेक्षा जास्त सांगतात.

शेवटी, प्रत्येक संबंधाला कोणते संरक्षण हवे हे जाणीवपूर्वक ठरवा. TLS वरील मूलभूत प्रमाणीकरण गेटवेच्या मागील लहान अंतर्गत साधनासाठी योग्य निवड आहे; ते प्रति-वापरकर्ता अधिकृतता किंवा TLS अंतिम बिंदूपलीकडील रहदारीच्या संरक्षणाचा पर्याय नाही. बोगदा मार्गाचे, प्रमाणपत्र टप्प्याचे, आणि 401 खात्याचे संरक्षण करते, आणि तुम्ही कोण आहात हे फक्त शेवटच्यालाच माहीत आहे.