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 खाते की रक्षा करता है, और केवल अंतिम जानता है कि आप कौन हैं।