मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 6.858। "कंप्यूटर सिस्टम की सुरक्षा।" निकोलाई ज़ेल्डोविच, जेम्स मिकेंस। 2014 साल
कंप्यूटर सिस्टम सुरक्षा सुरक्षित कंप्यूटर सिस्टम के विकास और कार्यान्वयन पर एक कोर्स है। व्याख्यान खतरे के मॉडल को कवर करते हैं, हमले जो सुरक्षा से समझौता करते हैं, और हाल के वैज्ञानिक कार्यों के आधार पर सुरक्षा तकनीक। विषय में ऑपरेटिंग सिस्टम (OS) सुरक्षा, सुविधाएँ, सूचना प्रवाह प्रबंधन, भाषा सुरक्षा, नेटवर्क प्रोटोकॉल, हार्डवेयर सुरक्षा और वेब अनुप्रयोग सुरक्षा शामिल हैं।
व्याख्यान 1: "परिचय: खतरे के मॉडल"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 2: "हैकर हमलों का नियंत्रण"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 3: "बफर ओवरफ्लो: शोषण और संरक्षण"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 4: "पृथक्करण का पृथक्करण"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 5: "सुरक्षा प्रणालियाँ कहाँ से आती हैं?"
भाग 1 /
भाग 2व्याख्यान 6: "अवसर"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 7: "मूल ग्राहक सैंडबॉक्स"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 8: "नेटवर्क सुरक्षा मॉडल"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 9: "वेब अनुप्रयोग सुरक्षा"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 10: "प्रतीकात्मक निष्पादन"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 11: "उर / वेब प्रोग्रामिंग भाषा"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 12: नेटवर्क सुरक्षा
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 13: "नेटवर्क प्रोटोकॉल"
भाग 1 /
भाग 2 /
भाग 3व्याख्यान 14: "एसएसएल और एचटीटीपीएस"
भाग 1 /
भाग 2 /
भाग 3 पहला कारण यह है कि OCSP प्रोटोकॉल आपके द्वारा किए गए प्रत्येक अनुरोध में देरी को जोड़ता है। हर बार जब आप किसी सर्वर से जुड़ना चाहते हैं, तो आपको सबसे पहले OCSP से कनेक्ट होना होगा, इसके जवाब के लिए इंतजार करना होगा और फिर कुछ और करना होगा। इसलिए कनेक्शन देरी इस प्रोटोकॉल की लोकप्रियता में योगदान नहीं करती है।
दूसरा कारण यह है कि आप नहीं चाहते कि OCSP वेब ब्राउज़ करने की आपकी क्षमता को प्रभावित करे। मान लीजिए कि OSCP सर्वर डाउन है, और फिर आप पूरी तरह से इंटरनेट खो सकते हैं, क्योंकि प्रोटोकॉल मानता है कि चूंकि यह किसी के प्रमाण पत्र को सत्यापित नहीं कर सकता है, तो शायद इंटरनेट पर सभी साइटें खराब हैं और आपको वहां जाने की अनुमति नहीं दी जानी चाहिए। लेकिन किसी को इसकी आवश्यकता नहीं है, इसलिए अधिकांश ग्राहक सकारात्मक विकास के रूप में OCSP सर्वर को गैर-हस्तक्षेप करते हैं।
यह सुरक्षा के दृष्टिकोण से बहुत बुरा है। क्योंकि यदि आप एक हमलावर हैं और किसी को यह विश्वास दिलाना चाहते हैं कि आपके पास एक कानूनी प्रमाण पत्र है, लेकिन वास्तव में यह प्रमाण पत्र निरस्त कर दिया गया है, तो आपको बस किसी तरह क्लाइंट को OCSP सर्वर के साथ संचार करने से रोकना होगा।
क्लाइंट यह कहेगा: "मैं उस साइट के प्रमाण पत्र सत्यापन का अनुरोध करने का प्रयास कर रहा हूं जिसकी मुझे आवश्यकता है, लेकिन यह OCSP, ऐसा लगता है, पास नहीं है, इसलिए मैं सिर्फ इस साइट पर जाता हूं।" इसलिए OCSP का उपयोग करना एक अच्छी योजना नहीं है।
व्यवहार में, लोग इस विकल्प को बनाने की कोशिश करते हैं, क्योंकि ग्राहक केवल गंभीर गलतियां करते हैं। इसलिए, उदाहरण के लिए, क्रोम वेब ब्राउज़र क्लाइंट को दिया जाता है, पहले से ही अपने आप में उन प्रमाणपत्रों की एक सूची है जो Google वास्तव में रद्द करना चाहता है। इसलिए यदि कोई गलत तरीके से जीमेल या किसी अन्य महत्वपूर्ण साइट, जैसे कि फेसबुक या अमेज़ॅन के लिए एक प्रमाण पत्र जारी करता है, तो क्रोम के अगले संस्करण में पहले से ही अंतर्निहित सत्यापन सूची में यह जानकारी होगी। इस तरह से आपको CRL सर्वर तक पहुंचने और OCSP के साथ संवाद करने की आवश्यकता नहीं है। यदि ब्राउज़र ने सत्यापित किया है कि प्रमाण पत्र अब मान्य नहीं है, तो क्लाइंट इसे अस्वीकार कर देता है।
छात्र: मान लीजिए कि मैंने CA गुप्त कुंजी चुरा ली है, क्योंकि सभी सार्वजनिक कुंजी एन्क्रिप्ट नहीं हैं?
प्रोफेसर: हाँ, इसके बुरे परिणाम होंगे। मुझे नहीं लगता कि इस समस्या का कोई समाधान है। बेशक, ऐसे हालात थे जब प्रमाणन केंद्रों से समझौता किया गया था, उदाहरण के लिए, 2011 में दो समझौता किए गए सीए थे जिन्होंने किसी तरह जीमेल, फेसबुक और इतने पर प्रमाण पत्र जारी किए। यह स्पष्ट नहीं है कि यह कैसे हुआ, शायद किसी ने वास्तव में उनकी गुप्त कुंजी चुरा ली। लेकिन समझौते के कारणों की परवाह किए बिना, इन सीए को विश्वसनीय प्रमाणपत्र अधिकारियों की सूची से हटा दिया गया था, जो ब्राउज़र में बनाया गया है, इसलिए वे अब क्रोम की अगली रिलीज़ में नहीं थे।
वास्तव में, इससे इन केंद्रों द्वारा जारी किए गए प्रमाणपत्रों के वैध धारकों के लिए परेशानी हुई, क्योंकि उनके पिछले प्रमाण पत्र अमान्य हो गए थे और उन्हें नए प्रमाण पत्र प्राप्त करने थे। तो व्यवहार में, प्रमाण पत्र के साथ यह सब उपद्रव एक भ्रामक मामला है।
इसलिए, हमने प्रमाणपत्रों के सामान्य सिद्धांत की जांच की है। वे इस अर्थ में केर्बोस से बेहतर हैं कि आपको हर समय ऑनलाइन रहने के लिए इस आदमी की आवश्यकता नहीं है। इसके अलावा, वे अधिक मापनीय हैं, क्योंकि आपके पास कई केडीसी हो सकते हैं और हर बार जब आप कनेक्शन स्थापित करते हैं तो आपको उनके साथ संवाद करने की आवश्यकता नहीं होती है।
इस प्रोटोकॉल की एक और दिलचस्प विशेषता यह है कि केर्बरोस के विपरीत, आपको कनेक्शन के दोनों किनारों को प्रमाणित करने की आवश्यकता नहीं है। आप अपने लिए एक प्रमाणपत्र के बिना वेब सर्वर से कनेक्ट कर सकते हैं, और यह हर समय होता है। यदि आप amazon.com पर जाते हैं, तो आप यह जांचने जा रहे हैं कि अमेज़ॅन सही साइट है, लेकिन अमेज़ॅन को पता नहीं है कि आप कौन हैं और जब तक आप साइट को प्रमाणित नहीं करते, तब तक आपको इसके बारे में पता नहीं चलेगा। इस प्रकार, एन्क्रिप्शन प्रोटोकॉल के स्तर पर आपके पास एक प्रमाण पत्र नहीं है, लेकिन अमेज़ॅन के पास एक है।
यह केर्बरोस की तुलना में बहुत बेहतर है, क्योंकि कर्बरोस सेवाओं से जुड़ने के लिए आपके डेटाबेस में इसकी प्रविष्टि होनी चाहिए। इस प्रोटोकॉल का उपयोग करने की एकमात्र असुविधा यह है कि सर्वर के पास एक प्रमाण पत्र होना चाहिए। तो आप सर्वर से कनेक्ट नहीं कर सकते हैं और कह सकते हैं, "हे, चलो बस हमारी चीजों को एन्क्रिप्ट करें। मुझे पता नहीं है कि आप कौन हैं, लेकिन आपको पता नहीं है कि मैं कौन हूं, लेकिन चलो इसे वैसे भी एन्क्रिप्ट करें। " इसे अवसरवादी एन्क्रिप्शन कहा जाता है, और निश्चित रूप से, यह मध्य-मध्य हमलों के लिए संवेदनशील है। आप किसी के साथ सामान्य चीजों को एन्क्रिप्ट कर सकते हैं, उसे जानने के बिना, फिर एक हमलावर जो आप पर हमला करने की तैयारी कर रहा है, वह बाद में अपने पैकेटों को भी एन्क्रिप्ट कर सकता है और खुद को स्नूपिंग से बचा सकता है।
इसलिए यह थोड़ा अफ़सोस की बात है कि ये प्रोटोकॉल जो हम यहाँ पर विचार कर रहे हैं - एसएसएल, टीएलएस - इस तरह के अवसरवादी एन्क्रिप्शन की पेशकश नहीं करते हैं। लेकिन ऐसी जिंदगी है।
छात्र: मैं बस उत्सुक हूं। मान लें कि वर्ष में एक बार, वे नए नामों के साथ प्रमुख जोड़े बनाते हैं। क्यों साल भर इस विशेष कुंजी का उपयोग करने की कोशिश नहीं की?
प्रोफेसर: मुझे लगता है कि वे ऐसा करते हैं। लेकिन इस सर्किट में कुछ गलत हो रहा है। यहां, केर्बरोस के साथ, लोग मजबूत एन्क्रिप्शन का उपयोग करके शुरू करते हैं, लेकिन समय के साथ यह खराब और बदतर हो जाता है। कंप्यूटर तेजी से बन रहे हैं, नए एल्गोरिदम विकसित किए जा रहे हैं जो सफलतापूर्वक इस एन्क्रिप्शन को क्रैक करते हैं। और अगर लोग विश्वसनीयता में सुधार की परवाह नहीं करते हैं, तो समस्याएं बढ़ती हैं। इसलिए, उदाहरण के लिए, यह तब होता है जब बड़ी संख्या में प्रमाण पत्र पर हस्ताक्षर किए जाते हैं।
यहां दो बारीकियां हैं। एक सार्वजनिक कुंजी हस्ताक्षर योजना है। इसके अलावा, यह देखते हुए कि एन्क्रिप्ट की गई सार्वजनिक कुंजी में कुछ सीमाएँ हैं, जब किसी संदेश पर हस्ताक्षर करते हैं, तो वास्तव में, केवल इस संदेश के हैश पर हस्ताक्षर किए जाते हैं, क्योंकि एक विशाल संदेश पर हस्ताक्षर करना मुश्किल है, लेकिन एक कॉम्पैक्ट हैश पर हस्ताक्षर करना आसान है।
समस्या इसलिए पैदा हुई क्योंकि लोगों ने एमडी 5 का उपयोग एक हैश फ़ंक्शन के रूप में किया, एक विशाल संदेश के हस्ताक्षर को 128-बिट चीज़ में बदल दिया जिसे एन्क्रिप्ट किया गया था। शायद एमडी 5 20 साल पहले अच्छा था, लेकिन समय के साथ, लोगों ने इसमें कमजोरियों की खोज की जो एक हमलावर द्वारा शोषण की जा सकती है।
मान लीजिए किसी बिंदु पर किसी ने वास्तव में एक विशिष्ट एमडी 5 हैश के साथ एक प्रमाण पत्र के लिए पूछा, और फिर ध्यान से एक और संदेश को छोड़ दिया जो उसी एमडी 5 मूल्य के साथ हैशेड था। नतीजतन, उनके पास एक हैशेड सीए हस्ताक्षर था, और फिर एक अन्य संदेश दिखाई दिया, या एक अलग कुंजी, या एक अलग नाम, और अब वह किसी को समझा सकता है कि यह सही प्रमाण पत्र के साथ हस्ताक्षरित है। और यह वास्तव में हो रहा है। उदाहरण के लिए, यदि आप एक कुंजी को क्रैक करने में बहुत समय बिताते हैं, तो आप अंततः सफल होंगे। यदि यह प्रमाणपत्र एन्क्रिप्शन का उपयोग करता है, तो इसे ब्रूट-बल विधि का उपयोग करके क्रैक किया जा सकता है।
एन्क्रिप्शन के असफल उपयोग का एक और उदाहरण RSA एल्गोरिथम है। हम आरएसए के बारे में बात नहीं करते थे, लेकिन आरएसए इन सार्वजनिक-कुंजी क्रिप्टोग्राफ़िक प्रणालियों में से एक है जो आपको संदेशों को एन्क्रिप्ट करने और हस्ताक्षर करने की अनुमति देता है। इन दिनों आप बहुत सारा पैसा खर्च कर सकते हैं, लेकिन अंत में, 1000-बिट आरएसए कुंजी को क्रैक करें। आपको संभवतः एक विशाल मात्रा में काम करना होगा, लेकिन यह पूरे वर्ष में करना आसान है। आप प्रमाणीकरण प्राधिकारी से एक संदेश पर हस्ताक्षर करने या किसी की मौजूदा सार्वजनिक कुंजी लेने के लिए कह सकते हैं, इसके लिए उपयुक्त गुप्त कुंजी खोजने का प्रयास कर सकते हैं या इसे हैक कर सकते हैं।
इस प्रकार, आपको हमलावर के साथ रहना चाहिए, आपको बड़े आरएसए कुंजी का उपयोग करना चाहिए या एक अलग एन्क्रिप्शन योजना का उपयोग करना चाहिए।
उदाहरण के लिए, अब लोग MD5 हैश और प्रमाणपत्र का उपयोग नहीं करते हैं। वे SHA-1 क्रिप्टोग्राफिक हैशिंग एल्गोरिथ्म का उपयोग करते हैं। कुछ समय के लिए इसने आवश्यक सुरक्षा प्रदान की, लेकिन आज यह एक कमजोर रक्षा है। अब Google सक्रिय रूप से वेब और ब्राउज़र डेवलपर्स को SHA-1 का उपयोग छोड़ने और एक अलग हैश फ़ंक्शन का उपयोग करने के लिए मजबूर करने की कोशिश कर रहा है, क्योंकि यह काफी स्पष्ट है कि, शायद, 5 या 10 साल बाद SHA-1 पर सफलतापूर्वक हमला करना मुश्किल नहीं होगा। उसकी कमजोरी पहले ही साबित हो चुकी है।
तो, मुझे लगता है, इस तरह के रूप में जादू की गोली मौजूद नहीं है। आपको बस यह सुनिश्चित करना है कि आप हैकर्स के समानांतर विकास करना जारी रखें। बेशक, समस्या मौजूद है। इसलिए, हमने जिन सभी चीजों के बारे में बात की है, वे उचित एन्क्रिप्शन पर आधारित होनी चाहिए, या इस तथ्य पर कि यह दरार करना बहुत मुश्किल है। इसलिए, आपको उचित विकल्प चुनना होगा। कम से कम एक समाप्ति तिथि है, इसलिए 10 वर्ष की बजाय 1 वर्ष की समाप्ति तिथि चुनना बेहतर है।
यह CA कुंजी एक अधिक गंभीर समस्या पैदा करती है, क्योंकि इसकी समाप्ति तिथि नहीं होती है। इसलिए, आपको अधिक आक्रामक सुरक्षा सेटिंग्स चुननी चाहिए, उदाहरण के लिए, 4000 या 6000 बिट आरएसए कुंजी, या कुछ और। या एक अलग एन्क्रिप्शन योजना, या सभी एक साथ, लेकिन यहां SHA-1 का उपयोग न करें।
अब देखते हैं कि हम इस प्रोटोकॉल को एक विशिष्ट अनुप्रयोग में कैसे एकीकृत करते हैं, अर्थात् एक वेब ब्राउज़र। यदि आप क्रिप्टोग्राफी का उपयोग करने वाली साइटों के साथ नेटवर्क संचार या संचार प्रदान करना चाहते हैं, तो ब्राउज़र में तीन चीजें हैं जिन्हें हमें संरक्षित करना चाहिए।
पहली बात, A नेटवर्क पर डेटा सुरक्षा है। यह अपेक्षाकृत आसान है क्योंकि हम अभी तक मेरे द्वारा वर्णित एक प्रोटोकॉल के समान चलने जा रहे हैं। हम सभी संदेशों को एन्क्रिप्ट करेंगे, उन्हें साइन इन करेंगे, सुनिश्चित करें कि उनके साथ छेड़छाड़ नहीं की गई है, सामान्य तौर पर, हम इन सभी अद्भुत चीजों को करेंगे। इस प्रकार हम डेटा की सुरक्षा करेंगे।
लेकिन वेब ब्राउज़र में दो और चीजें हैं जिनके बारे में हमें वास्तव में चिंता करने की आवश्यकता है। तो, पहला, बी, कोड है जो ब्राउज़र में उपयोग किया जाता है, उदाहरण के लिए, जावास्क्रिप्ट या महत्वपूर्ण डेटा जो ब्राउज़र में संग्रहीत किया जाता है, आपके कुकीज़, या स्थानीय भंडारण, यह सब किसी भी तरह हैकर्स से सुरक्षित होना चाहिए। एक दूसरे में मैं आपको बताऊंगा कि उन्हें कैसे संरक्षित किया जाए।
अंतिम एक, सी, जिसके बारे में आप अक्सर सोचते नहीं हैं, लेकिन जो व्यवहार में एक वास्तविक समस्या हो सकती है, वह यूजर इंटरफेस की रक्षा कर रही है। और इसका कारण यह है कि, अंततः, अधिकांश गोपनीय डेटा जो हम सुरक्षा के बारे में परवाह करते हैं, उपयोगकर्ता से आता है। इसलिए, उपयोगकर्ता किसी साइट पर डेटा प्रिंट करता है, और संभवत: उसके पास अलग-अलग साइटों के कई टैब एक साथ खुलते हैं, इसलिए उसे यह पता लगाने में सक्षम होना चाहिए कि वह किस साइट पर वास्तव में किसी भी समय बातचीत कर रहा है।
यदि वह गलती से किसी वेब फोरम पर अमेज़ॅन पासवर्ड में प्रवेश करता है, तो इससे विनाशकारी परिणाम नहीं होंगे, यह निर्भर करता है कि वह अपने अमेज़ॅन पासवर्ड की कितनी परवाह करता है, लेकिन फिर भी यह अप्रिय होगा। इसलिए, आप वास्तव में एक अच्छा उपयोगकर्ता इंटरफ़ेस रखना चाहते हैं जो उपयोगकर्ता को यह समझने में मदद करता है कि वह क्या कर रहा है, क्या वह सही साइट पर संवेदनशील डेटा प्रिंट करता है और यदि वह भेजने के बाद इस डेटा के साथ कुछ होता है। तो यह वेब अनुप्रयोगों की सुरक्षा के लिए एक बहुत महत्वपूर्ण मुद्दा बन जाता है।
तो, आइए इन ए, बी और सी चीजों के साथ आधुनिक ब्राउज़र क्या करते हैं, इसके बारे में बात करते हैं। जैसा कि मैंने उल्लेख किया है, नेटवर्क पर डेटा की सुरक्षा के लिए, हम बस इस प्रोटोकॉल का उपयोग करेंगे, जिसे एसएसएल या टीएलएस कहा जाता है, अगर एन्क्रिप्शन और प्रमाणीकरण का उपयोग किया जाता है।
यह बहुत कुछ वैसा ही है जैसा हमने चर्चा की थी, और इसमें प्रमाणपत्र प्राधिकारी आदि शामिल हैं। और फिर, ज़ाहिर है, कई और अधिक विवरण हैं। उदाहरण के लिए, टीएलएस अत्यंत जटिल है, लेकिन हम इसे इस दृष्टिकोण से नहीं मानेंगे। हम ब्राउज़र सुरक्षा पर ध्यान केंद्रित करेंगे, जो कि अधिक दिलचस्प है। हमें यह सुनिश्चित करने की आवश्यकता है कि अनएन्क्रिप्टेड कनेक्शन पर दिया गया कोई भी कोड या डेटा एन्क्रिप्टेड कनेक्शन से प्राप्त कोड और डेटा को बदलने में सक्षम नहीं है, क्योंकि हमारा खतरा मॉडल ऐसा है कि सभी अनएन्क्रिप्टेड डेटा को नेटवर्क पर एक हमलावर द्वारा फेक किया जा सकता है।
इसलिए अगर हमारे पास हमारे ब्राउज़र में चलने वाले कुछ प्रकार के अनएन्क्रिप्टेड जावास्क्रिप्ट कोड हैं, तो हमें यह मान लेना चाहिए कि यह एक हमलावर द्वारा छेड़छाड़ किया जा सकता था क्योंकि यह एन्क्रिप्ट नहीं किया गया था। इसने नेटवर्क पर प्रमाणित नहीं किया। और, इसलिए, हमें किसी भी पृष्ठ से इसके हस्तक्षेप को रोकना चाहिए जो एक अनएन्क्रिप्टेड कनेक्शन के माध्यम से दिया गया था।
इस प्रकार, सामान्य योजना यह है कि इसके लिए हम एक नई URL योजना शुरू करने जा रहे हैं, जिसे हम HTTPS कहेंगे। आप अक्सर इसे urls में देखते हैं। नई URL स्कीम यह है कि अब ये URL HTTP एड्रेस से अलग हैं। इसलिए यदि आपके पास इस HTTPS: // के साथ एक URL है, तो इसका नियमित HTTP URL की तुलना में एक अलग मूल स्रोत है, क्योंकि उत्तरार्द्ध अनएन्क्रिप्टेड पैच के माध्यम से जाते हैं, वे एसएसएल / टीएलएस से गुजरते हैं। इस तरह से आप कभी भी इस प्रकार के पतों को भ्रमित नहीं करेंगे यदि एक ही मूल नीति सही ढंग से काम करती है।
तो यह पहेली का एक टुकड़ा है। लेकिन फिर आपको यह भी सुनिश्चित करने की आवश्यकता है कि आप एन्क्रिप्टेड साइटों को एक-दूसरे से सही रूप से अलग करते हैं, क्योंकि ऐतिहासिक कारणों से वे विभिन्न कुकी नीतियों का उपयोग करते हैं। तो चलिए पहले बात करते हैं कि हम अलग-अलग एन्क्रिप्टेड साइटों को एक-दूसरे से कैसे अलग करेंगे।
योजना यह है कि URL के माध्यम से होस्टनाम प्रमाणपत्र में नाम होना चाहिए। वास्तव में, यह पता चला है कि प्रमाणीकरण प्राधिकारी होस्ट नाम पर हस्ताक्षर करने जा रहे हैं, जो URL में वेब सर्वर की सार्वजनिक कुंजी के नाम के रूप में दिखाई देता है। जैसे, अमेजन
www.amazon.com के लिए कथित तौर पर एक प्रमाण पत्र रखता है। यह हमारी तालिका का नाम है जिसमें सार्वजनिक कुंजी उनकी निजी कुंजी के अनुरूप है।
यह वही है जो ब्राउज़र के लिए दिखेगा। इसलिए यदि वह एक प्रमाण पत्र प्राप्त करता है, अगर वह
foo.com URL को जोड़ने या प्राप्त करने का प्रयास करता है, तो इसका मतलब है कि सर्वर सही रूप से प्रामाणिक fy.com प्रमाणपत्र का प्रतिनिधित्व करता है। अन्यथा, कहते हैं, हमने एक आदमी से संपर्क करने की कोशिश की, और दूसरे से संपर्क किया, क्योंकि प्रमाण पत्र में वह पूरी तरह से अलग नाम है जिसे हमने कनेक्ट किया था। यह एक सर्टिफिकेट मिसमैच होगा।
यहां बताया गया है कि हम विभिन्न साइटों को एक-दूसरे से कैसे अलग करेंगे: हम इन साइटों को एक-दूसरे से अलग करने में मदद करने के लिए सीए लाएंगे, क्योंकि सीए केवल सही नेटवर्क के सदस्यों को प्रमाण पत्र जारी करने का वादा करते हैं। तो यह उसी मूल नीति का हिस्सा है, जिसके अनुसार हम कोड को भागों में विभाजित करते हैं। जैसा कि आप याद करते हैं, कुकीज़ की एक अलग नीति है। वे लगभग एक ही मूल के हैं, लेकिन काफी नहीं, कुकीज़ की योजना थोड़ी अलग है। कुकीज़ में एक तथाकथित सुरक्षा ध्वज, सुरक्षित ध्वज होता है। नियम यह है कि यदि कुकीज़ में यह ध्वज है, तो वे केवल HTTPS अनुरोधों के जवाब में या HTTPS अनुरोधों के साथ भेजे जाते हैं। बिना किसी सुरक्षा ध्वज के कुकीज़ https और http अनुरोध के रूप में एक दूसरे से संबंधित हैं।
यह थोड़ा जटिल है। यह आसान होगा यदि एक कुकी ने केवल यह संकेत दिया कि यह HTTPS होस्ट के लिए एक कुकी थी, और यह HTTP होस्ट के लिए एक कुकी थी, और वे पूरी तरह से अलग थीं। यह सुरक्षित साइटों को असुरक्षित लोगों से अलग करने के संदर्भ में बहुत स्पष्ट होगा। दुर्भाग्य से, ऐतिहासिक कारणों से, कुकीज़ इस अजीब तरह की बातचीत का उपयोग करती हैं।
इसलिए, यदि कोई कुकी सुरक्षित के रूप में चिह्नित है, तो यह केवल HTTPS साइटों पर लागू होती है, अर्थात इसमें सही होस्ट है। सुरक्षित कुकीज़ केवल HTTPS होस्ट URL पर लागू होती हैं, जबकि असुरक्षित कुकीज़ https और http दोनों के लिए दोनों प्रकार के URL पर लागू होती हैं, इसलिए केवल एक सेकंड में यह हमारे लिए समस्याओं का स्रोत बन जाएगा।
और अंतिम स्पर्श जो वेब ब्राउज़र इस संबंध में हमारी मदद करने के लिए करने की कोशिश करते हैं, वह उपयोगकर्ता इंटरफ़ेस का पहलू है जिसमें वे किसी प्रकार के लॉक आइकन में प्रवेश करने जा रहे हैं ताकि उपयोगकर्ता इसे देख सकें। इस प्रकार, आपको ब्राउज़र और एड्रेस यूआरएल में लॉक आइकन पर ध्यान देना चाहिए ताकि यह पता लगाया जा सके कि आप वास्तव में किस साइट पर स्थित हैं।
वेब ब्राउज़र डेवलपर्स उम्मीद करते हैं कि आप इस तरह से व्यवहार करेंगे: एक बार जब आप किसी वेबसाइट पर पहुंचते हैं, तो आप पहले URL को देखते हैं और सुनिश्चित करते हैं कि यह उस होस्ट का नाम है जिससे आप बात करना चाहते हैं, और फिर आपको लॉक आइकन मिलेगा और समझते हैं कि सब कुछ ठीक है। यह ब्राउजर यूजर इंटरफेस का एक पहलू है।
हालांकि, यह पर्याप्त नहीं है। यह पता चला है कि कई फ़िशिंग साइटें केवल साइट में लॉक आइकन की छवि को शामिल करेंगी, लेकिन एक अलग URL का उपयोग करें। और अगर आपको नहीं पता है कि इस साइट का पता क्या होना चाहिए, तो आपको धोखा हो सकता है। इस अर्थ में, उपयोगकर्ता इंटरफ़ेस का यह पक्ष थोड़ा भ्रामक है, भाग में क्योंकि उपयोगकर्ता स्वयं अक्सर भ्रमित होते हैं। इसलिए यह कहना मुश्किल है कि यहाँ क्या है। इसलिए, हम मुख्य रूप से दूसरे पहलू बी पर ध्यान केंद्रित करेंगे, जिस पर चर्चा करना निश्चित रूप से बहुत आसान है। इस बारे में प्रश्न हैं?
छात्र: मैंने देखा कि कुछ साइटें HTTP से HTTPS तक समय के साथ बदल जाती हैं।
प्रोफेसर: हाँ, ब्राउज़र समय के साथ विकसित होते हैं, और इस तथ्य की पुष्टि की जाती है कि उन्हें लॉक आइकन मिलता है। कुछ ब्राउज़र केवल एक लॉक आइकन सेट करते हैं, यदि आपके पेज पर सभी सामग्री या सभी संसाधन भी https के माध्यम से प्रसारित होते हैं। तो एक समस्या है कि HTTPS को बल द्वारा हल करने की कोशिश की जा रही है मिश्रित सामग्री या असुरक्षित प्रकार की सामग्री के साथ पृष्ठ में एम्बेडेड सामग्री। इसलिए, कभी-कभी आप इस चेक के कारण लॉक आइकन प्राप्त नहीं कर पाएंगे। यदि क्रोम ब्राउज़र मानता है कि साइट प्रमाणपत्र पर्याप्त अच्छा नहीं है और कमजोर क्रिप्टोग्राफी का उपयोग करता है, तो यह आपको लॉक आइकन नहीं देगा। हालांकि, अलग-अलग ब्राउज़र अलग-अलग कार्य करते हैं, और यदि क्रोम आपको लॉक आइकन नहीं देता है, तो फ़ायरफ़ॉक्स कर सकता है। इस प्रकार, फिर से, इस लॉक आइकन का क्या अर्थ है, इसकी कोई स्पष्ट परिभाषा नहीं है।
आइए देखें कि इस योजना को लागू करते समय क्या समस्याएं आ सकती हैं। नियमित HTTP में, हम DNS पर भरोसा करने के लिए उपयोग किए जाते हैं, जो हमें सर्वर पर सही आईपी पता देना चाहिए। DNS HTTPS URL-? DNS DNS?
: , , , IP-.
: , , , amazon.com.
: , - amazon.com, IP-.
: , , – - DNS . , DNS , . , DNS , IP-, . , - DNS- IP-? ?
: , HTTPS?
: , , .
: , HTTP URL.
: , HTTPS, .
: .
: , . . , CA, , , , - , .
, - https , - , , , , , , .
HTTPS , - . , . , , , . -. « , ». , , , - , . , - .
, , , . , amazon.com
www.amazon.com , , , .
-, , , . , : „ , , , , ». , - , . .
, DNS, , , .
, , DNS, . , DNS-, SSL / TLS HTTPS, DNS . , DNS . DoS , , .
, — , ? , , ? , ?
: , - , . , .
: , , , , , , : « »! , , - , , , , . , .
: , .
: , . . , , , , , cookies, , URL-, , origin. , - amazon.com , , , , amazon.com. , amazon.com, , , , , , JavaScript .
, , -. , . - amazon.com «» . , amazon.com, , , , . . , , .
52:10
MIT « ». 14: «SSL HTTPS», 3.
हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें,
एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 30% छूट जो हमने आपके लिए ईजाद की है: VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps से पूरा सच $ 20 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।
VPS (KVM) E5-2650 v4 (6 करोड़) 10GB DDR4 240GB SSD 1Gbps दिसंबर तक मुफ्त में जब छह महीने की अवधि के लिए भुगतान करते हैं, तो आप
यहां ऑर्डर कर सकते
हैं ।
डेल R730xd 2 बार सस्ता? केवल हमारे पास
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps नीदरलैंड और यूएसए में $ 249 से 100 टीवी है ! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें
। एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?