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 ले खाता सुरक्षित गर्छ, र तपाईं को हुनुहुन्छ भन्ने अन्तिमलाई मात्र थाहा छ।