क्या वेबसाइट पर HTTPS लागू नहीं करने का कोई कारण है?

49

एक वेबसाइट जो मैंने अक्सर टीएलएस को अपने सर्वरों में सक्षम करने का निर्णय लिया है, न केवल इसे करने के लिए इसे करने के लिए बहुत सारी वेबसाइटें हैं। अनुरक्षक का दावा है कि टीएलएस वैकल्पिक होना चाहिए। क्यों?

अपनी खुद की वेबसाइट पर मैंने लंबे समय तक अनिवार्य रूप से टीएलएस और एचएसटीएस की स्थापना की है, और कमजोर सिफर स्वीट्स अक्षम हैं। प्लेनटेक्स्ट एक्सेस की गारंटी दी जाती है कि वह HTTP 301 के साथ TLS- प्रोटेक्टेड वर्जन के साथ दी गई है। क्या यह मेरी वेबसाइट को नकारात्मक रूप से प्रभावित करता है?

ssl  hsts 
— मैक्सथन चान
स्रोत
12
उन्हें डर हो सकता है, कि अगर कुछ भी गलत हो जाता है, तो एचएसटीएस उन्हें परेशानी में डाल देगा (यानी उनका मुफ्त सीए प्रमाण पत्र जारी करना बंद कर देता है या किसी मुद्दे के कारण ब्राउज़र ट्रस्ट स्टोर से हटा दिया जाता है)। वर्तमान टीएलएस पारिस्थितिकी तंत्र के साथ, आप भरोसेमंद सीए / ब्राउज़र विक्रेताओं के लिए निर्भरता बनाते हैं। वर्तमान में इसे टालना और इसके लायक होना कठिन है, लेकिन आप अभी भी इसे एक समस्या के रूप में देख सकते हैं और कुछ होने की स्थिति में एचटीटीपीएस को लागू करने के समाधान के रूप में लागू नहीं कर सकते।
— allo
कोई भी h2 के लिए tls की आवश्यकता का उल्लेख करना चाहता है, जो http1.1 की तुलना में बहुत तेज है। आपके लिए hsts करने के लिए अच्छा है, मैंने हाल ही में hsts प्रीलोड सूची के लिए अपनी साइट भेजी है, उम्मीद है कि मैं सिर्फ एक साथ पोर्ट 80 को निष्क्रिय कर सकता हूं
— याकूब इवान्स
— d33tah
4
@gerrit यह तर्क कम लागत और फ्री सर्टिफिकेट अथॉरिटी जैसे लेट्स एनक्रिप्ट के सामने नहीं टिकता है।
— मैक्सथन चान
1
आइए Encrypt हर होस्ट के साथ काम नहीं करता है, और बेहतर होस्ट का उपयोग करना उतना आसान नहीं है। मैं ऐप इंजन का उपयोग करता हूं जो तकनीकी कारणों से समर्थित (सीधे) नहीं है।
— कार्ल स्मिथ

जवाबों:

8

टीएलएस का उपयोग करने के कई अच्छे कारण हैं

(और ऐसा नहीं करने के लिए केवल कुछ सीमांत कारण)।

  • यदि साइट का कोई प्रमाणीकरण है, तो HTTP का उपयोग सत्र और पासवर्ड चोरी करने के लिए बेनकाब करता है।

  • यहां तक ​​कि स्थिर, केवल सूचनात्मक साइटों पर, टीएलएस का उपयोग करने से यह सुनिश्चित होता है कि किसी ने डेटा के साथ छेड़छाड़ नहीं की है।

  • Google I / O 2014 के बाद से , Google ने सभी साइटों को HTTPS का उपयोग करने के लिए प्रोत्साहित करने के लिए कई कदम उठाए हैं:

  • मोज़िला सिक्योरिटी ब्लॉग ने गैर-सुरक्षित HTTP को केवल सुरक्षित वेबसाइटों के लिए सभी नई सुविधाओं को उपलब्ध कराने और गैर-सुरक्षित वेबसाइटों के लिए ब्राउज़र सुविधाओं तक धीरे-धीरे पहुंच बनाने की घोषणा की है , विशेष रूप से ऐसी सुविधाएँ जो उपयोगकर्ताओं की सुरक्षा और गोपनीयता के लिए जोखिम पैदा करती हैं ।

टीएलएस लागू करने के कई अच्छे कारण भी हैं

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

यदि आपका अनुचर अभी भी HTTP कनेक्शन को बिना प्रत्यक्ष अनुमति देना चाहता है, तो 301 Moved Permanentlyकुछ पुराने ब्राउज़रों या मोबाइल उपकरणों से पहुंच सुनिश्चित करने के लिए कहें, ब्राउज़र के लिए यह जानने का कोई तरीका नहीं है कि आपके पास HTTPS भी कॉन्फ़िगर है । इसके अलावा, आपको HTTP सख्त परिवहन सुरक्षा (HSTS) को बिना तैनात नहीं करना चाहिए 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

दोनों प्रोटोकॉल के लिए कॉन्फ़िगर की गई विभिन्न साइटों की समस्या को टो प्रोजेक्ट और इलेक्ट्रॉनिक फ्रंटियर फाउंडेशन द्वारा मान्यता प्राप्त है और एक मल्टीब्रोसर HTTPS एवरीवेयर एक्सटेंशन द्वारा संबोधित किया गया है :

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

गैर-सुरक्षित HTTP कनेक्शन के माध्यम से लोड किए गए जावास्क्रिप्ट या सीएसएस को संशोधित करके HTTPS साइटों पर संभावित XSS हमलों के कारण मिश्रित सामग्री भी एक बड़ी समस्या थी। इसलिए आजकल सभी मुख्यधारा के ब्राउज़र उपयोगकर्ताओं को मिश्रित सामग्री वाले पृष्ठों के बारे में चेतावनी देते हैं और इसे स्वचालित रूप से लोड करने से मना करते हैं। यह HTTP पर रीडायरेक्ट के बिना साइट को बनाए रखना कठिन बनाता है301 : आपको यह सुनिश्चित करना होगा कि हर HTTP पृष्ठ केवल HTTP contect (CSS, JS, images etc.) को लोड करता है और हर HTTPS पेज केवल HTTPS सामग्री को लोड करता है। दोनों पर समान सामग्री के साथ हासिल करना बेहद कठिन है।

— एसा जोकिनेन
स्रोत
If your maintainer still would like to allow HTTP connections without direct 301 Moved Permanently, say for ensuring access from some really old browsers or mobile devices, HSTS is the correct choise as it only enforces HTTPS when it is clear that the browser supports itलेकिन इस मामले में क्लाइंट (यहां तक ​​कि HTTPS- संगत) को HTTPS संस्करण के बारे में कभी नहीं पता होगा कि वे शुरू में HTTP लोड कर रहे हैं।
— Cthulhu
अपने अंतिम पैराग्राफ को फिर से लिखें: गैर- HTTPS कनेक्शन के दौरान HSTS हेडर को अनदेखा किया जाता है।
— Cthulhu
1
HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport. If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s). tools.ietf.org/id/draft-ietf-websec-strict-transport-sec-14.txt
— Cthulhu
मेरे झूठे संकेत को इंगित करने के लिए धन्यवाद, Cthulhu! उससे प्रेरित होकर, मैंने अपने उत्तर में बड़े सुधार किए हैं। नई सामग्री के प्रति भी आपका स्वागत है। :)
— एसा जोकिनेन
62

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

दूसरे छोर पर अधिकतम संगतता है। वहाँ अभी भी पुराने ग्राहक हैं, विशेष रूप से दुनिया के कुछ हिस्सों में जो संयुक्त राज्य अमेरिका, यूरोप या चीन नहीं हैं। सादा HTTP हमेशा काम करेंगे (हालांकि, हमेशा काम नहीं अच्छी तरह से , कि एक और कहानी है)।

TLS + HSTS: सर्च-इंजन रैंकिंग के लिए ऑप्टिमाइज़ करें
HTTP: अनुकूलता के लिए ऑप्टिमाइज़ करें

इस बात पर निर्भर करता है कि आपके लिए क्या मायने रखता है।

— sysadmin1138
स्रोत
16
हो सकता है कि यह मुझे चुगली कर रहा हो, लेकिन यह पहला वाक्य थोड़ा खिंचा हुआ लगता है: https होने वाली साइट व्यावसायिकता या लोगों के भरोसे के बारे में कुछ नहीं बताती है। एक साइट https हो सकती है और अभी भी उन लोगों द्वारा विकसित / प्रबंधित की जा सकती है जो इनपुट को साफ नहीं करते हैं, जिससे साइट SQL इंजेक्शन या XSS के लिए असुरक्षित हो जाती है; या यह https हो सकता है और अमान्य हो सकता है, सुलभ नहीं है, या उपयोग करने योग्य नहीं है।
— अल्वारो मोंटोरो
34
HTTPS का उपयोग करना व्यावसायिकता की गारंटी नहीं है, लेकिन इसका अभाव निश्चित रूप से इसके विपरीत बताता है।
— एसा जोकिनेन
8
टीएलएस और एचएसटीएस का उपयोग सिग्नल, एक बहुत बड़े सरणी का हिस्सा है, जो कि साइट पढ़ने लायक हो सकती है। दूसरों के विपरीत, इसकी तुच्छ उपस्थिति के लिए परीक्षण करना आसान है , यही कारण है कि Google इसे बाकी के लिए एक प्रॉक्सी के रूप में उपयोग कर रहा है।
— sysadmin1138
3
@Braiam Stack Exchange केवल https पर माइग्रेट कर रही है और जल्द ही hsts का उपयोग शुरू कर देगी। Http अभी भी उपलब्ध है, संगतता के कारण नहीं, बल्कि इसलिए कि वे धीमे और सावधान हो रहे हैं, और यह तकनीकी रूप से स्थानांतरित करना मुश्किल है।
— captncraig
4
@esajohnson - https का अभाव अव्यवसायिकता को प्रदर्शित नहीं करता है। यह दर्शाता है कि इसके लिए कोई "आवश्यकता" नहीं है। उदाहरण के लिए, एक CentOS दर्पण।
— वॉरेन
30

केवल पढ़ने के लिए वेबसाइटों के HTTPS का उपयोग न करने का एक अच्छा कारण है ।

  • वेब कैश HTTPS पर ले जाने वाली छवियों को कैश नहीं कर सकता है।
  • दुनिया के कुछ हिस्सों में बहुत कम गति वाले अंतरराष्ट्रीय कनेक्शन हैं, इसलिए कैश पर निर्भर हैं।
  • किसी अन्य डोमेन से छवियों की मेजबानी करने से ऐसे कौशल मिलते हैं जिनकी आप उम्मीद नहीं कर सकते हैं कि केवल छोटी वेबसाइटों के लिए ऑपरेटर ही पढ़ें ।
— इयान रिंगरोज
स्रोत
1
यदि आप उन देशों को लक्षित करते हैं तो केवल-सामग्री को ही CDN पर तैनात किया जा सकता है। सीडीएन अपने स्वयं के साधनों का उपयोग करके स्थिर सामग्री को दिखाता है और फिर भी HTTPS के माध्यम से उनकी सेवा करता है। सीडीएन खोजने के लिए काफी आसान हो सकता है और छोटी वेबसाइटों के लिए उपयोग करने के लिए महंगा नहीं है।
— मैक्सथन चान
8
@MaxthonChan, मेरी मां को समझाने की कोशिश करें कि CDN क्या है ..... फिर भी वह स्थानीय चर्च सेवाओं के समय के साथ एक वेबसाइट सेटअप कर सकती है।
— इयान रिंगरोस
6
@Michael Hampton विवरण कुंजी के बिना एक कैश HTTPS स्ट्रीम से छवि कैसे पढ़ सकता है? और क्या आप अपनी चाबियों के साथ एक आईएसपी पर भरोसा करेंगे?
— इयान रिंगरोज 21
8
आपको इसे और अधिक स्पष्ट करना चाहिए कि आप किस कैश के बारे में बात कर रहे हैं।
— माइकल हैम्पटन
2
@IanRingrose यदि आपकी मां स्थानीय चर्च सेवा की जानकारी के साथ एक वेबसाइट स्थापित कर रही है, तो यह संभावना नहीं है कि अंतरराष्ट्रीय कनेक्शन पर कैशिंग व्यवहार खेलने में आ जाएगा, जब तक कि यह एक बहुत लोकप्रिय चर्च न हो।
— जेसन सी
14

अनुरक्षक का दावा है कि टीएलएस वैकल्पिक होना चाहिए। क्यों?

वास्तव में इस प्रश्न का उत्तर जानने के लिए, आपको उनसे पूछना चाहिए। हालाँकि, हम कुछ अनुमान लगा सकते हैं।

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

  1. इस यातायात की निगरानी करना छोड़ दें।
  2. उपयोगकर्ताओं की मशीनों पर एक रूट सीए स्थापित करें ताकि आप मिट डिक्रिप्शन और निरीक्षण कर सकें।
  3. थोक ब्लॉक एन्क्रिप्टेड ट्रैफ़िक।

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

प्रौद्योगिकी के पहिये आगे मंथन करते रहते हैं, और आपको कई ऐसे लोग मिल जाएंगे जो तर्क देते हैं कि इस प्रकार का संरक्षण पुराने जमाने का है और इसे चरणबद्ध किया जाना चाहिए। लेकिन अभी भी कई ऐसे हैं जो इसका अभ्यास करते हैं, और शायद यह वह है जिनके साथ आपका रहस्यमय अनुचर चिंतित है।

— जिओनग चियासियोव
स्रोत
कैसे के बारे में दृश्यपटल सर्वर / लोड बैलेंसर / पर ssl को समाप्त करने और उसके बाद यातायात लॉगिंग के बारे में?
— ईईस
1
@eis यह मानता है कि कंपनी हर उस वेबसाइट को नियंत्रित करती है जिसे कर्मचारी देख सकते हैं, जिसकी संभावना नहीं है। इंट्रानेट वेबसाइट पर टीएलएस के बारे में पोस्ट दिखाई नहीं देती है।
— Xiong Chiamiov
5

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

स्पष्ट रूप से HTTP को असुरक्षित करने के लिए मुझे अनुमति नहीं दे रहा है जब मैंने समझा है कि आपका ब्लॉग पोस्ट आपको रूबी से अधिक क्यों पसंद है (आप ऐसा नहीं कर रहे हैं, बस एक सामान्य उदाहरण है) कुछ ऐसा नहीं है जो मुझे समझ में आता है या जनता को पता है मैंने एक्सेस किया है, बिना किसी अच्छे कारण के मेरे रास्ते में बस हो रही है, इस धारणा पर कि HTTPS मेरे लिए तुच्छ होगा।

आज, एम्बेडेड सिस्टम हैं, जो टीएलएस को बॉक्स से बाहर निकालने की क्षमता नहीं रखते हैं, या जो पुराने कार्यान्वयन पर अटके हुए हैं (मुझे लगता है कि यह बहुत बुरा है कि यह ऐसा है, लेकिन एम्बेडेड सम्मिलित करने की शक्ति उपयोगकर्ता के रूप में है यहाँ उपकरण], मैं कभी-कभी इसे बदल नहीं सकता)।

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

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

हममें से अधिकांश एपीटी (एडवांस्ड परसेंट थ्रेड: राष्ट्रीय खुफिया एजेंसियों के लिए सुरक्षा शब्दजाल और अन्य अत्यंत अच्छी तरह से पुनर्विचारित साइबर खतरों) के स्वामित्व से एक असुरक्षित डाउनलोड नहीं हैं। कभी-कभी मैं बस wgetकुछ सादे पाठ प्रलेखन या एक छोटा कार्यक्रम चाहता हूं, जिसका स्रोत मैं जल्दी से अपने स्वयं के छोटे उपयोगिताओं / स्क्रिप्ट्स (GitHub पर स्क्रिप्ट, उदाहरण के लिए) एक बॉक्स पर ऑडिट कर सकता हूं जो सबसे हाल ही में सिफर सुइट्स का समर्थन नहीं करता है।

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

— mtraceur
स्रोत
1
"पर्याप्त पुराने टीएलएस / एसएसएल कार्यान्वयन के साथ एचटीटीपीएस पर अपस्ट्रीम ओपनबीएसडी साइट से लिबरएसएसएल के हाल के संस्करण को डाउनलोड करने का प्रयास करें" इस पाठ्यक्रम का फ्लिप पक्ष है: पर्याप्त पुराने ब्राउज़र के साथ हाल के ब्राउज़र को डाउनलोड करने का प्रयास करें, उदाहरण के लिए एक कि केवल लागू करता है HTTP / 1.0 Host:हेडर के लिए समर्थन के बिना । या एक वेब ब्राउज़र के साथ आधुनिक साइटों को सर्फ करने की कोशिश करें जो केवल 2001 के जावास्क्रिप्ट का समर्थन करता है। कुछ बिंदु पर हमें एक समुदाय के रूप में आगे बढ़ना होगा, जो दुर्भाग्य से कुछ के लिए चीजों को तोड़ देता है। सवाल तो यह हो जाता है: जोड़ा मूल्य टूटने के लायक है?
— एक सीवीएन
@ माइकलकॉर्जलिंग वे समस्याएं भी हैं, जो बदलती गंभीरता की हैं। मैं उस सूची में हाल के संकलक संस्करणों का निर्माण करूँगा। कुछ दूसरों की तुलना में अधिक रक्षात्मक हैं। मुझे यकीन है कि आप असहमति जताने या क्यों कर रहे हैं, तो आप कर रहे हैं नहीं कर रहा हूँ: मेरी पोस्ट के दूसरे वाक्य में, मैं मानता हूँ कि यह है , एक HTTPS कनेक्शन पर पुराने सिफर को रोकने के लिए के बाद से यह ढाल हमलों वे 'से अधिकांश उपयोगकर्ताओं की सुरक्षा करता है उचित डी अन्यथा के खिलाफ या रक्षा में कोई सार्थक दृश्यता नहीं है। (मुझे नहीं लगता कि ज्यादातर आधुनिक वेबसाइट्स इनायत से नीचा दिखाने में असफल होती हैं, लेकिन यह बहुत ही उचित है, लेकिन बिंदु के बगल में
— थोथा
@ माइकलकॉर्जिंग स्पष्ट करने के लिए, इसे लाने की बात इसलिए थी क्योंकि यह एक उदाहरण है जहां उपयोगकर्ता को सादे HTTP प्रदान करने का स्पष्ट लाभ था, जो कि प्रश्न का मूल बिंदु था जिसका उत्तर दिया जा रहा था। यह ओपनबीएसडी / लिब्रेएसएसएल परियोजनाओं पर नकारात्मक प्रकाश डालने के लिए किसी भी तरह से नहीं था, जिसके लिए मेरे पास बहुत सम्मान है। मुझे लगा कि पहले पैराग्राफ का दूसरा वाक्य इस तरह की नकारात्मक व्याख्या को खारिज कर देगा। अगर आपको लगता है कि यह अस्पष्ट था या बेहतर शब्दों में लिखा जा सकता है, तो कृपया मेरे उत्तर को संपादित करने या सुधार का सुझाव देने के लिए स्वतंत्र महसूस करें।
— mtraceur
3

यहाँ इस बात की बहुत चर्चा है कि क्यों टील्स अच्छा है - लेकिन मूल पोस्ट में ऐसा कभी नहीं पूछा गया।

मैक्सथन ने 2 सवाल पूछे:

1) क्यों एक यादृच्छिक, बिना नाम वाली साइट ने http और https दोनों स्थितियों को बनाए रखने का फैसला किया है

2) क्या http अनुरोधों के लिए केवल 301 प्रतिक्रियाओं की सेवा करने वाले मैक्सथन पर नकारात्मक प्रभाव पड़ता है

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

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

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

— symcbean
स्रोत
1

अतीत में, मुझे एचटीटीपीएस के बजाय एचटीटीपी का उपयोग करना पड़ा है, क्योंकि मैं <embed>कहीं और से उन पृष्ठों पर जाना चाहता हूं जो स्वयं एचटीटीपी पर सेवा कर चुके हैं, और वे अन्यथा काम नहीं करेंगे।

— Algy टेलर
स्रोत
आप SSL'd वर्जन को रिवर्स करने के लिए अपने सर्वर का उपयोग कर सकते हैं।
— मैक्सथन चान
1

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

मुझे अज्ञात (या ज्ञात-विरासत) को हटाने के लिए पुनर्निर्देशित नियम को लिखकर इस संभावना से निपटने के लिए लुभाया जाएगा - उपयोगकर्ता-एजेंट तार को पुनर्निर्देशित किया जा रहा है और यदि वे चाहते हैं तो http के माध्यम से सामग्री का उपयोग करने दें, ताकि वास्तविक ब्राउज़र से सभी को लाभ हो सके मजबूर https / hsts।

— आर ..
स्रोत
1
मुझे याद दिलाएं कि कितने दशकों पहले किसी भी बनाए हुए टूल (जैसे wget) ने HTTPS का समर्थन नहीं किया था?
— ओलेग वी। वोल्कोव
@ ओलेगवी.वोलकोव: मुझे लगता है कि आपने मेरे जवाब में व्यस्त शब्द को याद किया।
— R ..
इसकी जाँच की - ठीक है, अब मैं देख रहा हूँ। मैं वास्तव में क्यों नहीं मिलता है तो बस लानत बात नहीं बना सकते हैं और फिर पैकेज का निर्माण नहीं करते हैं, लेकिन जो भी हो। यह सोचकर कि मैंने कुछ और मामलों को भी याद किया है जब लोगों को छीनने या पुराने उपकरणों को प्रतिबंधित कर दिया गया था और सादे HTTP पर रखना अच्छा होगा। क्या आप कृपया कैप्स ठीक कर सकते हैं ताकि मैं संपादित करने के बाद भी वोट वापस कर सकूं?
— ओलेग वी। वोल्कोव
1

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

— केन
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.