अगर मुझे ऐसी साइट दिखाई देती है, जिसमें एक अहस्ताक्षरित या स्व-हस्ताक्षरित एसएसएल प्रमाणपत्र है, तो मेरा ब्राउज़र मुझे चेतावनी देता है। फिर भी एक ही ब्राउज़र को असुरक्षित पन्नों में क्रेडेंशियल्स भेजने की अनुमति देने में कोई समस्या नहीं है।
स्व-हस्ताक्षरित प्रमाणपत्र को बिना प्रमाण पत्र के क्यों बदतर माना जाता है?
जवाबों:
बहुत सारे लोग हैं जो महसूस करते हैं कि यह प्रणाली टूट गई है।
SSL प्रमाणपत्र अमान्य होने पर आपका ब्राउज़र आपको ऐसी खतरनाक चेतावनी क्यों देगा इसके पीछे तर्क है:
एसएसएल बुनियादी ढांचे के मूल डिजाइन उद्देश्यों में से एक वेब सर्वर का प्रमाणीकरण प्रदान करना था। असल में, यदि आप www.bank.com पर जाते हैं, तो एसएसएल वेबसर्वर को यह साबित करने की अनुमति देता है कि यह साबित करता है कि यह वास्तव में आपके बैंक से संबंधित है। यह DNS को हेरफेर करने या दुर्भावनापूर्ण सर्वर प्रतिक्रिया के लिए किसी अन्य विधि का उपयोग करने से एक इम्पोर्टर को रोकता है।
SSL में "ट्रस्ट" एक विश्वसनीय तृतीय पक्ष होने से प्रदान किया जाता है (VeriSign और Thawte Consulting जैसी कंपनियां) प्रमाण पत्र पर हस्ताक्षर करती हैं, यह दर्शाता है कि उन्होंने सत्यापित किया है कि यह किसके स्वामित्व में है, यह कहता है (सिद्धांत में आईटी व्यवस्थापक पर जाकर व्यक्ति या कोई अन्य विधि जो प्रत्यक्ष विश्वास पैदा करती है, हालांकि सबूत दिखाते हैं कि वे वास्तव में इसके बारे में ढीले हैं - यह सब एक हस्ताक्षरित एसएसएल प्रमाणपत्र प्राप्त करने के लिए होता है अक्सर एक 800 नंबर और अभिनय कौशल का एक सा होता है)।
इसलिए, यदि आप एक ऐसे वेब सर्वर से जुड़ते हैं जो एसएसएल प्रमाणपत्र प्रदान करता है, लेकिन यह एक विश्वसनीय तीसरे पक्ष द्वारा हस्ताक्षरित नहीं है, तो सिद्धांत रूप में इसका मतलब यह हो सकता है कि आप एक अभेद्य के साथ संचार कर रहे हैं जो एक अलग संगठन से संबंधित सर्वर होने का नाटक कर रहा है ।
व्यवहार में, आमतौर पर एक स्व-हस्ताक्षरित प्रमाण पत्र का मतलब है कि सर्वर को चलाने वाले संगठन ने हस्ताक्षरित प्रमाण पत्र के लिए भुगतान करने के लिए नहीं चुना है (वे बहुत महंगी हो सकती हैं, जो आप चाहते हैं सुविधाओं के आधार पर), या एक को कॉन्फ़िगर करने के लिए तकनीकी विशेषज्ञता का अभाव है ( कुछ छोटे व्यवसाय समाधान स्वयं-हस्ताक्षरित प्रमाणपत्र के लिए एक-क्लिक तंत्र की पेशकश करते हैं, लेकिन एक विश्वसनीय प्रमाण पत्र प्राप्त करने के लिए अधिक तकनीकी चरणों की आवश्यकता होती है)।
मेरा व्यक्तिगत रूप से मानना है कि यह प्रणाली टूटी हुई है, और यह कि बिना किसी एन्क्रिप्शन की पेशकश करने वाले सर्वर के साथ संचार करना एसएसएल की पेशकश करने वाले सर्वर के साथ स्व-हस्ताक्षरित प्रमाण पत्र के साथ संचार करने से कहीं अधिक खतरनाक है। तीन कारण हैं कि ब्राउज़र ऐसा कार्य नहीं करता है:
पृष्ठ से पृष्ठ पर क्रेडेंशियल भेजना मूल रूप से HTTP POST कर रहा है। क्रेडेंशियल भेजने की तुलना में कुछ खास नहीं है। उदाहरण के लिए POST.I के माध्यम से खोज शब्द भेजने की तुलना में। असुरक्षित पेज पर कोई भी पोस्ट चेतावनी को ट्रिगर करेगा, उपयोगकर्ताओं को बेकार चेतावनी द्वारा बमबारी की जाएगी।
सुरक्षित चैनल का उपयोग स्थानांतरण को सुरक्षित करने के लिए प्रोग्रामर के इरादे को इंगित करता है। इस मामले में, स्व-हस्ताक्षरित प्रमाणपत्र चेतावनी का उपयोग करना बहुत सही बात है।
मैं टिप्पणी नहीं कर सकता, इसलिए मैं इस जानकारी को पोस्ट करूंगा जो user40350 की सही जानकारी के लिए पूरक है।
फिर भी एक ही ब्राउज़र को असुरक्षित पन्नों में क्रेडेंशियल्स भेजने की अनुमति देने में कोई समस्या नहीं है।
यह वास्तव में सच भी नहीं है। जब आप पहली बार प्रयास करते हैं तो अधिकांश ब्राउज़र आपको एक असुरक्षित कनेक्शन पर डेटा सबमिट करने के बारे में एक चेतावनी दिखाएंगे , लेकिन आप इसे बंद कर सकते हैं ताकि यह फिर कभी न दिखे, और मैं शर्त लगाता हूं कि आपने जो किया है ...
मिरो ए ने लिखा:
पृष्ठ से पृष्ठ पर क्रेडेंशियल भेजना मूल रूप से HTTP POST कर रहा है। POST के माध्यम से उदा। खोज शब्द भेजने की तुलना में क्रेडेंशियल्स भेजने के बारे में कुछ खास नहीं है
यह भी गलत है, क्योंकि पासवर्ड फ़ील्ड उदाहरण के लिए विशेष HTML टैग हैं। उसके ऊपर "उपयोगकर्ता नाम" और "पासवर्ड" जैसे लेबल भी उनके सेंसिटिव का बहुत बड़ा धोखा देते हैं। ब्राउज़र के लिए इस तरह की जानकारी को ध्यान में रखना पूरी तरह से संभव होगा।
Https: // प्रोटोकॉल द्वारा सुरक्षित किए गए कनेक्शन ब्राउज़र द्वारा "सुरक्षित" होने के संकेत दिए गए हैं। उदाहरण के लिए, थोड़ा पैडलॉक दिखाया गया है या URL के कुछ हिस्सों को हरे रंग में चिह्नित किया गया है।
इसलिए उपयोगकर्ता को यह विश्वास करना चाहिए कि वह जिन पृष्ठों पर जा रहा है वे वास्तव में उस URL से हैं जो उसने दर्ज किया था और किसी और से नहीं।
यदि वह बिना किसी https: // का उपयोग कर रहा है, तो उपयोगकर्ता को यह पता होना चाहिए कि दर्ज किया गया डेटा संरक्षित नहीं है और वह जिस साइट पर सर्फ कर रहा है, वह अधिरोपित हो सकती है।
एक स्व-हस्ताक्षरित प्रमाणपत्र यह सुनिश्चित नहीं करता है - उम्मीद को फिर से, कि पृष्ठ सर्फ किया गया है, इसलिए इसे लगाया नहीं गया है, इसलिए यह कोई अतिरिक्त सुरक्षा नहीं देता है।
एक विश्वसनीय (एक प्राधिकारी जिसे आप पर भरोसा है) द्वारा हस्ताक्षरित और अविश्वसनीय प्रमाण पत्र के बीच अंतर किया जाना चाहिए। अन्यथा कोई व्यक्ति आपके बैंक (उदाहरण के लिए) के साथ स्वयं-हस्ताक्षरित प्रमाण पत्र का उपयोग करके अपने रिश्तेदार को थोप सकता है।
इस मामले में सूक्ष्म रूप से आपके चेहरे की चेतावनी बेहतर है क्योंकि संभावित जोखिम अपेक्षाकृत अधिक है। लोग एक https लिंक पर क्लिक कर सकते हैं और यह भी नहीं सोचते कि कोई व्यक्ति कनेक्शन की निगरानी के बीच में बैठा हो सकता है। यदि यह संकेत मिलता है कि प्रमाणपत्र अविश्वसनीय है, तो सूक्ष्म है (हरे रंग की आइकन, आदि के बजाय एक लाल कहें), तो एसएसएल के लाभों को हटाकर लोगों को आसानी से बेवकूफ बनाया जा सकता है।
कई अच्छे कारणों को सूचीबद्ध किया गया है। यहाँ एक और है:
उन मामलों के बारे में सोचें जहां एक सुरक्षित वेब पेज दूसरे से तत्वों को एम्बेड करता है। एक हमलावर यह पता लगा सकता है कि कौन से अनुरोध बाहरी वेब पेज के लिए हैं (समय को देखते हुए, इसे पहले आना होगा) और जो आंतरिक तत्वों के लिए हैं। वह स्वयं को केवल आंतरिक तत्वों में MITM के रूप में इंजेक्ट कर सकता है, स्व-हस्ताक्षरित प्रमाण पत्र का उपयोग कर सकता है, और पृष्ठ के कुछ हिस्सों को नियंत्रित कर सकता है। जब तक एसएसएल का उपयोग करने वाले आंतरिक तत्वों के लिए एक चेतावनी प्रस्तुत की गई थी, लेकिन एक विश्वसनीय प्रमाण पत्र का उपयोग नहीं किया गया था, बाहरी पृष्ठ की सुरक्षा से समझौता किया जाएगा।
यहाँ एक यथार्थवादी उदाहरण है। कहो मैं एक विक्रेता हूं, और मेरे पास 'पेपल के साथ भुगतान' लिंक है। आप उस पर क्लिक करें, और मुझे पता है। मैं आपको PayPal पर पुनर्निर्देशित करता हूं, और आपको वैध, सुरक्षित PayPal पेज मिलता है। यदि मैं आपका नेटवर्क देख रहा हूं, तो मुझे पता है कि पेपाल से आपका पहला अनुरोध होगा, और इसके तुरंत बाद आप अपना पासवर्ड जमा करेंगे। इसलिए मैं submitआपके ईमेल पते और पासवर्ड वाले MITM को पेपल के लिए मेरे स्व-हस्ताक्षरित प्रमाणपत्र को प्रतिस्थापित करता हूं।
आप देखें कि बाहरी पृष्ठ की सुरक्षा से कैसे छेड़छाड़ की जाती है, यदि आंतरिक पृष्ठ का प्रमाण पत्र स्व-हस्ताक्षरित नहीं है? इसलिए इसे स्वयं-हस्ताक्षरित प्रमाणपत्रों पर चेतावनी देनी चाहिए जो लिंक से आते हैं।
और, ज़ाहिर है, यदि आप httpsमैन्युअल रूप से दर्ज करते हैं, तो यह आपको चेतावनी देना चाहिए। क्योंकि आप इसे सुरक्षित होने की उम्मीद करते हैं।