2010-10-29 15 views
16

सबसे पहले, मुझे यह मानने दो कि मुझे HTTPS के बारे में क्या पता है वह बहुत ही प्राथमिक है। मुझे सत्र सुरक्षा, एन्क्रिप्शन, या उन चीज़ों में से किसी एक के बारे में बहुत कुछ नहीं पता है।100% HTTPS साइट के पेशेवर और विपक्ष क्या हैं?

मुझे क्या पता है कि वेब सुरक्षा महत्वपूर्ण है; एक्सएसएस, सीएसआरएफ, और डेटाबेस इंजेक्शन की डरावनी कहानियां बार-बार पॉप-अप होती हैं। मुझे पता है कि इस तरह के शोषण के खिलाफ एक निवारक रुख एक प्रतिक्रियाशील से बेहतर है।

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

  • सीएसएस/global.css
  • js/global.js
  • छवियों/
    • logo.png
    • bg.png

जिस तरह से मैं इसे समझता हूं, इन फ़ाइलों को डुप्लिकेट करने की आवश्यकता है इससे पहले कि वे HTTPS में "जोड़ा" जा सकें। तो एक फ़ाइल या तो सुरक्षा (HTTPS) के तहत हो सकती है या नहीं।

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

तो मैं क्या जानना चाहता हूं, एचटीटीपीएस के पीछे पूरी तरह से साइट के पेशेवरों और विपक्ष क्या हैं? क्या यह ध्यान देने योग्य ओवरहेड का कारण बनता है? क्या पूरी साइट को एन्क्रिप्शन के तहत रखना मूर्खतापूर्ण है? क्या उपयोगकर्ता अपनी संपूर्ण यात्रा के दौरान अपने ब्राउज़र में "सुरक्षित" अधिसूचनाओं को सुरक्षित महसूस करेंगे? और अंतिम लेकिन कम से कम नहीं, क्या यह वास्तव में make for a more secure site है? HTTPS क्या सुरक्षा कर सकते हैं?

+4

देखें कि मैं क्या मंच आप उपयोग कर रहे पता नहीं है, लेकिन आईआईएस दुनिया में इसे करने के लिए * एक ही मैप करने के लिए आम है * साइट दोनों 80 * और * 443 यह कोई शाब्दिक दोहराव का मतलब । फिर कोड के भीतर आप यह लागू कर सकते हैं कि कुछ निश्चित पृष्ठ केवल HTTPS के माध्यम से पहुंच योग्य हैं। –

+6

यह ध्यान दिया जाना चाहिए कि एसएसएल (या ["टीएलएस"] (http://en.wikipedia.org/wiki/Transport_Layer_Security) का उपयोग करके इसे आजकल कहा जाता है) XSS, CSRF, या डेटाबेस इंजेक्शन भेद्यता के विरुद्ध नहीं रोकेगा –

+3

हाल ही में , सुरक्षा समुदाय में एक सम्मानित (कम से कम मेरे द्वारा) व्यक्ति से प्रासंगिक ब्लॉग प्रविष्टि: http://steve.grc.com/2010/10/28/why-firesheeps-time-has-come/ – Fantius

उत्तर

11

आप HTTP के माध्यम से एचटीटीपीएस के माध्यम से एक ही सामग्री की सेवा कर सकते हैं (बस इसे उसी दस्तावेज़ रूट पर इंगित करें)।

विपक्ष कि प्रमुख या मामूली हो सकता है, निर्भर करता है: HTTPS पर

  1. की सेवा सामग्री HTTP के माध्यम से यह सेवा करने की तुलना में धीमी है।
  2. प्रमाण पत्र प्रसिद्ध अधिकारियों द्वारा हस्ताक्षरित महंगा
  3. यदि आप एक प्रमाण पत्र एक विश्वसनीय प्राधिकरण द्वारा हस्ताक्षरित नहीं है (उदाहरण के लिए, आप इसे अपने आप को हस्ताक्षर) हो सकता है, आगंतुकों को एक चेतावनी

उन मिल जाएगा बहुत बुनियादी हैं, लेकिन ध्यान देने योग्य कुछ चीजें हैं। साथ ही, व्यक्तिगत रूप से, मैं यह देखकर बहुत बेहतर महसूस करता हूं कि पूरी साइट HTTPS है यदि यह वित्तीय सामान से संबंधित कुछ भी है, जाहिर है, लेकिन जहां तक ​​सामान्य ब्राउज़िंग है, नहीं, मुझे परवाह नहीं है।

6

ध्यान देने योग्य ओवरहेड?हां, लेकिन इन दिनों कम और कम मायने रखता है क्योंकि ग्राहक और सर्वर बहुत तेज हैं।

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

क्या संपूर्ण साइट को एन्क्रिप्शन के तहत रखना मूर्खतापूर्ण है? आम तौर पर नहीं।

क्या उपयोगकर्ता सुरक्षित महसूस करेंगे? शायद।

क्या यह वास्तव में एक और अधिक सुरक्षित साइट के लिए बनाता है? केवल ग्राहक और सर्वर के बीच संचार चैनल से निपटने के दौरान। बाकी सब कुछ अभी भी पकड़ने के लिए है।

3

एसएसएल के पीछे पूरी साइट न होने का पारंपरिक कारण समय प्रसंस्करण कर रहा है। एसएसएल का उपयोग करने के लिए क्लाइंट और सर्वर दोनों के लिए यह अधिक काम करता है। हालांकि, यह ओवरहेड आधुनिक प्रोसेसर की तुलना में काफी छोटा है।

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

आपको एक प्रमाणपत्र खरीदने की आवश्यकता है, या स्वयं हस्ताक्षरित एक का उपयोग करें जो आपके उपयोगकर्ताओं द्वारा भरोसा नहीं किया जा सकता है।

आपको एक समर्पित आईपी पता भी चाहिए। यदि आप एक साझा होस्टिंग सिस्टम पर हैं, तो आपको एक आईपी होना चाहिए जिसे आप अपनी साइट पर केवल SSL रखने के लिए समर्पित कर सकते हैं।

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

एसएसएल कमजोर पड़ने वाले हमलों की संख्या के साथ, मैं यह कहूंगा।

3

आपको इन फ़ाइलों की HTTP प्रतियों के साथ काम करने के लिए कई प्रतियों की आवश्यकता नहीं है। यदि होस्टिंग सेटअप कॉन्फ़िगर किया गया है, तो आपके पास इन फ़ाइलों की 2 प्रतियां होनी चाहिए ताकि आपके पास एक अलग https निर्देशिका हो। तो अपने प्रश्न का उत्तर देने के लिए - HTTP के लिए कोई डुप्लिकेट फ़ाइलें आवश्यक नहीं हैं लेकिन वेब होस्टिंग कॉन्फ़िगरेशन के आधार पर - वे हो सकते हैं।

https बनाम http के पेशेवरों और विपक्ष के संबंध में पहले से ही कुछ पदों को संबोधित कर रहे हैं। HTTP vs HTTPS performance HTTPS vs HTTP speed comparison

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

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

4

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

प्रत्येक अन्य पृष्ठ के लिए जहां आप http (असुरक्षित) के तहत साइट चला रहे हैं, आप उसी स्थान पर उन फ़ाइलों को संदर्भित कर सकते हैं, लेकिन एक http पते के साथ।

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

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

+1

यह ज्यादातर फ़ायरफ़ॉक्स 2 है https सामग्री को कैशिंग करने के संबंध में यह मुश्किल है, इसलिए मैं इसके बारे में चिंता नहीं करता। – rlovtang

1

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

http://support.apple.com/kb/ht2900

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

1

एक निम्नलिखित महत्वपूर्ण अपनी साइट पर अधिक https के लिए "समर्थक" है:

एक उपयोगकर्ता, एन्क्रिप्ट न किए गए Wi-Fi के माध्यम से जोड़ने की तरह एक हवाई अड्डे पर, https में उनके पासवर्ड दे सकते हैं, लेकिन साइट अगर फिर पासवर्ड पेज के बाद http पर वापस स्विच करता है, सत्र कुकी का खुलासा हो जाता है और इसे तुरंत एक छिपकली द्वारा उपयोग किया जा सकता है।

इस लेख http://steve.grc.com/2010/10/28/why-firesheeps-time-has-come/#comment-2666

संबंधित मुद्दे