क्या http से https में रीडायरेक्ट करना बुरा है?

247

मैंने अभी-अभी अपने सर्वर पर एक SSL प्रमाणपत्र स्थापित किया है।

फिर उसने पोर्ट 80 पर मेरे डोमेन पर सभी ट्रैफ़िक के लिए रीडायरेक्ट को पोर्ट 443 पर रीडायरेक्ट किया।

दूसरे शब्दों में, मेरा सारा http://example.comट्रैफ़िक अब https://example.comपृष्ठ के उपयुक्त संस्करण पर पुनर्निर्देशित हो गया है ।

रीडायरेक्ट मेरे अपाचे वर्चुअल होस्ट्स फ़ाइल में कुछ इस तरह से किया गया है ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]

मेरा सवाल है, क्या एसएसएल का उपयोग करने में कोई कमियां हैं?

चूँकि यह 301 रीडायरेक्ट नहीं है, तो क्या मैं सर्च इंजन में लिंक जूस / रैंकिंग को स्विच करके खो दूंगा https?

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

अद्यतन ISSUE

अजीब तरह से बिंग मेरी साइट से अब यह स्क्रीनशॉट बनाता है कि यह हर जगह HTTPS का उपयोग कर रहा है ...

यहां छवि विवरण दर्ज करें

— JasonDavis
स्रोत

12

[डब्ल्यूटीएफ - मैं उत्तर नहीं जोड़ सकता (हालांकि लगता है कि मेरे पास पर्याप्त प्रतिनिधि है)।] मेरा उत्तर (भाग में) यह होगा कि आईटी आईटी बीएडी है । HTTP पर GET में एक COOKIE या API कुंजी पास करने पर विचार करें। यदि आपकी साइट HTTP अनुरोधों को HTTPS अनुरोधों पर पुनर्निर्देशित करती है, तो ये कॉल काम करेंगे, लेकिन COOKIE या API कुंजी को स्पष्ट उजागर किया जाएगा। कुछ एपीआई HTTP को बंद कर देते हैं, एक अधिक मजबूत दृष्टिकोण - कोई HTTP बिल्कुल नहीं ताकि आप इसे तब तक काम न कर सकें जब तक कि आप HTTPS का उपयोग न करें। उदाहरण: "सभी एपीआई अनुरोध HTTPS से अधिक होने चाहिए। स्ट्रिप

— docs/

8

@codingoutloud - विकल्प यह है कि पूरी बात HTTP पर होती है जिसमें कोई HTTPS नहीं होता है। यह कैसे बेहतर है?

— मार्क हेंडरसन

3

@BenCrowell, ऐसा इसलिए है क्योंकि एक कैप्टिव पोर्टल एक भयानक बहुत कुछ दिखता है जैसे -स्टाइल sslstripरिडायरेक्ट अटैक (वे दोनों मैन-इन-द-मिडल रिक्वेस्ट हाईजैक हैं ) इसलिए HSTS -aware ब्राउज़र उन दोनों को ब्लॉक कर देगा।

— जेफरी हंटिन

3

ध्यान रखें कि https का उपयोग करने का अर्थ है कि आपके द्वारा शामिल की जाने वाली प्रत्येक चीज़ का भी https होना चाहिए या यह लोड नहीं हो सकता है - जैसे कि लोडिंग jquery का उपयोग करना src="://example.com/jquery.js"- नोट करें httpया httpsइसलिए ब्राउज़र उपयुक्त लोड करता है। मेरे पास एक बुरा सपना था जो कुछ एम्बेडेड अमेज़ॅन सामान को ठीक से लोड करने के लिए कोशिश कर रहा था क्योंकि एपीआई (https के माध्यम से लोड) ने http लिंक का उत्पादन किया - जिसका अर्थ है कि वे ठीक से काम नहीं करते थे जब तक कि मुझे https लिंक टॉगल करने के लिए अनिर्धारित पैरामीटर नहीं मिला

— बेसिक

3

जेसन; आपका अद्यतन एक नया प्रश्न होना चाहिए, शायद वेबमास्टर्स पर क्योंकि यह आपके मूल प्रश्न से असंबंधित (तकनीकी रूप से) है। लेकिन यह शायद है कि आपकी स्टाइल शीट एक असुरक्षित डोमेन से आ रही हैं।

— मार्क हेंडरसन

316

[R]अपने दम पर झंडा एक है 302पुनर्निर्देशन ( Moved Temporarily)। यदि आप वास्तव में अपनी साइट के HTTPS संस्करण (संकेत: आप करते हैं) का उपयोग कर रहे लोगों को चाहते हैं, तो आपको [R=301]स्थायी लाल रंग का उपयोग करना चाहिए :

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L]

A 301आपके सभी google-fu और हार्ड-अर्जित पेजरेंकों को बरकरार रखता है । सुनिश्चित करें कि mod_rewriteसक्षम है:

a2enmod rewrite

आपके सटीक प्रश्न का उत्तर देने के लिए:

क्या http से https में रीडायरेक्ट करना बुरा है?

बिलकुल नहीं। यह बहुत अच्छा है।

— मार्क हेंडरसन
स्रोत

3

जानकारी के लिए धन्यवाद, मेरे बॉस मुझे इसका कारण बता रहे हैं क्योंकि वह केवल अपनी साइट के कुछ पन्नों पर ही https चलाता है, यह है कि यह हर पेज पर इसे चलाने के लिए बहुत अधिक सर्वर संसाधनों का उपयोग करता है। क्या आप इसके बारे में कुछ जानते हैं या अगर यह सच है?

— जेसनडैविस

9

@ajondavis केवल अगर आप इसे अनुकूलित करने के लिए कुछ मिनट खर्च नहीं करते हैं ।

— माइकल हैम्पटन

10

"यह हर पृष्ठ पर इसे चलाने के लिए बहुत अधिक सर्वर संसाधनों का उपयोग करता है।" आधुनिक सीपीयू में एन्क्रिप्शन त्वरण विशेषताएं हैं जो एसएसएल को लगभग मुफ्त बनाती हैं। ओवरहेड के बारे में चिंता मत करो।

— एडम डेविस

41

@AdamDavis क्रिप्टो एल्गोरिदम हल्का हो सकता है, लेकिन हैंडशेक ओवरहेड अभी भी मौजूद है। इसके अलावा, HTTPS आपकी सामग्री को कैशिंग से HTTP प्रॉक्सी को रोकता है। में सबसे मामलों, HTTPS के ऊपरी न्यूनतम और सार्थक है, लेकिन अति-सामान्यीकरण के बारे में सावधान रहना है।

— २०० २।

6

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

— जॉन हैना

49

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

आंतरिक लिंक के लिए पूरी साइट की जाँच करें और सुनिश्चित करें कि आप सभी HTTPS का उपयोग कर रहे हैं यदि आप लिंक में अपना स्वयं का डोमेन नाम निर्दिष्ट करते हैं, तो आप अपने स्वयं के रीडायरेक्ट का कारण नहीं बन रहे हैं।
<meta property="og:url"अपने डोमेन के https संस्करण का उपयोग करके अपना अपडेट करें ।
यदि आप <base href=HTTPS का उपयोग करने के लिए फिर से अपडेट का उपयोग करते हैं।
यदि संभव हो तो SPDY प्रोटोकॉल स्थापित करें
अनुरोध की संख्या को कम करने के लिए सीएसएस छवि स्प्राइट का उपयोग करना सुनिश्चित करें।
Https स्थिति को इंगित करने के लिए अपने साइटमैप को अपडेट करें, ताकि समय के साथ मकड़ियों को यह परिवर्तन सीखें।
HTTPS को पसंद करने के लिए Google Webmaster Tools जैसी खोज इंजन प्राथमिकताएं बदलें
जहां HTTPS CDN सर्वर पर किसी भी स्टैटिक मीडिया को ऑफ-लोड किया जा सकता है।

यदि उपरोक्त संबोधित किया गया है, तो मुझे संदेह है कि आपके पास कई मुद्दे होंगे।

— TheBritishGeek
स्रोत

SPDY एक अच्छा सुझाव है; यहां तक कि Apache 2.x में SPDY समर्थन को जोड़ने वाला एक मॉड्यूल भी प्रतीत होता है ।

— २३:२५ बजे कैलरीन २ion

18

का उपयोग करना "//yourserver.com/some-uri" के बदले " yourserver.com/some-uri " निराकरण मुद्दा (1) क्योंकि ब्राउज़र उचित स्कीमा ले जाएगा (http या https) स्कीमा पृष्ठ के साथ लोड किया गया था पर निर्भर करता है ।

— मगनराना

1

@MauganRa जब तक, निश्चित रूप से, यह http लेख पृष्ठ से https लॉगिन पृष्ठ के लिए एक लिंक है, उदाहरण के लिए।

— मोलॉट

4

Google उस URL को देखता है जिसे Refererहेडर के माध्यम से कोई व्यक्ति देख रहा है । उदाहरण के लिए यह साइट Google के CDN से jQuery का उपयोग करती है और मेरा ब्राउज़र Google को हर बार साइट को फिर से लोड करने के लिए एक अनुरोध भेजता है। जिससे RefererGoogle को एक हेडर भी भेजा जाता है जो इस साइट के URL पर सेट है। इसलिए Google उन साइटों को ट्रैक कर सकता है जो मैं उस समय देख सकता हूं जब मेरा आईपी पता नहीं बदलता (और अगर मैं इस दौरान Google सेवा का उपयोग करता हूं, तो Google इस जानकारी को मेरे Google खाते से भी जोड़ सकता है)।

— Stephan Kulla

1

1 के लिए) मैंने सिर्फ MySQL डेटाबेस http में https के लिए एक खोज और प्रतिस्थापित किया ... मैं वर्डप्रेस का उपयोग कर रहा हूं ताकि सैकड़ों लिंक अपडेट करना आसान हो गया

— जेसनडेविस

38

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

Http से https तक पुनर्निर्देशन के बारे में जवाब इतना आसान नहीं है।

रीडायरेक्ट करना आपके उपयोगकर्ताओं के लिए बहुत आसान हो जाएगा, वे सिर्फ whateversite.com में टाइप करते हैं और https पर पुनर्निर्देशित हो जाते हैं।

परंतु। क्या होगा यदि उपयोगकर्ता कभी-कभी असुरक्षित नेटवर्क पर है (या ट्रॉय हंट और उसके अनानास के करीब है )? फिर उपयोगकर्ता पुरानी आदत से http://whateversite.com का अनुरोध करेगा । वह है http। जिससे समझौता किया जा सके। रीडायरेक्ट https://whateversite.com.some.infrastructure.long.strange.url.hacker.org की ओर इशारा कर सकता है । एक साधारण उपयोगकर्ता के लिए यह काफी कानूनी होगा। लेकिन यातायात को बाधित किया जा सकता है।

इसलिए हमारे पास दो प्रतिस्पर्धी आवश्यकताएं हैं: उपयोगकर्ता के अनुकूल होने और सुरक्षित होने के लिए। सौभाग्य से, एक उपाय है जिसे एचएसएसएस हेडर कहा जाता है । इसके साथ आप रीडायरेक्ट को सक्षम कर सकते हैं। ब्राउज़र सुरक्षित साइट पर चला जाएगा, लेकिन एचएसटीएस हेडर के लिए धन्यवाद भी इसे याद रखें। जब उपयोगकर्ता उस असुरक्षित नेटवर्क पर बैठे whateversite.com में टाइप करता है, तो ब्राउज़र http पर तुरंत चला जाएगा, बिना http पर रीडायरेक्ट किए बिना। जब तक आप बहुत संवेदनशील डेटा से निपटते हैं, मुझे लगता है कि अधिकांश साइटों के लिए सुरक्षा और उपयोगिता के बीच एक निष्पक्ष व्यापार है। (जब मैंने हाल ही में मेडिकल रिकॉर्ड्स को संभालने वाला एक एप्लिकेशन सेट किया तो मैं सभी https बिना रीडायरेक्ट चला गया)। दुर्भाग्य से इंटरनेट एक्सप्लोरर के पास एचएसटीएस ( स्रोत) के लिए कोई समर्थन नहीं है), इसलिए यदि आपके लक्षित दर्शक ज्यादातर IE का उपयोग कर रहे हैं और डेटा संवेदनशील है तो आप रीडायरेक्ट को निष्क्रिय करना चाहते हैं।

इसलिए यदि आप IE उपयोगकर्ताओं को लक्षित नहीं कर रहे हैं, तो आगे बढ़ें और रीडायरेक्ट का उपयोग करें, लेकिन साथ ही साथ एचएसटीएस हेडर को भी सक्षम करें।

— एंडर्स हाबिल
स्रोत

अधिक लोगों को इस पर भी ध्यान देने की आवश्यकता है। एक और बात यह है कि लोग मानते हैं कि वे सुरक्षित हैं क्योंकि अंतिम बिंदु HTTPS है, इस तथ्य की अनदेखी करते हुए कि GET या POST में पृष्ठ पर भेजी गई सभी जानकारी सादे पाठ में है।

— वेलॉक्स

3

@ वेलॉक्स - मुझे नहीं लगता कि "लोगों का मानना है कि वे सुरक्षित हैं क्योंकि अंतिम बिंदु HTTPS है, इस तथ्य की अनदेखी करते हुए कि GET या POST में पेज पर भेजी गई सभी जानकारी सादे पाठ में है" काफी सटीक है। जबकि कुछ गोचैट हैं, HTTPS पर परिवहन के दौरान स्पष्ट रूप से यात्रा नहीं करते हैं। उदाहरण के लिए देखें: stackoverflow.com/questions/323200/… POST पेलोड भी सुरक्षित हैं, जबकि लॉगिंग और रेफर हेडर के लिए भी असुरक्षित नहीं है।

— कोडिंगआउटलाड

@codingoutloud यह मेरी बात है। HTTPS से अधिक वे एन्क्रिप्टेड हैं, लेकिन HTTP पेज के शुरुआती अनुरोध में वे नहीं थे।

— वेलोक्स

1

@Velox - यदि पूरी साइट HTTPS पर पुनर्निर्देशित हो रही है, तो यह संभव नहीं है कि HTTPS के किक करने से पहले कोई भी GET पैरामीटर भेजा जाएगा (और उस बिंदु के बाद सबकुछ HTTPS रहेगा)। अभी भी एक प्रारंभिक अनुरोध है जहां कुकीज़ भेजी जाएंगी, जिसे एचएसटीएस के साथ रीमेड किया जा सकता है ... और एसएसएलस्ट्रिप के लिए एक छोटी सी हमले की खिड़की, जिसे संभवतः जावास्क्रिप्ट द्वारा हराया जा सकता है, लेकिन यह अपनी खुद की एक हथियारों की दौड़ है।

— ब्रिलियनड

@ ब्रिलियनड फेयर प्वाइंट, लेकिन सुरक्षा में कमजोर बिंदु पूरी बात को कमजोर बना देता है। हमेशा विचार करने लायक।

— वेलॉक्स

22

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

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

301स्थिति कोड को इंगित करता है स्थायी रीडायरेक्ट, सक्षम ग्राहकों को निर्देश (जैसे बुकमार्क अपडेट) भविष्य कनेक्शन के लिए सुरक्षित URL का उपयोग करें।

यदि आप केवल TLS / SSL से अधिक साइट पर सेवा दे रहे हैं, तो मैं आपके सुरक्षित वर्चुअल होस्ट में HTTP सख्त परिवहन सुरक्षा (HSTS) को सक्षम करने के लिए एक और निर्देश सुझाऊंगा :

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

यह शीर्ष लेख सक्षम ग्राहकों (इन दिनों उनमें से अधिकांश, मुझे विश्वास है) का निर्देश है कि वे केवलsecure.example.com अगले 1234सेकंड के लिए प्रदान किए गए डोमेन ( इस मामले में) के साथ HTTPS का उपयोग करें । ; includeSubdomainsभाग है वैकल्पिक और इंगित करता है कि यह निर्देश सिर्फ मौजूदा डोमेन के लिए नहीं लागू होता है, लेकिन यह (उदाहरण के लिए के तहत किसी भी alpha.secure.example.com)। ध्यान दें कि एसएसएल / टीएलएस कनेक्शन पर सेवा करते समय एचएसटीएस हेडर केवल ब्राउज़रों द्वारा स्वीकार किया जाता है!

वर्तमान सर्वोत्तम अभ्यास के विरुद्ध अपने सर्वर कॉन्फ़िगरेशन का परीक्षण करने के लिए, एक अच्छा मुक्त संसाधन है क्वालिस एसएसएल सर्वर टेस्ट सेवा; मैं कम से कम A- स्कोर करने का लक्ष्य रखता हूं (आप अण्डाकार वक्र क्रिप्टोग्राफी के लिए समर्थन की कमी के कारण Apache 2.2 के साथ इससे अधिक नहीं प्राप्त कर सकते हैं)।

— Calrion
स्रोत

मुझे जोड़ना चाहिए, हेडर भेजने से Strict-Transport-Security: max-age=0किसी भी पिछले निर्देश को नकार दिया जाएगा; हमेशा की तरह, यह स्वीकार किए जाने के लिए HTTPS पर भेजा जाना चाहिए, लेकिन अगर आप यह भी तय करते हैं कि आपको डोमेन पर HTTP का उपयोग करने की आवश्यकता है, तो चीजों को रद्द करने का एक आसान तरीका है।

— कालरात्रि

5

वाह ! HTTP को HTTPS पर पुनर्निर्देशित करना एक बहुत अच्छी बात है और मैं इसके लिए कोई कमियां नहीं देख सकता।

बस सुनिश्चित करें कि आपके ग्राहकों के पास ब्राउज़र में प्रमाणपत्र के बारे में गैर-उपयोगकर्ता-अनुकूल चेतावनियों से बचने के लिए सही CA है।

इसके अलावा, आपके पास Apache को HTTPS पर पुनर्निर्देशित करने का तरीका ठीक लगता है।

— krisFR
स्रोत

5

क्या http से https में रीडायरेक्ट करना बुरा है?

नहीं, बिलकुल नहीं। वास्तव में, यह एक अच्छी बात है!

पुनर्निर्देशन पर:

यह पुनर्लेखन को पूरी तरह से समाप्त करके, अधिक कुशल हो सकता है । ऐसी ही स्थिति पर मेरा कॉन्फिगरेशन ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

— पोथी कालीमुथु
स्रोत

4

HTTPS वास्तव में मूर्ख नहीं है। बेशक, आम तौर पर मजबूर HTTPS एक अच्छी बात है। यह सामान्य अपराधियों को आपके उपयोगकर्ताओं के साथ कुछ भी बुरा करने से रोकता है।

लेकिन SSLCiphers सेटिंग की तरह SSL सेटिंग्स को चेक करना न भूलें। RC4 क्रिप्टो, SSLv2 और SSLv3 प्रोटोकॉल जैसी चीजों को अक्षम करें। इसके अलावा, आपको यह पता लगाना चाहिए कि क्या आपके सिस्टम का क्रिप्टो-सिस्टम लिबरी TLS1.2 का समर्थन करता है (जो आपके पास जो चीज है;);

SSL, इसकी अच्छी बात है।

— टोबियास मैडेल
स्रोत

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

— गाइल्स

क्षमा करें, क्या ? लिनक्स पर कई ऑपरेशन हैं जो PRNG- आधारित शायद-अच्छे-पर्याप्त एन्ट्रॉपी के बजाय हार्डवेयर-व्युत्पन्न मजबूत एन्ट्रापी पर जोर देते हैं, और पूल की गहराई कम होने पर वे वास्तव में ब्लॉक कर सकते हैं। लिनक्स सिस्टम पर पर्याप्त एन्ट्रापी के साथ शुरू करना सबसे निश्चित रूप से संभव है, लेकिन पूल को खाली करने के लिए अति प्रयोग से, जिससे कुछ ऑपरेशन अवरुद्ध हो सकते हैं।

— मदहैटर

3

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

— Vality
स्रोत

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

— हाकिन लिंडक्विस्ट

3

यहाँ कुछ व्यापक ब्रशस्ट्रोक मुद्दे हैं:

MITM / SSLSTRIP : यह एक विशाल चेतावनी है। यदि आप HTTPS पर अपनी साइट की सेवा करने जा रहे हैं, तो साइट पर HTTP को अक्षम करें । अन्यथा, आप अपने उपयोगकर्ताओं को SSLSTRIP सहित विभिन्न मैन-इन-द-बीच के हमलों के लिए खुला छोड़ देते हैं, जो अनुरोधों को रोकेंगे और चुपचाप एचटीटीपी पर अपनी स्वयं की मालवेयर स्क्रिप्ट को स्ट्रीम में डालकर उनकी सेवा करेंगे। यदि उपयोगकर्ता ध्यान नहीं देता है, तो वे सोचेंगे कि उनका सत्र सुरक्षित है जब यह वास्तव में नहीं है।
- हालाँकि, इसके साथ समस्या यह है कि यदि आपकी साइट एक सार्वजनिक साइट है और आप सिर्फ HTTP को अनजाने में अक्षम कर देते हैं, तो आप बहुत सारे आगंतुकों को खो सकते हैं। यह शायद भी नहीं होंगे तब हो उन्हें यदि साइट HTTP के साथ लोड नहीं होगा HTTPS कोशिश करने के लिए।
यदि आपकी साइट को एक सुरक्षित लॉगिन की आवश्यकता है, तो पूरे उपयोगकर्ता सत्र को सुरक्षित किया जाना चाहिए। HTTPS पर प्रमाणित न करें, फिर उपयोगकर्ता को HTTP पर वापस भेज दें। यदि आप फिर से करते हैं, तो आप अपने उपयोगकर्ताओं को MITM हमलों के लिए असुरक्षित छोड़ रहे हैं। इन दिनों प्रमाणीकरण के लिए मानक दृष्टिकोण एक बार प्रमाणित करना है, फिर एक प्रमाणीकरण टोकन को आगे और पीछे (एक कुकी में) पास करें। लेकिन अगर आप HTTPS से अधिक प्रमाणित करते हैं तो HTTP पर रीडायरेक्ट करते हैं तो एक आदमी बीच-बीच में उस कुकी को रोक सकता है और साइट का उपयोग कर सकता है जैसे कि वे आपके प्रमाणित उपयोगकर्ता हैं, आपकी सुरक्षा को दरकिनार करते हुए।
HTTPS के साथ "प्रदर्शन" मुद्दे एक नया कनेक्शन बनाने में शामिल हैंडशेक तक सीमित सभी व्यावहारिक उद्देश्यों के लिए हैं। एक URL से कई HTTPS कनेक्शन की आवश्यकता को कम करने के लिए आप क्या कर सकते हैं और आप मीलों आगे रहेंगे। और यह सच है कि भले ही आप HTTP पर अपनी सामग्री परोस रहे हों। यदि आप SPDY पर पढ़ते हैं, तो आप महसूस करेंगे कि यह सब कुछ एक ही कनेक्शन पर एक URL से सभी सामग्री की सेवा करने की कोशिश में उन्मुख है। हां, HTTPS का उपयोग कैशिंग को प्रभावित करता है। लेकिन इन दिनों कितनी वेब साइटें केवल स्थिर, कैचवेबल सामग्री हैं? आपके वेब सर्वर पर कैशिंग का उपयोग करके आपके हिरन के लिए अधिक धमाके होने की संभावना है, अनावश्यक डेटाबेस प्रश्नों को कम करने के लिए, बार-बार अपरिवर्तित डेटा प्राप्त करना, और महंगे कोड रास्तों को आवश्यकता से अधिक बार निष्पादित करने से रोकना।

— क्रेग
स्रोत

बात यह है कि आप वास्तव में sslstrip को संबोधित करने के लिए HSTS का उपयोग कर सकते हैं (अधिमानतः अपने HSTS सेटिंग्स प्रीलोड प्राप्त करें )। चाहे आप सादे HTTP पर अनुरोध स्वीकार करते हैं या वास्तव में इस संबंध में कोई बात नहीं करते हैं, MITM सादे HTTP पर जवाब दे सकता है (संभवतः आपके HTTPS साइट पर प्रॉक्सी करना) भले ही आप HTTPS अनुरोधों को स्वीकार करते हैं।

— हाकिन लिंडक्विस्ट

@ HåkanLindqvist मैं वास्तव में आप से एक गिरावट अर्जित की है? क्या मैंने HTTPS पर प्रमाणीकरण न करने और शेष सत्र के लिए HTTP पर स्विच करने के संबंध में बुरी सलाह या अच्छी सलाह दी थी? क्या मैंने HTTPS प्रदर्शन मिथकों के संबंध में बुरी सलाह दी है? इसके अलावा, यदि क्लाइंट शुरू में HTTPS का उपयोग करके कनेक्ट करने का प्रयास करता है, तो MITM अवरोधन नहीं कर सकता और ब्राउज़र में अलर्ट ट्रिगर किए बिना प्रतिक्रिया कर सकता है, क्योंकि उनका प्रमाण पत्र तब तक मेल नहीं करेगा जब तक कि उनके पास चोरी या सफलतापूर्वक जाली प्रमाण पत्र न हो। दूसरी ओर, यदि साइट HTTP कनेक्शन स्वीकार करती है, तो अवरोधन आसान है। किसी भी तरह से, HTTPS बार उठाता है।

— क्रेग

.. और निश्चित रूप से मैं HSTS का उपयोग करने के लिए तहे दिल से सहमत हूं।

— क्रेग

उत्तर के साथ मेरी समस्या सूची में पहला आइटम है, जो sslstrip को संबोधित करने का दावा करता है, जबकि यह वास्तव में (मिथकों की बात नहीं करता है)। मैं अपनी प्रारंभिक टिप्पणी में जो पाने की कोशिश कर रहा था वह यह है कि यदि आपके पास एक सक्रिय MITM है (जो कि आपको पहले स्थान पर sslstrip की आवश्यकता है), तो हमलावर अनिवार्य रूप से ग्राहक के दृष्टिकोण से "साइट" हो सकता है; यह हमलावर है जो यह तय करता है कि अगर वे क्लाइंट से सादे HTTP कनेक्शन को स्वीकार करना चाहते हैं, तो आपका वास्तविक वेब सर्वर उस संबंध में कैसे व्यवहार करता है, जो हमलावर को प्रभावित कर सकता है या नहीं करेगा।

— हाकान लिंडक्विस्ट

@ HåkanLindqvist सिवाय इसके कि अगर आगंतुक जानबूझकर HTTPS के साथ जुड़ने की कोशिश कर रहा है, तो हमलावर ब्राउज़र में झंडे फेंकने के बिना उस अनुरोध को संतुष्ट नहीं कर सकता, जब तक कि वे सर्वर प्रमाण पत्र चोरी करने में कामयाब न हों या किसी तरह सफलतापूर्वक एक बना हो, जिसे उन्हें करना होगा HTTP से कनेक्शन स्विच करने के लिए क्या करें। HTTPS अभी भी बार उठाता है। बेशक अगर आगंतुक HTTP पर प्रारंभिक कनेक्शन का प्रयास करता है, तो सभी दांव पूरी तरह से बंद हैं।

— क्रेग

1

यह तकनीकी रूप से आपके मूल प्रश्न का उत्तर नहीं है, लेकिन यदि आप Google Chrome एक्सटेंशन HTTPSEverywhere का उपयोग करते हैं (मुझे यकीन है कि अन्य ब्राउज़रों पर समान एक्सटेंशन हैं), एक्सटेंशन स्वचालित रूप से HTTP के साथ साइटों को HTTPS के साथ उसी साइट पर पुनर्निर्देशित करता है। मैं इसे थोड़ी देर के लिए उपयोग कर रहा हूं, और मुझे कोई समस्या नहीं है (शायद मंदी के अलावा, लेकिन मैंने इसका परीक्षण नहीं किया है)। HTTPSEverywhere को सर्वर साइड पर कुछ नियमों द्वारा बदला जा सकता है, लेकिन चूंकि मैंने उस क्षेत्र में बहुत कुछ नहीं किया है, इसलिए मुझे सटीक विवरणों पर यकीन नहीं है।

अपने वास्तविक प्रश्न पर वापस जाएं, यदि आप HTTPSEverywhere जैसी किसी चीज़ का उपयोग करते हैं, तो HTTP-केवल का उपयोग करने के लिए और भी कम प्रोत्साहन है, हालांकि मुझे लगता है कि जब आपको उनकी आवश्यकता होती है, तो सही नियम स्थापित करना कठिन होता है।

— trysis
स्रोत

1

HTTP पर HTTPS का एकमात्र तकनीकी ड्रा यह है कि यह HTTPS अनुरोधों को सामान्य HTTP से संसाधित करने के लिए कम्प्यूटेशनल रूप से अधिक महंगा है

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

SPDY जैसे प्रोटोकॉल के आगमन के लिए जिन्हें SSL / TLS को काम करने की आवश्यकता होती है, यह वास्तव में aforementioned कम्प्यूटेशनल ओवरहेड को कई अनुरोधों के साथ महत्वपूर्ण प्रदर्शन में सुधार और समग्र रूप से क्लाइंट को संपत्ति प्राप्त करने के लिए महत्वपूर्ण बनाता है।

— anthonysomerset
स्रोत

HTTPS प्रदर्शन के साथ मुद्दा यह है कि एक नया कनेक्शन स्थापित करना अधिक महंगा है क्योंकि इसमें अधिक गोल-यात्राएं शामिल हैं और क्योंकि सममित एन्क्रिप्शन / डिक्रिप्शन सममित एन्क्रिप्शन / डिक्रिप्शन की तुलना में बहुत अधिक महंगा है। एक बार कनेक्शन हैंडशेक एक साझा सममित एन्क्रिप्शन कुंजी स्थापित करता है, चल रहा ओवरहेड वस्तुतः अप्रासंगिक (बहुत छोटा) है। यदि आप SPDY पर पढ़ते हैं, तो आप देखेंगे कि अनिवार्य रूप से URL के सभी कन्टैंट का लक्ष्य एक ही कनेक्शन पर एक URL से सभी सामग्री को परोसना है, कनेक्शन हैंडशेक ओवरहेड को कम करना।

— क्रेग

1

यह https पर पुनर्निर्देशित करने के लिए बहुत अच्छा है, लेकिन मैंने पढ़ा है यह इस बात पर भी निर्भर करता है कि आप पुनर्निर्देशन को कैसे व्यवस्थित करते हैं।

आपके http कनेक्शन के लिए आने वाले http अनुरोधों को पुनर्निर्देशित करने के लिए एक समर्पित वर्चुअल सर्वर बनाना जैसा कि सुरक्षा पर जवाब में सुझाया गया है । stackexchange.com बहुत ही स्मार्ट लगता है और कुछ अतिरिक्त सुरक्षा खतरों को बंद कर देगा। अपाचे में एक विन्यास कुछ इस तरह दिखेगा:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>

— विल्ट
स्रोत