सवाल Http को https पर रीडायरेक्ट करना बुरा है?


मैंने बस अपने सर्वर पर एक एसएसएल प्रमाणपत्र स्थापित किया है।

इसके बाद पोर्ट 80 पर पोर्ट 443 पर रीडायरेक्ट करने के लिए मेरे डोमेन पर सभी ट्रैफ़िक के लिए रीडायरेक्ट स्थापित किया गया।

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

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

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

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

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

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


अद्यतन मुद्दा

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

enter image description here 


245
2018-01-28 00:12


मूल


[डब्ल्यूटीएफ - मैं जवाब नहीं जोड़ सकता (हालांकि लगता है कि मेरे पास पर्याप्त प्रतिनिधि है)।] मेरा जवाब (भाग में) होगा कुछ समय बीत चुका है। HTTP पर एक GET में एक कुकी या एपीआई कुंजी पास करने पर विचार करें। यदि आपकी साइट HTTP अनुरोधों को HTTPS अनुरोधों पर रीडायरेक्ट करती है, तो ये कॉल काम करेंगे, लेकिन कुकी या एपीआई कुंजी स्पष्ट - खुलासा में प्रसारित की जाएगी। कुछ एपीआई HTTP बंद कर देते हैं, एक अधिक मजबूत दृष्टिकोण - कोई भी HTTP नहीं, इसलिए जब तक आप HTTPS का उपयोग नहीं करते हैं तब तक आप इसे तब तक काम नहीं कर सकते हैं। उदाहरण: "सभी एपीआई अनुरोध HTTPS पर किए जाने चाहिए। सादे HTTP पर किए गए कॉल" विफल हो जाएंगे stripe.com/docs/api?lang=php#authentication - codingoutloud
@codingoutloud - विकल्प यह है कि पूरी बात एचटीटीपीएस के बिना HTTP पर होता है। यह कैसे बेहतर है? - Mark Henderson♦
@ बेनक्रोवेल, ऐसा इसलिए है क्योंकि ए कैप्टिव पोर्टल एक की तरह एक भयानक लग रहा है sslstripस्टाइल रीडायरेक्ट हमला (वे दोनों मैन-इन-द-बीच अनुरोध हाइजैक हैं) तो HSTS-वेयर ब्राउज़र उन्हें दोनों ब्लॉक करेंगे। - Jeffrey Hantin
ध्यान रखें कि https का उपयोग करना मतलब है कि जो भी आप शामिल करते हैं वह भी https होना चाहिए या यह लोड नहीं हो सकता है - उदाहरण के लिए लोड jquery src="://example.com/jquery.js" - की कमी ध्यान दें http या https तो ब्राउज़र उपयुक्त एक लोड करता है। मुझे कुछ एम्बेडेड अमेज़ॅन सामान ठीक से लोड करने की कोशिश कर रहा था क्योंकि एपीआई (https के माध्यम से लोड किया गया) ने http लिंक का उत्पादन किया - जिसका अर्थ है कि जब तक मैंने https लिंक टॉगल करने के लिए अनियंत्रित पैरामीटर नहीं पाया, तब तक वे ठीक से काम नहीं कर पाए। - Basic
जेसन; आपका अपडेट शायद एक नया सवाल होना चाहिए वेबमास्टर्सक्योंकि यह आपके मूल प्रश्न से असंबंधित (तकनीकी रूप से) है। लेकिन शायद यह है कि आपकी स्टाइल शीट एक असुरक्षित डोमेन से आ रही हैं। - Mark Henderson♦


जवाब:


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

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

301 आपके सभी Google-fu और कड़ी मेहनत वाले पेजरैंक रखता है बरकरार। सुनिश्चित करो mod_rewrite सक्षम किया गया है:

a2enmod rewrite

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

Http को https पर रीडायरेक्ट करना बुरा है?

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


309
2018-01-28 00:27



जानकारी के लिए धन्यवाद, मेरा मालिक मुझे बता रहा है कि वह केवल अपनी साइट के कुछ पृष्ठों पर https चलाता है, यह है कि यह हर पृष्ठ पर इसे चलाने के लिए बहुत अधिक सर्वर संसाधनों का उपयोग करता है। क्या आप इसके बारे में कुछ जानते हैं या यदि यह सच है? - JasonDavis
@jasondavis केवल तभी जब आप कुछ मिनट नहीं बिताते हैं इसे अनुकूलित करें। - Michael Hampton♦
"यह हर पृष्ठ पर इसे चलाने के लिए बहुत अधिक सर्वर संसाधनों का उपयोग करता है।" आधुनिक सीपीयू में एन्क्रिप्शन त्वरण विशेषताएं होती हैं जो एसएसएल को लगभग मुक्त बनाती हैं। ओवरहेड के बारे में चिंता मत करो। - Adam Davis
@AdamDavis क्रिप्टो एल्गोरिदम हल्का हो सकता है, लेकिन हैंडशेक ओवरहेड अभी भी मौजूद है। साथ ही, HTTPS आपकी सामग्री को कैशिंग करने से HTTP प्रॉक्सी को रोकता है। में अधिकांश मामले, एचटीटीपीएस का ओवरहेड न्यूनतम और सार्थक है, लेकिन अधिक सामान्यीकरण के बारे में सावधान रहें। - 200_success
यह साझा कैशिंग को मारता है, जो कुछ साइट के उपयोग पैटर्न के लिए उपयोगी होता है, और अक्सर छोटे की रक्षा करता है (क्या यह महत्वपूर्ण है कि लोग जान सकें कि आप साइट पर गए हैं, लेकिन आपने जो किया है उसका ब्योरा नहीं है? यही एकमात्र स्थिति है जहां एसएसएल उपयोगी है)। प्रत्येक संसाधन पर एसएसएल का मुख्य लाभ यह नहीं है कि आपको "सुरक्षित" की आवश्यकता है उदा। लोग "हमारे बारे में" देख रहे हैं, लेकिन आप पर्ची नहीं कर सकते हैं और इसे किसी ऐसे मामले में उपयोग करने में असफल हो सकते हैं जहां आपको चाहिए। - Jon Hanna


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

  1. आंतरिक लिंक के लिए पूरी साइट देखें और सुनिश्चित करें कि वे सभी HTTPS का उपयोग कर रहे हैं यदि आप लिंक में अपना डोमेन नाम निर्दिष्ट करते हैं, तो आप अपने स्वयं के रीडायरेक्ट नहीं कर रहे हैं।
  2. अपना अपडेट करें <meta property="og:url" अपने डोमेन के https संस्करण का उपयोग करने के लिए।
  3. यदि तुम प्रयोग करते हो <base href= फिर HTTPS का उपयोग करने के लिए अद्यतन करें।
  4. इंस्टॉल करें एसपीडीवाई प्रोटोकॉल अगर संभव हो तो
  5. अनुरोध की संख्या को कम करने के लिए, जहां संभव हो, सीएसएस छवि sprites का उपयोग करना सुनिश्चित करें।
  6. Https स्थिति इंगित करने के लिए अपने साइटमैप अपडेट करें, इसलिए समय के साथ मकड़ियों ने इस परिवर्तन को सीख लिया है।
  7. HTTPS को प्राथमिकता देने के लिए Google वेबमास्टर टूल्स जैसे खोज इंजन प्राथमिकताएं बदलें
  8. जहां संभव हो, एचटीटीपीएस सीडीएन सर्वर पर किसी भी स्टैक्टिक मीडिया को बंद करें।

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


49
2018-01-28 02:08



एसपीडीवाई एक अच्छा सुझाव है; यहां तक ​​कि एक मॉड्यूल भी प्रतीत होता है Apache 2.x को एसपीडीवाई समर्थन जोड़ना। - Calrion
"//Yourserver.com/some-uri" के बजाय "yourserver.com/some-uri"समस्या हल करता है (1) क्योंकि ब्राउज़र उस स्कीमा के आधार पर उचित स्कीमा (http या https) चुनता है जिसके साथ पृष्ठ लोड किया गया था। - MauganRa
@MauganRa, बेशक, यह http लेख पृष्ठ से https लॉगिन पृष्ठ पर एक लिंक है, उदाहरण के लिए। - Mołot
Google उस यूआरएल को देखता है जो किसी के माध्यम से जा रहा है Referer हैडर। उदाहरण के लिए यह साइट Google के सीडीएन से jQuery का उपयोग करती है और जब भी मैं साइट को फिर से लोड करता हूं तो मेरा ब्राउज़र Google से अनुरोध भेजता है। इस प्रकार ए Referer हेडर भी Google को भेजता है जो इस साइट के यूआरएल पर सेट है। तो Google मेरे आईपी पते में बदलाव के दौरान आने वाली साइटों को ट्रैक कर सकता है (और यदि मैं इस समय के दौरान Google सेवा का उपयोग करता हूं, तो Google इस जानकारी को मेरे Google खाते से भी जोड़ सकता है)। - Stephan Kulla
1 के लिए) मैंने अभी एक खोज किया है और मेरे MySQL डेटाबेस http में https को प्रतिस्थापित किया है ... मैं वर्डप्रेस का उपयोग कर रहा हूं इसलिए इसे सैकड़ों लिंक अपडेट करना आसान बना दिया गया - JasonDavis


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

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

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

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

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

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


38
2018-01-28 07:40



अधिक लोगों को भी इस पर ध्यान देना होगा। एक और बात यह है कि लोग मानते हैं कि वे सुरक्षित हैं क्योंकि अंतिम बिंदु एचटीटीपीएस है, इस तथ्य को अनदेखा करते हुए कि जीईटी या पीओएसटी में पृष्ठ पर भेजी गई सारी जानकारी सादा पाठ में है। - Velox
@ वेलोक्स - मुझे नहीं लगता कि "लोगों का मानना ​​है कि वे सुरक्षित हैं क्योंकि अंत बिंदु एचटीटीपीएस है, इस तथ्य को अनदेखा करते हुए कि जीईटी या पीओएसटी में पृष्ठ पर भेजी गई सारी जानकारी काफी सादा है" काफी सटीक है। हालांकि कुछ गॉथस हैं, लेकिन पूछे जाने वाले प्रश्न पैरा एचटीटीपीएस पर परिवहन के दौरान स्पष्ट रूप से यात्रा नहीं करते हैं। उदाहरण के लिए देखें: stackoverflow.com/questions/323200/... पोस्ट पेलोड भी संरक्षित हैं, जबकि लॉगिंग और रेफरर हेडर के लिए भी कमजोर नहीं है। - codingoutloud
@codingoutloud यह मेरा मुद्दा है। HTTPS से अधिक वे एन्क्रिप्ट किए गए हैं, लेकिन HTTP पृष्ठ के प्रारंभिक अनुरोध में वे नहीं थे। - Velox
@ वेलोक्स - अगर पूरी साइट HTTPS पर रीडायरेक्ट कर रही है, तो यह संभावना नहीं है कि किसी भी जीईटी पैरामीटर को एचटीटीपीएस में लात मारने से पहले भेजा जाएगा (और उस बिंदु के बाद सब कुछ HTTPS रहेगा)। अभी भी एक प्रारंभिक अनुरोध है जहां कुकीज़ भेजी जाएगी, जिसे एचएसटीएस के साथ उपचार किया जा सकता है ... और एसएसएलस्ट्रिप के लिए एक छोटी सी हमला खिड़की, जिसे संभवतः जावास्क्रिप्ट द्वारा पराजित किया जा सकता है, लेकिन यह स्वयं की एक हथियार दौड़ है। - Brilliand
@ ब्रिलियांड फेयर प्वाइंट, लेकिन सुरक्षा में एक कमजोर बिंदु पूरी चीज को कमजोर बनाता है। हमेशा विचार करने लायक है। - Velox


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

<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 स्थिति कोड एक इंगित करता है स्थायी रीडायरेक्ट, सक्षम ग्राहकों को भविष्य के कनेक्शन के लिए सुरक्षित यूआरएल का उपयोग करने का निर्देश देना (उदाहरण के लिए बुकमार्क अपडेट करें)।

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

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

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

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


22
2018-01-28 02:20



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


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

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

इसके अलावा, जिस तरह से आपने सेटअप किया है, वह HTache को रीडायरेक्ट करने के लिए अपाचे ठीक लगता है।


5
2018-01-28 00:35





Http को https पर रीडायरेक्ट करना बुरा है?

नहीं, कदापि नहीं। दरअसल, यह करना एक अच्छी बात है!

रीडायरेक्ट पर:

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

<VirtualHost *:80>
  ServerName domainname.com

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

5
2018-01-28 13:45





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

लेकिन कृपया एसएसएल सेटिंग्स की तरह एसएसएल सेटिंग्स की जांच करना याद रखें। आरसी 4 क्रिप्टो, एसएसएलवी 2 और एसएसएलवी 3 प्रोटोकॉल जैसी चीजों को अक्षम करें। साथ ही, आपको यह पता लगाना चाहिए कि क्या आपके सिस्टम की क्रिप्टो-सिस्टम लिबररी टीएलएस 1.2 का समर्थन करती है (जो वह चीज है जो आप चाहते हैं;))

एसएसएल चालू करें, यह एक अच्छी बात है।


4
2018-01-28 07:43



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


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


3
2018-01-28 10:13



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