एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 14: "एसएसएल और एचटीटीपीएस", भाग 3

मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 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

मुझे लगता है कि HTTPS का प्रवर्तन उन उपयोगकर्ताओं के लिए चिंता का विषय है जो प्रमाण पत्र का उपयोग करने का निर्णय लेने में बहुत अधिक विवेक रखते हैं।

एक और समस्या जो व्यवहार में खुद को प्रकट करती है और जो HTTPS के उपयोग को मजबूर करती है वह एक वेब पेज पर असुरक्षित लगाव या मिश्रित सामग्री है। इस समस्या का मुद्दा यह है कि एक सुरक्षित साइट या कोई भी वेबसाइट, इस मामले के लिए, एक वेब पेज में सामग्री के अन्य टुकड़ों को एम्बेड कर सकती है।

इसलिए यदि आपके पास किसी प्रकार की वेबसाइट है, उदाहरण के लिए foo.com/index.html, तो इसे HTTPS प्रोटोकॉल का उपयोग करके परोसा जा सकता है, लेकिन HTML पेज के अंदर आपके पास कई टैग हो सकते हैं जो ब्राउज़र को कहीं जाने के लिए मजबूर करते हैं और इसे हिस्सा बनाते हैं इस पृष्ठ में किसी प्रकार की विदेशी सामग्री है।



इस परिदृश्य का टैग इस तरह दिखता है:

<script scr = «http://jquery.com/…”> 

और jquery.com के स्रोत को इंगित करता है। इस प्रकार, लोकप्रिय जावास्क्रिप्ट लाइब्रेरी आपके ब्राउज़र में कई चीजों के संपर्क की सुविधा प्रदान करती है। लेकिन कई वेब डेवलपर्स बस किसी अन्य साइट के URL से लिंक करते हैं। इससे चीजें आसान हो जाती हैं, लेकिन क्या हो सकता है? मान लीजिए कि आपके पास एक सुरक्षित साइट है और आप बस वहाँ से jQuery डाउनलोड करते हैं।

छात्र: यह नकली jQuery हो सकता है।

प्रोफेसर: हाँ, यह है। वास्तव में गलत काम करने के दो तरीके हैं जिन्हें आप प्राप्त करने की उम्मीद नहीं करते हैं। एक संभावना यह है कि jQuery से ही समझौता किया जा सकता है। आपने जो अनुरोध किया, उसके समान ही आपको कुछ मिला है। अगर jQuery से छेड़छाड़ की जाती है, तो यह बहुत बुरा है। एक और संभावना यह है कि यह अनुरोध बिना किसी एन्क्रिप्शन या प्रमाणीकरण के नेटवर्क पर भेजा जाएगा। इसलिए, यदि विरोधी आपके नेटवर्क कनेक्शन को नियंत्रित करता है, तो वह इस अनुरोध को रोक सकता है और प्रतिक्रिया में आपको एक और जावास्क्रिप्ट कोड भेज सकता है, और अब यह जावास्क्रिप्ट कोड आपके पृष्ठ के हिस्से के रूप में काम करेगा। और जब से वह इस HTTPS डोमेन foo.com में काम करता है, उसके पास आपके सुरक्षित कुकीज़ foo.com और इस पृष्ठ पर किसी भी अन्य चीज की पहुंच होती है। यह एक बहुत बुरी चीज की तरह लगता है, इसलिए सावधान रहें। और वेब डेवलपर को भी इस तरह की गलती न करने के लिए सावधान रहना होगा।

इस प्रकार, समाधानों में से एक सुरक्षित पृष्ठ में एम्बेडेड सभी सामग्री की सुरक्षा सुनिश्चित करना है। कई वेब डेवलपर्स को फॉलो करने के लिए यह एक अच्छी गाइडलाइन है। तो शायद आपको jquery.com के बजाय इस लाइन में jquery.com का उपयोग करना चाहिए। या यदि URL मूल नीति का समर्थन करते हैं, तो इसका मतलब है कि आप HTTPS का हिस्सा छोड़ सकते हैं और केवल यह कह सकते हैं कि इस स्क्रिप्ट का मूल //jquery.com/ है, जो कि scr = "//jquery.com / ..." है



और इसका मतलब है कि यह टैग आपको jquery.com पर भेज देगा यदि यह HTTPS पेज पर है, और jquery.com पर अगर यह HTTPS पर नहीं है, लेकिन एक नियमित HTTP URL पर है। इस तरह की समस्या से बचने का यह एक तरीका है।

हालांकि, लोग लगातार हर चीज को बेहतर बनाने की कोशिश कर रहे हैं, इसलिए इस समस्या को हल करने के लिए वैकल्पिक तरीकों में से एक हैश या कुछ और जैसे सूचक को यहीं टैग में शामिल करना है:

 <script scr = «http://jquery.com/…”> 

क्योंकि यदि आप जानते हैं कि आप किस प्रकार की सामग्री डाउनलोड करना चाहते हैं, तो आपको HTTPS प्रोटोकॉल का उपयोग करके इसे पूरी तरह से डाउनलोड करने की आवश्यकता नहीं है। वास्तव में, आप परवाह नहीं करते हैं कि कौन आपको यह सामग्री प्रदान करता है जब तक कि यह एक विशिष्ट हैश से मेल खाता है।

इस प्रकार, एक नया विनिर्देश है जो आपको इस तरह के टैग के लिए हैश को कॉन्फ़िगर करने की अनुमति देता है। इसलिए HTTPS URL के साथ jquery.com से लिंक करने के बजाय, आप बस यह कह सकते हैं कि स्क्रिप्ट का स्रोत jquery.com या यहां तक ​​कि HTTP भी है, लेकिन स्क्रिप्ट के अंत में आप किसी प्रकार की टैग विशेषता जोड़ते हैं, उदाहरण के लिए हैश आपके लिए समान है सर्वर से प्राप्त करने की उम्मीद है।



छात्र: इस विनिर्देश का नाम क्या है?

प्रोफेसर: इसका एक जटिल नाम है, यह नोट्स में व्याख्यान नोट्स के लिए है, "सबस्रोइट अखंडता", सबस्रोसिटी अखंडता जैसे कुछ। इसे धीरे-धीरे लागू किया जा रहा है, लेकिन मुझे उम्मीद है कि निकट भविष्य में इसे विभिन्न ब्राउज़रों में लागू किया जाएगा। यह नेटवर्क स्तर पर डेटा एन्क्रिप्शन पर भरोसा किए बिना सामग्री को प्रमाणित करने के एक अन्य तरीके के समान है।

इस प्रकार, हमारे पास यह बहुत ही सामान्य योजना है जो एक विशिष्ट सर्वर से कनेक्शन को प्रमाणित करने के लिए एसएसएल और टीएलएस का उपयोग करता है। यह आपके नेटवर्क कनेक्शन की सुरक्षा का एक वैकल्पिक तरीका है। यदि आप अखंडता की परवाह करते हैं, तो आपको एक सुरक्षित, एन्क्रिप्टेड नेटवर्क चैनल की आवश्यकता नहीं हो सकती है। आपको केवल यह निर्दिष्ट करने की आवश्यकता है कि आप आखिर में क्या प्राप्त करना चाहते हैं।

छात्र: क्या यह SRC कोड क्लाइंट से नहीं आ रहा है?

प्रोफेसर: वह क्लाइंट की तरफ काम करता है, लेकिन क्लाइंट को कुछ सर्वर से यह कोड प्राप्त होता है।

छात्र: क्या कोई भी केवल एक पृष्ठ में अपना जावास्क्रिप्ट कोड दर्ज नहीं कर सकता है?

प्रोफेसर: मुझे लगता है कि यह कर सकता है। इसलिए, हैश का अर्थ पृष्ठ की सामग्री को उन घुसपैठियों से बचाना है जो विभिन्न जावास्क्रिप्ट कोड दर्ज करने का प्रयास कर रहे हैं। JQuery के लिए, यह बहुत महत्वपूर्ण है क्योंकि jQuery अच्छी तरह से जाना जाता है, क्योंकि आप jQuery स्रोत कोड को छिपाने की कोशिश नहीं कर रहे हैं। इसलिए, आप यह सुनिश्चित करना चाहते हैं कि कोई नेटवर्क हमलावर आपके कनेक्शन को बाधित न कर सके और jQuery का एक दुर्भावनापूर्ण संस्करण सम्मिलित कर सके, जिससे कुकीज़ का रिसाव हो सके। यह सच है कि कोई भी अपने लिए इन चीजों के हैश का पता लगा सकता है। इस प्रकार, यह गोपनीयता नहीं बल्कि अखंडता की समस्याओं का समाधान है।

मुझे लगता है कि डेवलपर्स को इस पर नज़र रखना चाहिए जब वे पृष्ठ लिखते हैं या HTTPS URL में अपने HTML पृष्ठों की सामग्री शामिल करते हैं। हमारे पास एक और चिंता कुकीज़ के साथ है। यह वह जगह है जहां सुरक्षा झंडे के साथ कुकीज़ और मूल उत्पत्ति वाले कुकीज़ के बीच अंतर होता है। केवल एक चीज जो डेवलपर यहां खराब कर सकती है, वह यह है कि पहली बार में कुकीज़ पर झंडा लगाना भूल जाएं, ऐसा होता है। शायद वह केवल उन उपयोगकर्ताओं के बारे में सोचता है जो केवल HTTPS URL पर जाएंगे, और झंडे को अनावश्यक रूप से सेट करने पर विचार करेंगे। क्या यह एक समस्या है? यदि आपके उपयोगकर्ता बहुत सावधान हैं और हमेशा HTTPS URL पर जाते हैं, तो कोई समस्या नहीं है। क्या आपको लगता है कि इस मामले में आपके कुकीज़ पर सुरक्षा ध्वज छोड़ने का कोई मतलब है?

छात्र: क्या यह संभावना है कि एक हमलावर आपके URL से जुड़ सकेगा और आपको दुर्भावनापूर्ण साइट पर रीडायरेक्ट कर सकेगा?

प्रोफेसर: हाँ। भले ही उपयोगकर्ता स्पष्ट रूप से सादे पाठ के रूप में किसी URL पर न जाए, फिर भी हमलावर उसे असुरक्षित साइट का लिंक दे सकता है या उसे HTTPS के अलावा किसी URL के साथ एक छवि डाउनलोड करने के लिए कह सकता है। और फिर असुरक्षित कुकीज़ नेटवर्क अनुरोध के साथ भेजे जाएंगे। तो यह एक समस्या है, और आपको वास्तव में एक ध्वज की आवश्यकता है, भले ही आपके उपयोगकर्ता और आपके अनुप्रयोग बहुत सावधान रहें।

छात्र: मेरा मानना ​​है कि सुरक्षित HTTP URL हैं।
प्रोफेसर: हाँ, यह सच है। मान लीजिए मेरे पास एक वेबसाइट है जो पोर्ट 80 पर भी नहीं सुन रही है और पोर्ट 80 के माध्यम से मुझे कनेक्ट करने का कोई तरीका नहीं है, इसलिए यदि मैं असुरक्षित कुकीज़ का उपयोग करता हूं तो समस्या क्यों हो सकती है?

छात्र: क्योंकि ब्राउज़र आपके कुकीज़ को दूसरे डोमेन पर भेजने में सक्षम नहीं होगा।

प्रोफेसर: यह सही है, ब्राउज़र कुकीज़ को दूसरे डोमेन पर नहीं भेजेगा, लेकिन अभी भी एक खतरा है कि कोई हमलावर अपना URL डाउनलोड कर सकता है। तो, मान लीजिए कि amazon.com केवल SSL का उपयोग करता है, यह पोर्ट 80 पर भी नहीं सुनता है। परिणामस्वरूप, वे कुकीज़ पर अपना सुरक्षित ध्वज सेट नहीं करते हैं। तो कैसे एक हैकर उनके कुकीज़ चोरी कर सकता है अगर अमेज़ॅन पोर्ट 80 पर भी नहीं सुनता है?

छात्र: क्या ब्राउज़र अब भी सोच सकता है कि यह एक HTTP कनेक्शन है?

प्रोफेसर: ठीक है, यदि आप 443 पोर्ट से कनेक्ट करते हैं और एसएसएल या टीएलएस का उपयोग करते हैं, तो कनेक्शन हमेशा एन्क्रिप्ट किया जाएगा, इसलिए यह कोई समस्या नहीं है।

छात्र: एक हमलावर कनेक्शन को रोक सकता है।

प्रोफेसर: हाँ, एक हमलावर आपके पैकेट को बाधित कर सकता है जो अमेज़ॅन को पोर्ट 80 के माध्यम से कनेक्ट करने की कोशिश कर रहे हैं, और यह दिखावा करते हैं कि आप सफलतापूर्वक साइट से जुड़े हैं। इसलिए यदि किसी हमलावर का आपके नेटवर्क पर नियंत्रण है, तो वह अमेज़ॅन को निर्देशित किए गए आपके पैकेट को अपनी मशीन के 80 पोर्ट में रीडायरेक्ट कर सकता है, और ग्राहक अंतर नहीं देख पाएगा। ऐसा लगेगा जैसे कि अमेज़ॅन पोर्ट 80 पर सुन रहा था, लेकिन वास्तव में आपके कुकीज़ इस हैकर के वेब सर्वर पर भेजे जाएंगे।

छात्र: क्योंकि ग्राहक अज्ञात है।

प्रोफेसर: यह सही है, क्योंकि HTTP में आपके द्वारा होस्ट किए गए होस्ट की प्रामाणिकता को सत्यापित करने का कोई तरीका नहीं है। ठीक ऐसा ही हो रहा है। HTTP में प्रमाणीकरण नहीं है। इसलिए, यदि आप मानते हैं कि एक नेटवर्क विरोधी है, तो आपको सबसे पहले अपने कुकीज़ को HTTP के माध्यम से भेजने से रोकना होगा, क्योंकि आपको पता नहीं है कि यह HTTP कनेक्शन किसके पास जाएगा।

छात्र: इसके लिए आपको नेटवर्क को नियंत्रित करने की आवश्यकता है।

प्रोफेसर: हां, बिल्कुल। यदि आपका अपने नेटवर्क पर पूर्ण नियंत्रण है, तो आप जानते हैं कि विरोधी आपके पैकेट को बाधित नहीं कर पाएंगे। हालांकि, यहां तक ​​कि नेटवर्क पर पूर्ण नियंत्रण के साथ, आपको परेशानी हो सकती है, टीसीपी पर व्याख्यान के लिए सामग्री को देखें, विभिन्न प्रकार के नेटवर्क हमलों पर विचार किया गया था।

श्रोता: लेकिन क्या इस मामले में पुनर्निर्देशित हमले को रोकना संभव नहीं है?

प्रोफेसर: हैकर के ग्राहक के http अनुरोध को amazon.com पर इंटरसेप्ट करने की संभावना है, और इस अनुरोध में आपके सभी कुकीज़ amazon.com या किसी अन्य डोमेन के लिए कुकीज़ शामिल होंगी, जिसके लिए आप अनुरोध भेजते हैं। इसलिए, यदि आप इन कुकीज़ को सुरक्षित नहीं रखते हैं, तो उन्हें एन्क्रिप्टेड और अनएन्क्रिप्टेड कनेक्शन दोनों पर भेजा जा सकता है।

छात्र: यह अनुरोध कैसे शुरू किया गया है?

प्रोफेसर: शायद आप उपयोगकर्ता को newyorktimes.com पर जा सकते हैं, जहाँ आपने amazon.com से एक छवि अपलोड करने वाले विज्ञापन के लिए भुगतान किया था। और ऐसा कुछ भी नहीं है जो उपयोगकर्ता को पूछने से बचाएगा: "कृपया इस URL से छवि डाउनलोड करें।" लेकिन जब ब्राउज़र साइट से कनेक्ट करने का प्रयास करता है, तो यह कनेक्शन सफल होने पर कुकीज़ भेज देगा।

हर जगह एक HTTPS एक्सटेंशन होता है, जो Force HTTPS या मजबूर HTTPS के समान है, और जो इस तरह की त्रुटि को रोकने का प्रयास करता है। जब आप मजबूर HTTPS मोड में एक साइट का चयन करते हैं, तो ब्राउज़र मुख्य रूप से इस होस्ट के लिए किसी भी HTTP कनेक्शन को रोक देगा।



इस प्रकार, आपके कुकीज़ को सुरक्षित रूप से चिह्नित नहीं करने या इसी तरह की गलती करने का कोई तरीका नहीं है। यदि डेवलपर कुकीज़ पर सुरक्षा ध्वज लगाना भूल गया है, तो इस मामले में समाधान स्पष्ट है - उसे अपनी गलती को ठीक करना होगा। लेकिन एक और अधिक नाजुक समस्या है: जब एक सुरक्षित वेब सर्वर क्लाइंट की कुकी वापस प्राप्त करता है, तो यह पता नहीं चलता है कि यह कुकी एन्क्रिप्टेड या सादे पाठ कनेक्शन के माध्यम से भेजा गया था या नहीं। क्योंकि वास्तव में, सर्वर को कुकी के लिए केवल कुछ महत्वपूर्ण मान प्राप्त होते हैं।

ऊपर चर्चा की गई कार्ययोजना से, यह इस प्रकार है कि सुरक्षित सर्वर के लिए अनुरोध भेजते समय, ब्राउज़र में सुरक्षित और असुरक्षित कुकीज़ दोनों शामिल होंगे, क्योंकि इसके भाग के लिए, यह उनकी गोपनीयता के बारे में चिंतित है। लेकिन सर्वर की तरफ गोपनीयता की कोई गारंटी नहीं है, और जब सर्वर को उपयोगकर्ता कुकीज़ प्राप्त होती हैं, तो उन्हें एन्क्रिप्टेड और टेक्स्ट कनेक्शन दोनों पर भेजा जा सकता है। इससे सत्र निर्धारण जैसे हमलों की संभावना बढ़ जाती है।

इसका मतलब है कि एक हमलावर, उदाहरण के लिए, यह देखना चाहता है कि आप कौन से ईमेल भेजते हैं। ऐसा करने के लिए, वह आपको अपनी खुद की कुकीज़ सेट करेगा, जो उसके जीमेल खाते की कुकीज़ की एक प्रति है। और जब आप अपना पत्र भेजते हैं, तो यह उसके भेजे गए आइटम फ़ोल्डर में दिखाई देगा, और आपके फ़ोल्डर में नहीं। यह ऐसा होगा जैसे आप एक हमलावर खाते का उपयोग कर रहे थे, इसलिए वह आपके मेलबॉक्‍स से आपके पत्राचार को निकाल सकता है। इसलिए यदि कोई हैकर जबरन आपके ब्राउज़र में सत्र कुकीज़ डालता है, तो वह आपको अपने खाते का उपयोग करने के लिए मजबूर करेगा। तो यह एक और समस्या है जो HTTP और HTTPS कुकीज़ के अधूरे अलगाव के साथ गलतफहमी के कारण उत्पन्न होती है।

छात्र: लेकिन किसी और के ब्राउज़र में अपनी कुकी डालने के लिए, आपको वहां एक भेद्यता होनी चाहिए।

प्रोफेसर: नहीं, अपने कुकी को सेट करने के लिए, भेद्यता की आवश्यकता नहीं है। आप बस ब्राउज़र को सामान्य HTTP होस्ट URL से कनेक्ट करने में ट्रिक कर रहे हैं। और यदि ब्राउज़र में कोई एक्सटेंशन नहीं है, जैसे कि फोर्स HTTPS या HTTPS एवरीवेयर, तो आप एक हमलावर के रूप में, उपयोगकर्ता के ब्राउज़र में कुंजी सेट कर सकते हैं। यह एक असुरक्षित कुकी है, लेकिन इसे सुरक्षित अनुरोधों के लिए भी वापस भेजा जाएगा।

छात्र: आप ब्राउज़र को कैसे लगा सकते हैं कि यह डोमेन एक ही डोमेन है?
प्रोफेसर: इसके लिए आपको नेटवर्क कनेक्शन को इंटरसेप्ट करना चाहिए और कुछ प्रकार के हमलों को करना चाहिए, जिनके बारे में हमने कुछ मिनट पहले बात की थी।

तो क्या HTTPS वास्तव में मजबूर करता है? वह कई समस्याओं में से कुछ को रोकने की कोशिश कर रहा है। बल HTTPS प्रोटोकॉल पर अध्ययन 5 या 6 साल पहले प्रकाशित किए गए थे। तब से, इसे मानकीकृत किया गया है और वास्तव में अपनाया गया है। यह एक स्केची प्लगइन की तरह दिखता है जो कुछ चीजों और कुछ कुकीज़ को संग्रहीत करता है। आज, अधिकांश ब्राउज़र डेवलपर्स का मानना ​​है कि इसे बनाना एक अच्छा विचार था। इसे सीधे ब्राउज़र में एकीकृत करना सबसे अच्छा है। एचटीटीपीएस प्रोटोकॉल पर एक सुरक्षित कनेक्शन को बाध्य करने के लिए HTTP स्ट्रक्ट ट्रांसपोर्ट सिक्योरिटी या HSTS नामक एक प्रणाली है। यह एक अच्छा उदाहरण है कि वैज्ञानिक अनुसंधान वेब अनुप्रयोगों और ब्राउज़रों की सुरक्षा को कैसे प्रभावित करते हैं।

आइए देखें कि एक वेबसाइट के लिए फोर्स HTTPS क्या करता है। मजबूर HTTPS एक वेबसाइट को एक विशिष्ट होस्ट नाम के लिए इस बिट को सेट करने की अनुमति देता है, और तीन चीजें हैं जो HTTPS को ब्राउज़र व्यवहार को प्रभावित करने के लिए मजबूर करती हैं।

पहला यह है कि कोई भी प्रमाणपत्र त्रुटियां हमेशा घातक होती हैं। इस प्रकार, उपयोगकर्ता के पास गलत होस्ट नाम या समय सीमा समाप्त होने के साथ गलत प्रमाण पत्र स्वीकार करने का कोई मौका नहीं है, और इसी तरह। यह एक ऐसी चीज है जो ब्राउज़र को बदल देती है।

दूसरी बात यह है कि फोर्स HTTPS HTTPS के सभी HTTP रिक्वेस्ट को रीडायरेक्ट करता है। यह एक बहुत अच्छा विचार है। यदि आप जानते हैं कि साइट हमेशा वैध रूप से HTTPS का उपयोग करती है, तो आपको संभवतः किसी भी नियमित HTTP अनुरोध को प्रतिबंधित करना चाहिए, क्योंकि यह किसी प्रकार की त्रुटि या सबूत का संकेत हो सकता है जो एक हमलावर आपको एन्क्रिप्शन के बिना साइट से कनेक्ट करने की पेशकश करने में आपको चकमा देने की कोशिश कर रहा है। । आप यह सुनिश्चित करना चाहते हैं कि यह वास्तव में HTTP अनुरोध के निष्पादित होने से पहले होता है, अन्यथा कोई भी HTTP अनुरोध नेटवर्क पर पहले ही चला जाएगा।

और आखिरी चीज फोर्स HTTPS ब्राउज़र को ऐसा करने के लिए मजबूर करती है कि यह असुरक्षित एम्बेडिंग योजना को प्रतिबंधित करता है जिसे हमने पहले देखा था - जब आप HTTPS साइट में एक HTTP URL एम्बेड करते हैं।



तो यह है कि बल HTTPS एक्सटेंशन क्या करता है। आज इस्तेमाल की जाने वाली शब्दावली के आधार पर, HSTS प्रोटोकॉल यही करता है। अब अधिकांश ब्राउज़र डिफ़ॉल्ट रूप से असुरक्षित एम्बेडिंग को प्रतिबंधित करते हैं। यह विवादास्पद था, क्योंकि कई डेवलपर्स को फोर्स HTTPS के कारण समस्या थी, लेकिन मुझे लगता है कि फ़ायरफ़ॉक्स, क्रोम और IE डिफ़ॉल्ट रूप से असुरक्षित घटकों को लोड करने से मना कर देंगे, या यदि आप कम से कम अपने पेज पर जावास्क्रिप्ट और सीएसएस को असुरक्षित करते हैं। तो गलत करो।

छात्र: वे किसी भी कार्रवाई के प्रदर्शन के बारे में उपयोगकर्ता से नहीं पूछते हैं?

प्रोफेसर: वे इस तथ्य के लिए उपयोग किए जाते हैं कि आमतौर पर उपयोगकर्ता सहमत होते हैं। उदाहरण के लिए, IE एक पॉपअप संवाद का उपयोग करता है जो पूछता है कि क्या आप अतिरिक्त सामग्री डाउनलोड करना चाहते हैं, या ऐसा कुछ। मुझे लगता है कि यदि आप कोशिश करते हैं, तो आप इन सभी सुरक्षा उपायों को दरकिनार कर सकते हैं, लेकिन मैं आपको ऐसा करने की सलाह नहीं देता। इस प्रकार, आधुनिक ब्राउज़र बल HTTPS और HSTS का उपयोग करके कुछ समस्याओं को हल करने का प्रयास करते हैं।

छात्र: क्या होता है जब कोई साइट HTTPS का समर्थन नहीं करती है?

प्रोफेसर: क्या मतलब?

छात्र: कि ब्राउज़र HTTPS के माध्यम से साइट से कनेक्ट नहीं होगा।

प्रोफेसर: यदि आपके पास कोई वेबसाइट है जो HTTPS का समर्थन नहीं करती है लेकिन इन कुकीज़ को सेट करती है तो क्या होता है? तथ्य यह है कि यदि आप अपने ब्राउज़र में इस विकल्प का उपयोग करते हैं, तो आप अधिकांश इंटरनेट से बात नहीं कर पाएंगे, क्योंकि वे HTTPS का उपयोग नहीं करते हैं। इसलिए, ब्राउज़र को उन साइटों के साथ HTTPS के माध्यम से संवाद करने में सक्षम होना चाहिए जो वास्तव में ऐसी सुरक्षा चाहते हैं।

स्टूडेंट: अगर मुझे सही से याद है, तो जब तक साइट इजाजत नहीं देती, आप कुकी सेट नहीं कर सकते।

प्रोफेसर: हाँ, यह सच है। ये लोग DoS के हमलों से चिंतित हैं, जिसमें इस प्लगइन का उपयोग अन्य साइटों पर परेशानी पैदा करने के लिए किया जा सकता है। उदाहरण के लिए, यदि आप कुछ बिना सोचे-समझे वेबसाइटों के लिए बल HTTPS बिट सेट करते हैं, तो वे अचानक काम करना बंद कर देंगे, क्योंकि अब हर कोई HTTPS के माध्यम से उन्हें कनेक्ट करने का प्रयास करेगा, जिसका वे समर्थन नहीं करते हैं। तो यह एक उदाहरण है जो उन साइटों के लिए मजबूर HTTPS का उपयोग करके DoS हमले का उपयोग करने की संभावना के बारे में चिंता करता है जो इस पर भरोसा नहीं करते हैं।

एक और बात यह है कि यह प्रोटोकॉल पूरे डोमेन के लिए बल HTTPS के उपयोग का समर्थन नहीं करता है। उदाहरण के लिए, मैं एक उपयोगकर्ता mit.edu हूं जिसने सभी ब्राउज़रों में Force HTTPS कुकीज सेट की हैं, और अब केवल HTTPS कनेक्शन MIT में काम करते हैं। यह थोड़ा विनाशकारी लगता है, इसलिए आप शायद एक समान स्थिति से बचना चाहते हैं।

दूसरी ओर, एचएसटीएस प्रोटोकॉल इस पर वापस आया, यह कहते हुए कि आप पूरे उपडोमेन के लिए फोर्स HTTPS सेट कर सकते हैं, क्योंकि यह अनुरोध के साथ भेजे गए असुरक्षित कुकीज़ के लिए उपयोगी साबित होता है यदि आपको नहीं पता कि वे मूल रूप से कहां से भेजे गए थे। इन चीजों के लिए न्यूनतम स्तर पर सेटिंग्स का एक पूरा समूह है, लेकिन यह अभी भी स्पष्ट नहीं है कि इस मामले में सही विकल्प का क्या मतलब है।

एक दिलचस्प सवाल है जो आप पूछ सकते हैं: क्या ये सुधार मौलिक हैं या क्या वे केवल डेवलपर्स को गलतियों से बचने में मदद करने के लिए हैं? मान लीजिए कि आपके पास एक बहुत ही जिम्मेदार डेवलपर है जो खतरनाक कार्यों को नहीं करता है, समय पर प्रमाण पत्र अपडेट करता है, नए लोगों को खींचता है - क्या उसे फोर्स HTTPS का उपयोग करने की आवश्यकता है?

छात्र: बेशक, क्योंकि कुछ भी नहीं हैकर को रोक देगा जो उपयोगकर्ता को HTTP के माध्यम से कुछ डाउनलोड करने के लिए मजबूर करेगा, और फिर कनेक्शन को रोक देगा।

प्रोफेसर: यह सच है। लेकिन अगर आपको लगता है कि वह बहुत मेहनती है, और उसकी सभी कुकीज़ सुरक्षित हैं, तो अगर कोई आपकी साइट के HTTP संस्करण पर जाता है, तो यह समस्या नहीं होनी चाहिए।



हालाँकि, आपको अभी भी कुकीज़ या इंजेक्शन हमलों को अधिलेखित करने से बचाव करना होगा। यह थकाऊ है, लेकिन आप शायद इसके बारे में कुछ कर सकते हैं।

छात्र: मुझे लगता है कि किसी भी मामले में डेवलपर प्रमाण पत्र की प्रामाणिकता को सत्यापित करने में सक्षम नहीं होगा, है ना?

: , : « ». , , , , , . : «, !», , , - - . , .

: , , HTTP HTTPS, , , .

: , UI, - , . URL-. amazon.com, , , . HTTPS amazon.com, HTTP URL . , URL-, , amazonn.com amazon.com. . , Force HTTPS.



– Force HTTPS ? ?

: , .

: . , , Force HTTPS HTTPS . , . , Force HTTPS, , , HTTP, HTTPS. , HTTPS. , , HTTPS.

: Force HTTPS?

: , , , . , , , , , , , Force HTTPS .

, amazon.com Force HTTPS, , , , amazon.com, .



. DNSSEC. DNSSEC, , , , HTTPS Force HTTPS, DNS-. , DNSSEC, , , .

Google , . , Chrome , Force HTTPS. Chrome, , CRL Force HTTPS, . , , , . , Google, , , .

बेशक, वर्तमान में Google का कहना है कि किसी भी साइट को ब्राउज़र में शामिल किया जा सकता है क्योंकि मौजूदा सूची बहुत छोटी है, लेकिन अगर यह लाखों प्रविष्टियों तक बढ़ती है, तो मुझे यकीन है कि Google ब्राउज़र सूची में सभी साइटों सहित बंद हो जाएगा। लेकिन अब आप वास्तव में क्रोम डेवलपर्स को एक ईमेल भेजकर अपने डोमेन को वहां जोड़ सकते हैं और आपकी साइट फोर्स HTTPS URL में सूचीबद्ध हो जाएगी।


पाठ्यक्रम का पूरा संस्करण यहां उपलब्ध है ।

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें, एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 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 सर्वर का उपयोग कर वर्ग?