सब कुछ के लिए HTTPS का उपयोग क्यों नहीं करते?

126

यदि मैं एक सर्वर स्थापित कर रहा था, और एसएसएल प्रमाण पत्र था, तो मैं केवल खरीद / लॉगिन के लिए पूरी साइट के लिए HTTPS का उपयोग क्यों नहीं करूंगा? मुझे लगता है कि यह पूरी साइट को एन्क्रिप्ट करने, और पूरी तरह से उपयोगकर्ता की रक्षा करने के लिए और अधिक समझ में आएगा। यह इस तरह की समस्याओं को रोक सकता है जैसे कि यह तय करना होगा कि सबकुछ सुरक्षित है क्योंकि सब कुछ होगा, और यह वास्तव में उपयोगकर्ता के लिए असुविधा नहीं है।

अगर मैं पहले से ही साइट के हिस्से के लिए एक HTTPS का उपयोग कर रहा हूं, तो मैं इसे पूरी साइट के लिए उपयोग क्यों नहीं करना चाहूंगा?

यह एक संबंधित प्रश्न है: https का उपयोग केवल लॉगिन के लिए क्यों किया जाता है? , लेकिन जवाब संतोषजनक नहीं हैं। उत्तर मान लेते हैं कि आप पूरी साइट पर https लागू नहीं कर पाए हैं।

security https

— Malfist
स्रोत

2

यह मुझे आश्चर्यचकित करता है कि वित्तीय सेवा कंपनियां अभी भी http का उपयोग करती हैं।

— टॉम हॉल्टिन

15

@ क्या मैं कुछ ऐसी साइटें चाहता हूँ जो मुझे फ़िशिंग संदेश भेजें उनके जाली साइटों के लिए https का उपयोग करें, इसलिए मुझे पता है कि मैं अपना डेटा सही फ़िशर को दे रहा हूँ।

— व्हर्लविंड

यह सवाल पूछने के लिए धन्यवाद। मैं यह सोचते गया था प्रदर्शन था कारण है और यह http से भी बदतर हो जाएगा। जवाब देखकर, ऐसा लगता है कि प्रदर्शन बहुत बुरा नहीं है, जो मुझे बहुत आश्चर्यचकित करता है।

— सूंदर - मोनिका को बहाल करना

4

मुझे लगता है कि आपने पृष्ठ पर सबसे खराब उत्तर दिया, जिसमें 11 डाउन वोट थे। आपके द्वारा चुना गया उत्तर सुरक्षा और सर्वोत्तम प्रथाओं के लिए कुल उपेक्षा है।

— बदमाश

5

यह प्रश्न वास्तव में एक शिक्षित आधुनिक उत्तर का हकदार है।

— पुराना बैडमैन ग्रे

17

मैं एक दो कारणों के बारे में सोच सकता हूं।

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

— बवंडर
स्रोत

137

कौन से ब्राउज़र SSL का समर्थन नहीं करते हैं?

— मलफिस्ट

6

लिनेक्स के कुछ संकलन इसका समर्थन नहीं करेंगे। यदि आप केवल नए ब्राउज़र का समर्थन कर रहे हैं, तो आपको ठीक होना चाहिए।

— व्हर्लविंड

5

मैं इसके माध्यम से देख रहा था: iweb.tntech.edu/hexb/publications/https-STAR-03122003.pdf "सर्वर के संतृप्त हो जाने के बाद, HTTPS का सिस्टम प्रदर्शन थ्रूपुट के संदर्भ में HTTP का लगभग 67% प्राप्त करता है।"

— व्हर्लविंड

16

मैं t buy this explanation. 1) Don2013 में SSL का समर्थन करने वाले ब्राउज़र का उपयोग नहीं करता हूं । 2) यहां तक कि Google SSL का उपयोग करता है अभी 3) ठीक से सेटअप, आप http ट्रैफ़िक को सही https लिंक पर पुनर्निर्देशित कर सकते हैं।

— jfyelle

4

बुरा जवाब, ऐसा मनु ने क्यों किया? पृथ्वी पर कौन सा ब्राउजर ssl को सपोर्ट नहीं करता है और यूजर्स को https टाइप करना याद नहीं है, इसे रीडायरेक्ट के साथ हैंडल किया जा सकता है

— Sanne

25

अन्य कारणों (विशेष रूप से प्रदर्शन से संबंधित) के अलावा, आप HTTPS का उपयोग करते समय केवल एक डोमेन प्रति IP पता * होस्ट कर सकते हैं।

एक एकल सर्वर HTTP में कई डोमेन का समर्थन कर सकता है क्योंकि सर्वर HTTP हेडर सर्वर को यह जानने देता है कि किस डोमेन से प्रतिक्रिया करनी है।

HTTPS के साथ, सर्वर को प्रारंभिक TLS हैंडशेक (जो HTTP शुरू होने से पहले है) के दौरान क्लाइंट को अपना प्रमाणपत्र देना होगा। इसका मतलब यह है कि सर्वर हैडर को अभी तक नहीं भेजा गया है, इसलिए सर्वर के पास यह जानने का कोई तरीका नहीं है कि किस डोमेन से अनुरोध किया जा रहा है और किस प्रमाणपत्र (www.foo.com, या www.bar.com) के साथ जवाब देना है।

* फुटनोट: तकनीकी रूप से, यदि आप उन्हें विभिन्न बंदरगाहों पर होस्ट करते हैं, तो आप कई डोमेन होस्ट कर सकते हैं, लेकिन यह आमतौर पर एक विकल्प नहीं है। यदि आपके SSL प्रमाणपत्र में वाइल्ड-कार्ड है, तो आप कई डोमेन होस्ट कर सकते हैं। उदाहरण के लिए, आप foo.example.com और bar.example.com दोनों को प्रमाणपत्र * .example.com के साथ होस्ट कर सकते हैं

— Eadwacer
स्रोत

5

वाइल्डकार्ड SSL प्रमाणपत्र नहीं होने से यह समस्या हल हो जाएगी?

— रोब

फुटनोट उत्तर का खंडन करता है: / आप वाइल्डकार्ड सेरट का उपयोग कर सकते हैं और किसी भी डोमेन की मेजबानी कर सकते हैं। en.wikipedia.org/wiki/Wildcard_certificate

— lucascaro

23

यह मुद्दा लंबे समय से सर्वर नाम संकेत द्वारा हल किया गया है, जो आजकल सभी प्रमुख ब्राउज़रों द्वारा समर्थित है। en.wikipedia.org/wiki/Server_Name_Indication

— tia

नहीं सिवाय @tia सभी वेब सर्वर इसे समर्थन

— meffect

2

@meffect ... लेकिन Apache2, nginx, lighttpd और नोडज सहित बहुत कुछ करते हैं। जिसके अलावा, डेवलपर को यह चुनने के लिए मिलता है कि HTTPS टनलिंग के लिए वे किस रिवर्स प्रॉक्सी का उपयोग करते हैं। यह कहते हुए कि "कोई भी क्लाइंट इसका समर्थन नहीं करता है" एक वैध बिंदु होगा यदि यह सच था क्योंकि यह ऐसा कुछ है जिसे डेवलपर का कोई नियंत्रण नहीं है और इसके लिए खाता होना चाहिए। हालांकि, यह कहते हुए कि "कुछ सर्वर इसका समर्थन नहीं करते हैं" काफी हद तक अप्रासंगिक है, ठीक है क्योंकि इसके लिए जिम्मेदार होने की आवश्यकता नहीं है। खासकर जब सभी मुख्यधारा सर्वर है वास्तव में समर्थन किया है।

— पार्थियन शॉट

13

एसएसएल / टीएलएस का उपयोग अक्सर पर्याप्त रूप से नहीं किया जाता है। HTTPS का उपयोग पूरे सत्र के लिए किया जाना चाहिए , किसी भी बिंदु पर एक सेशन आईडी HTTP पर नहीं भेजी जा सकती। यदि आप केवल लॉग इन करने के लिए https का उपयोग कर रहे हैं, तो आप 2010 "A3: टूटी प्रमाणीकरण और सत्र प्रबंधन" के लिए OWASP शीर्ष 10 के स्पष्ट उल्लंघन में हैं ।

— कौआ
स्रोत

यह एक धारणा के बहुत व्यापक हो सकता है। कोई कारण नहीं है कि सत्र स्थिति को http और https के लिए अलग से एकल https लॉगिन ऑपरेशन के माध्यम से प्रबंधित नहीं किया जा सकता है। इसकी कीमत से अधिक काम होने की संभावना है और सुरक्षा से संबंधित बगों को आमंत्रित करते हैं लेकिन स्वचालित रूप से स्पष्ट उल्लंघन का प्रतीत नहीं होगा।

— आइंस्टीन

@ आइंस्टीन कृपया OWASP A3 को पढ़ें, यह बहुत स्पष्ट रूप से लिखा गया है। ध्यान रखें कि यदि किसी प्रामाणिक सत्र से कुकी है तो हमलावर को उपयोगकर्ता नाम / पासवर्ड की आवश्यकता नहीं है।

— बदमाश

साइट मिश्रित https / http प्रदान करती है। https लॉगिन अलग-अलग निम्न और उच्च सुरक्षा सत्र टोकन प्रदान करता है। केवल http सत्र के लिए असाइन किए गए कम सुरक्षा टोकन उच्च सुरक्षा की आवश्यकता वाले कार्यों के लिए काम नहीं करेंगे। मेरे पढ़ने से OWASP A3 कम सुरक्षा परिवहन के माध्यम से उच्च सुरक्षा पहुंच की संभावना की बुनियादी समस्या को स्पष्ट रूप से प्रकाशित कर रहा है।

— आइंस्टीन

@ आइंस्टीन तो आप सहमत हैं कि वेब ब्राउज़र को प्रमाणित करने के लिए सत्र आईडी का उपयोग किया जाता है? इस हमले के पैटर्न पर ध्यान दें, xss हमलों में आप मूल्य प्राप्त करने की कोशिश कर रहे हैं document.cookieताकि हमलावर इसे प्रमाणित करने के लिए उपयोग कर सके। यह मान ट्रैफ़िक को सूँघकर भी प्राप्त किया जा सकता है, जिसे https रोक देता है। मुझे पूरा यकीन नहीं है कि आपकी बात क्या है।

— बदमाश

आपके परिदृश्य में http के लिए सेशन आईडी https संरक्षित संसाधनों के लिए बेकार होगा यदि कोई सिस्टम एक एकल प्रमाणीकरण कार्रवाई के लिए दो अलग-अलग सत्र बनाने के लिए था, जो दोनों प्रोटोकॉल को बिना https सत्र और संबंधित संसाधनों को http सत्र कुकी द्वारा उजागर किए बिना उपयोग करने की अनुमति देता है। उदाहरण के लिए http सत्र का उपयोग रिपोर्टिंग उद्देश्यों के लिए सार्वजनिक संसाधनों तक पहुंच या सार्वजनिक संदेश बोर्डों तक पहुंच के लिए किया जा सकता है, लेकिन वे सुरक्षित संसाधनों के लिए मान्य नहीं होंगे।

— आइंस्टीन

12

रजिस्टर किए गए मेल द्वारा प्रत्येक घोंघा-मेल पोस्ट को टैम्पर प्रूफ अपारदर्शी लिफाफे में क्यों नहीं भेजा जाता है? पोस्ट ऑफिस के किसी व्यक्ति की हमेशा निजी हिरासत होती है, इसलिए आप यह सुनिश्चित कर सकते हैं कि कोई भी आपके मेल पर स्नूपिंग नहीं कर रहा है। जाहिर है, इसका जवाब यह है कि कुछ मेल खर्च करने लायक हैं, लेकिन अधिकांश मेल नहीं है। मुझे परवाह नहीं है अगर किसी को मेरी "खुशी है कि आप जेल से बाहर आ गए!" पोस्टकार्ड अंकल जो के लिए।

एन्क्रिप्शन मुफ़्त नहीं है, और यह हमेशा मदद नहीं करता है।

यदि कोई सत्र (जैसे खरीदारी, बैंकिंग, इत्यादि) HTTPS का उपयोग करके बंद हो रहा है, तो पूरे सत्र को जल्द से जल्द HTTPS नहीं बनाने का कोई अच्छा कारण नहीं है।

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

— डेविड एम
स्रोत

जबरदस्त हंसी!!! महान! मैं शर्त लगाता हूं कि "ग्लैड

— यू आर

19

यदि पंजीकृत मेल की लागत 300% के बजाय 1% अधिक है, तो मैं इसे हर चीज के लिए उपयोग करूंगा ।

— घुलनशील मछली का बच्चा

3

You authenticate over HTTPS and get cookies that prove your identity, so you don't need HTTPS to read news stories.सत्र के सत्र को संभालने का यह उचित तरीका नहीं है। कुकीज़ को SECURE ध्वज के साथ सेट किया जाना चाहिए। लेकिन एक दूसरे के लिए उस भयानक सुरक्षा सलाह की अवहेलना ... आपका मेल सादृश्य वास्तव में कुछ कारणों से सटीक नहीं है। एक होने के नाते कि आप आमतौर पर रिटर्न मेल में होने वाले कारनामों को इंजेक्ट नहीं कर सकते हैं, या किसी और को किसी और के साथ किसी को लगाने के लिए नहीं भेज सकते हैं, या रिटर्न में एक "योर सेशन एक्सपायर्ड" संदेश को पॉप कर सकते हैं ताकि वे उन साख को फिर से दर्ज करें जो वे दोनों याहू के लिए उपयोग करते हैं! और उनका बैंक

— पार्थियन शॉट

पासवर्ड पुन: उपयोग और सत्र निर्धारण, अन्य बातों के अलावा, घोंघा मेल में समस्याएं नहीं हैं।

— पार्थियन शॉट

वे अच्छे अंक हैं, लेकिन आप 2016 के विश्लेषण को 2010 में चर्चा के लिए आवेदन कर रहे हैं।

— डेविड एम

12

सिस्टम लोड से परे सबसे बड़ा कारण यह है कि यह नाम-आधारित वर्चुअल होस्टिंग को तोड़ता है। SSL के साथ, यह एक साइट है - एक आईपी एड्रेस। यह बहुत महंगा है, साथ ही साथ प्रशासन के लिए कठिन है।

— एडम राइट
स्रोत

+1 इसका कारण है कि गूगल एप इंजन कस्टम डोमेन पर https का समर्थन नहीं करता। टीएलएस-एसएनआई के लिए और अधिक व्यापक रूप से समर्थन की प्रतीक्षा की जा रही है।

— श्रीपति कृष्णन

1

आप इसे SSL समाप्ति हार्डवेयर के साथ वापस पा सकते हैं। और अगर सिस्टम लोड एक समस्या है (यह बहुत से लोगों के लिए है!) तो हार्डवेयर एसएसएल वैसे भी जाने का रास्ता हो सकता है।

— जेसन

सिवाय आपके एक ही प्रमाणपत्र में कई डोमेन हो सकते हैं।

— लुकासकारो

10

सच नहीं है। (अब और नहीं, वैसे भी।)

— पार्थियन ने

7

डाउनवोटिंग क्योंकि पोस्ट में जानकारी अप्रचलित है। एसएनआई अब सभी प्रमुख ब्राउज़रों द्वारा समर्थित है।

— मार्टिन टॉर्नवॉल

5

उच्च विलंबता लिंक के लिए प्रारंभिक टीएलएस हैंडशेक को प्रमाण पत्र श्रृंखला (किसी भी मध्यवर्ती प्रमाणपत्र भेजने सहित) को मान्य करने के लिए अतिरिक्त दौर यात्राओं की आवश्यकता होती है, सिफर सुइट्स पर सहमत होते हैं और एक सत्र स्थापित करते हैं। एक बार सत्र स्थापित हो जाने के बाद, बाद के अनुरोध सत्र दौर की संख्या को कम करने के लिए सत्र कैशिंग का उपयोग कर सकते हैं, लेकिन इस सबसे अच्छे मामले में एक सामान्य HTTP कनेक्शन की तुलना में अभी भी अधिक दौर यात्राएं हैं। भले ही एन्क्रिप्शन ऑपरेशंस फ्री राउंड ट्राइसेप्स नहीं थे और यह धीमे नेटवर्क लिंक पर काफी ध्यान देने योग्य हो सकते हैं, खासकर अगर साइट http पिपलीलाइनिंग का लाभ नहीं उठाती है। ब्रॉडबैंड उपयोगकर्ताओं के लिए नेटवर्क के एक अच्छी तरह से जुड़े खंड के भीतर यह एक मुद्दा नहीं है। यदि आप अंतरराष्ट्रीय स्तर पर व्यापार करते हैं तो https आसानी से ध्यान देने योग्य देरी का कारण बन सकता है।

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

समय के साथ-साथ हार्डवेयर और नेटवर्क की क्षमताओं में सुधार होने के कारण ये सभी मुद्दे अधिक से अधिक गैर-मुद्दे बनते जा रहे हैं। ज्यादातर मामलों में मुझे संदेह है कि आज कोई भी ठोस अंतर है।

Https ट्रैफ़िक पर प्रशासनिक प्रतिबंध (जैसे मध्यवर्ती सामग्री फ़िल्टर..तो अल) संभवत: कुछ कॉर्पोरेट या सरकारी नियमों जैसे परिचालन संबंधी विचार हो सकते हैं। कुछ कॉर्पोरेट वातावरण को सूचना के रिसाव को रोकने के लिए परिधि में डेटा डिक्रिप्शन की आवश्यकता होती है ... हॉटस्पॉट और अज्ञात वेब आधारित एक्सेस सिस्टम के साथ हस्तक्षेप, जो https लेनदेन में संदेशों को इंजेक्ट करने में सक्षम नहीं है। दिन के अंत में मेरे विचार में डिफ़ॉल्ट रूप से https नहीं जाने के कारण काफी कम होने की संभावना है।

— आइंस्टाइन
स्रोत

4

सामान्य http की तुलना में https अधिक संसाधन-भूखा है।

यह सर्वर और क्लाइंट दोनों से अधिक मांग करता है।

— जोहान
स्रोत

3

यदि पूरे सत्र को एन्क्रिप्ट किया गया है, तो आप प्रॉक्सी स्तर जैसे आईएसपी पर छवियों और जेएस जैसे स्थिर संसाधनों के लिए कैशिंग का उपयोग नहीं कर पाएंगे।

— अलेक्सई तेनित्स्की
स्रोत

अच्छी तरह से, एसएसएल-टर्मिनेशन प्रॉक्सी को छोड़कर, या यदि आप एक HTTPS- सक्षम CDN का उपयोग कर रहे हैं।

— पार्थियन शॉट

3

आपको हर जगह HTTPS का उपयोग करना चाहिए, लेकिन आप निम्नलिखित को खो देंगे:

BREACH और CRIME हमलों के कारण आपको SSL पर SSL संपीड़न या HTTP संपीड़न का उपयोग नहीं करना चाहिए। यदि आपकी प्रतिक्रिया में सत्र या सीएसआरएफ पहचानकर्ता हैं तो कोई संपीड़न नहीं। आप कुकी-कम डोमेन पर अपने स्थैतिक संसाधन (चित्र, js, css) लगाकर इसे कम कर सकते हैं और वहां संपीड़न का उपयोग कर सकते हैं। आप HTML मिनिफिकेशन का भी उपयोग कर सकते हैं।
एक एसएसएल प्रमाणपत्र, एक आईपी पता, जब तक कि एसएनआई का उपयोग नहीं किया जाता है, जो सभी ब्राउज़रों (पुराने एंड्रॉइड, ब्लैकबेरी 6, आदि) पर काम नहीं करता है।
आपको अपने पृष्ठों पर किसी भी बाहरी सामग्री की मेजबानी नहीं करनी चाहिए जो एसएसएल पर नहीं आती है।
जब ब्राउज़र HTTP पृष्ठ पर जाता है, तो आप आउटबाउंड HTTP रेफ़र हेडर खो देते हैं, जो आपके लिए समस्या हो सकती है या नहीं भी हो सकती है।

— नील मैकगिगन
स्रोत

0

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

यह संभावित रूप से अंतिम उपयोगकर्ताओं के लिए भी भ्रामक है यदि सभी पते https://परिचित के बजाय उपयोग करते हैं http://। यह उत्तर भी देखें:

हमेशा js फाइल को शामिल करते समय https का उपयोग क्यों नहीं करना चाहिए?

— विल वूडेन
स्रोत

9

यह उपयोगकर्ताओं को भ्रमित क्यों करेगा? यूरी के प्रोटोकॉल को वास्तव में कितने देखते हैं?

— मलफिस्ट

आज, 10 साल बाद, https अधिक सामान्य है और http भ्रामक होगा

— madprops

0

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

— futureelite7
स्रोत

0

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

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

— 3Dave
स्रोत

2

चूंकि उपयोगकर्ता साइट के पहले से ही सुरक्षित हिस्से का हिस्सा है, इसलिए सर्टिफिकेट की लागत कम या ज्यादा होती है।

— Futureelite7

2

@ Futureelite7 अच्छा बिंदु है, लेकिन शायद दूसरों के लिए प्रासंगिक है जो भविष्य में इस विषय पर शोध कर सकते हैं।

— डीप

करतब करना सुरक्षा का दुश्मन है। मेरे स्वयं के सामान में अधिकांश कमजोरियों की जड़ें कुछ बीमार सलाह हैं, जो स्वयं या पूर्ववर्ती उत्पाद योजना में स्वीकार की जाती हैं। मुझे लगता है कि एक सुविधा को प्राप्त करना बंद हो गया है क्योंकि यह सुरक्षा भेद्यता का कारण बनता है जो आपको इसे पहले स्थान पर लाने की तुलना में अधिक लोकप्रिय नहीं बनाता है। लोकप्रियता SHOULDN'T मायने रखती है, लेकिन दुख की बात है कि यह कर सकता है और करता है। आपके जूते में, मैं खुद से पूछूंगा कि मैं वास्तव में असुरक्षित उपयोगकर्ताओं के साथ कितना व्यवहार करना चाहता हूं, या क्या ऐप उन उपयोगकर्ताओं के लिए भी उपयुक्त है जो एन्क्रिप्शन का उपयोग नहीं कर सकते हैं (सोचें: बैंकिंग, राजनीति, सक्रियता)।

— जेसन

0

मुझे बताया गया था कि हमारी कंपनी के एक प्रोजेक्ट पर, उन्होंने पाया कि SSL संदेशों द्वारा की गई बैंडविड्थ सादे संदेशों की तुलना में काफी अधिक थी। मेरा मानना है कि किसी ने मुझे बताया कि यह 12 बार एक चौंकाने वाला डेटा था। मैंने इसे स्वयं सत्यापित नहीं किया है और यह बहुत अधिक लगता है, लेकिन यदि प्रत्येक पृष्ठ पर कुछ प्रकार के हेडर जोड़े जाते हैं और अधिकांश पृष्ठों में कम मात्रा में सामग्री होती है, तो यह अब तक संभव नहीं है।

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

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

— नीलकंठ
स्रोत

1

सबसे खराब स्थिति में भी अतिरिक्त बैंडविड्थ छोटा है।

— राष्ट्रपति जेम्स के। पोल्क

0

एक अन्य छोटा बिंदु (हो सकता है कि कोई व्यक्ति सत्यापित कर सकता है), यदि कोई उपयोगकर्ता प्रपत्र आइटम में डेटा टाइप करता है जैसे कि टेक्स्ट बॉक्स और फिर किसी कारण से पृष्ठ को ताज़ा करता है या सर्वर एक सेकंड के लिए क्रैश हो जाता है, तो उपयोगकर्ता द्वारा दर्ज किया गया डेटा उपयोग करके खो जाता है HTTPS लेकिन HTTP का उपयोग करके संरक्षित है।

नोट: मुझे यकीन नहीं है कि यह ब्राउज़र विशिष्ट है लेकिन यह निश्चित रूप से मेरे फ़ायरफ़ॉक्स ब्राउज़र के साथ होता है।

— toc777
स्रोत

0

IIS 8.0 के साथ विंडोज़ सर्वर 2012 अब SNI प्रदान करता है जो सर्वर नेम इंडिकेशन है जो IIS में कई SSL वेब अनुप्रयोगों को एक आईपी पते पर होस्ट करने की अनुमति देता है।

— Webmaister
स्रोत

1

प्रश्न के साथ क्या करना है? यह एक दिलचस्प विशेषता है, लेकिन मैं प्रासंगिकता नहीं देखता हूं।

— user1618143