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


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

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


49
2018-04-01 13:46


मूल


वे डर सकते हैं कि अगर कुछ भी गलत हो जाता है तो एचएसटीएस उन्हें परेशानी में डाल देगा (यानी उनका मुफ्त सीए कुछ जारी करने के कारण प्रमाण पत्र जारी करना बंद कर देता है या ब्राउज़र ट्रस्ट स्टोर से हटा दिया जाता है)। वर्तमान टीएलएस पारिस्थितिक तंत्र के साथ, आप भरोसेमंद सीए / ब्राउज़र विक्रेताओं पर निर्भरता बनाते हैं। वर्तमान में इसे टालने और इसके लायक होने के लिए मुश्किल है, लेकिन आप अभी भी इसे एक समस्या के रूप में देख सकते हैं और कुछ ऐसा होने पर अपरिवर्तित रहने के लिए एक समाधान के रूप में HTTPS को लागू नहीं कर सकते हैं। - allo
कोई भी एच 2 के लिए टीएलएस की आवश्यकता का जिक्र करना चाहता है, जो http1.1 से बहुत तेज है। आपके लिए एचटीएस करने के लिए अच्छा है, मैंने हाल ही में एचएसटी प्रीलोड सूची के लिए अपनी साइट भेजी है, उम्मीद है कि मैं सिर्फ पोर्ट 80 को एक साथ अक्षम कर सकता हूं - Jacob Evans
यह देखो: security.stackexchange.com/questions/53250/... - d33tah
@gerrit यह तर्क कम लागत वाली और मुफ्त प्रमाणपत्र प्राधिकरणों के सामने खड़ा नहीं है जैसे लेट्स एन्क्रिप्ट। - Maxthon Chan
आइए एन्क्रिप्ट प्रत्येक होस्ट के साथ काम नहीं करता है, और यह एक बेहतर होस्ट का उपयोग करने जितना आसान नहीं है। मैं ऐप इंजन का उपयोग करता हूं जो तकनीकी कारणों से समर्थित नहीं है (सीधे)। - Carl Smith


जवाब:


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

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

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

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

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

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

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

यदि आपका रखरखाव अभी भी सीधे बिना HTTP कनेक्शन की अनुमति देना चाहता है 301 Moved Permanently, कुछ वास्तव में पुराने ब्राउज़र या मोबाइल उपकरणों से पहुंच सुनिश्चित करने के लिए कहें, ब्राउजर को यह जानने का कोई तरीका नहीं है कि आपके पास HTTPS भी कॉन्फ़िगर किया गया है। इसके अलावा, आपको तैनाती नहीं करनी चाहिए HTTP सख्त परिवहन सुरक्षा (एचएसटीएस) के बिना 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").

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

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

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


8
2018-04-01 15:25



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- संगत) एचटीटीपीएस संस्करण के बारे में कभी नहीं पता होगा कि वे प्रारंभ में HTTP लोड करते हैं। - Cthulhu
अपना अंतिम पैराग्राफ पुन: गैर-HTTPS कनेक्शन के दौरान एचएसटीएस हेडर को अनदेखा किया जाता है। - Cthulhu
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 इंगित करने के लिए धन्यवाद! इससे प्रेरित, मैंने अपने जवाब में बड़े सुधार किए हैं। कृपया नई सामग्री के प्रति भी महत्वपूर्ण होने के लिए आपका स्वागत है। :) - Esa Jokinen


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

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

टीएलएस + एचएसटीएस: खोज इंजन रैंकिंग के लिए अनुकूलित करें
सादा HTTP: संगतता के लिए अनुकूलित करें

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


62
2018-04-01 13:59



हो सकता है कि यह मुझे चुनौतीपूर्ण हो, लेकिन वह पहला वाक्य एक खिंचाव लगता है: https होने वाली साइट पेशेवरता या प्रभारी लोगों की भरोसेमंदता के बारे में कुछ भी नहीं बताती है। एक साइट https हो सकती है और अभी भी उन लोगों द्वारा विकसित / प्रबंधित की जा सकती है जो इनपुट को स्वच्छ नहीं करते हैं, जिससे साइट को एसक्यूएल इंजेक्शन या एक्सएसएस के लिए कमजोर बना दिया जाता है; या यह https हो सकता है और अमान्य हो सकता है, सुलभ नहीं है, या प्रयोग योग्य नहीं है। - Alvaro Montoro
एचटीटीपीएस का उपयोग व्यावसायिकता की गारंटी नहीं है, लेकिन इसकी कमी निश्चित रूप से विपरीत बताती है। - Esa Jokinen
टीएलएस और एचएसटीएस का उपयोग सिग्नल, एक बहुत बड़ी सरणी का हिस्सा है, यह साइट पढ़ने योग्य हो सकती है। दूसरों के विपरीत, इसकी उपस्थिति के लिए परीक्षण करने के लिए यह आसानी से आसान है, यही कारण है कि Google इसे बाकी के लिए प्रॉक्सी के रूप में उपयोग कर रहा है। - sysadmin1138♦
@ ब्रायम स्टैक एक्सचेंज केवल https पर माइग्रेट कर रहा है और जल्द ही एचएसटी का उपयोग करना शुरू कर देगा। एचटीपी अभी भी संगतता के कारण उपलब्ध नहीं है, लेकिन क्योंकि वे धीमे और सावधान हैं, और यह माइग्रेट करना तकनीकी रूप से मुश्किल है। - captncraig
@esajohnson - https की कमी गैर-व्यावसायिकता प्रदर्शित नहीं करती है। यह दिखाता है कि इसके लिए कोई "ज़रूरत नहीं है"। उदाहरण के लिए, एक सेंटोस दर्पण। - warren


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

  • वेब कैश छवियों को कैश नहीं कर सकते हैं जो HTTPS पर ले जाया जाता है।
  • दुनिया के कुछ हिस्सों में बहुत कम गति वाले अंतरराष्ट्रीय कनेक्शन हैं, इसलिए कैश पर निर्भर करते हैं।
  • किसी अन्य डोमेन से होस्टिंग छवियां उन कौशलों को लेती हैं जिन्हें आप ऑपरेटरों को छोटे से उम्मीद नहीं कर सकते हैं सिफ़ पढ़िये वेबसाइटें हैं।

31
2018-04-01 23:30



यदि आप उन देशों को लक्षित करते हैं तो केवल-पढ़ने वाली सामग्री सीडीएन पर तैनात की जा सकती है। सीडीएन अपने स्वयं के साधनों का उपयोग करके स्थैतिक सामग्री को प्रतिबिंबित करता है और अभी भी उन्हें HTTPS के माध्यम से कार्य करता है। सीडीएन ढूंढना काफी आसान हो सकता है और छोटी वेबसाइटों के लिए उपयोग करने के लिए महंगा नहीं है। - Maxthon Chan
@ मैक्सथॉन खान, मेरी मां को समझाओ कि सीडीएन क्या है ..... फिर भी वह स्थानीय चर्च सेवाओं के समय के साथ एक वेबसाइट स्थापित कर सकती है। - Ian Ringrose
@MichaelHampton विवरण कैश के बिना एक कैश एक HTTPS स्ट्रीम से छवि को कैसे पढ़ सकता है? और क्या आप अपनी चाबियों के साथ एक आईएसपी पर भरोसा करेंगे? - Ian Ringrose
आपको यह और स्पष्ट करना चाहिए कि आप किस कैश के बारे में बात कर रहे हैं। - Michael Hampton♦
@IanRingrose यदि आपकी मां स्थानीय चर्च सेवा की जानकारी के साथ एक वेबसाइट स्थापित कर रही है, तो यह संभावना नहीं है कि अंतर्राष्ट्रीय कनेक्शन पर कैशिंग व्यवहार खेल में आएगा, जब तक कि यह एक बहुत लोकप्रिय चर्च नहीं है। - Jason C


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

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

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

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

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

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


14
2018-04-01 18:16



फ्रंटेंड सर्वर / लोड बैलेंसर / समान पर एसएसएल को समाप्त करने और इसके बाद यातायात को लॉगिंग करने के बारे में कैसे? - eis
@eis यह मानता है कि कंपनी हर वेबसाइट पर नियंत्रण रखती है जो कर्मचारी जा सकते हैं, जो असंभव है। पोस्ट इंट्रानेट वेबसाइट पर टीएलएस के बारे में प्रतीत नहीं होता है। - Xiong Chiamiov


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

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

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

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

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

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

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


5
2018-04-02 18:12



"पर्याप्त पुराने टीएलएस / एसएसएल कार्यान्वयन के साथ एचटीटीपीएस पर अपस्ट्रीम ओपनबीएसडी साइट से लिबरएसएसएल के हाल के संस्करण को डाउनलोड करने का प्रयास करें" निश्चित रूप से फ्लिप पक्ष यह है: एक पुराने ब्राउज़र के साथ हालिया ब्राउज़र को डाउनलोड करने का प्रयास करें, उदाहरण के लिए एक जो केवल HTTP / 1.0 को समर्थन के बिना लागू करता है Host: हैडर। या एक वेब ब्राउजर के साथ आधुनिक साइटों को सर्फ करने का प्रयास करें जो केवल 2001 की जावास्क्रिप्ट का समर्थन करता है। किसी बिंदु पर हम एक समुदाय के रूप में आगे बढ़ने की जरूरत है, जो दुर्भाग्य से कुछ के लिए चीज़ों को तोड़ देता है। प्रश्न तब बन जाता है: टूटने के लायक मूल्य क्या है? - α CVn
@ माइकल Kjörling वे अलग गंभीरता की समस्या भी हैं। मैं उस सूची में हाल ही में कंपाइलर संस्करणों को जोड़ दूंगा। कुछ दूसरों की तुलना में अधिक रक्षात्मक हैं। मुझे यकीन नहीं है कि आप असहमति का दावा कर रहे हैं या क्यों आप हैं: मेरी पोस्ट की दूसरी वाक्य में, मैं सहमत हूं कि यह है एचटीटीपीएस कनेक्शन पर पुराने सिफर को रोकने के लिए उचित, क्योंकि यह ज्यादातर उपयोगकर्ताओं को डाउनग्रेड हमलों से बचाने में मदद करता है, अन्यथा उनके पास कोई सार्थक दृश्यता या रक्षा नहीं होती है। (मुझे नहीं लगता कि अधिकतर आधुनिक वेबसाइटें गहराई से अपनाने में नाकाम रही हैं, यह दूरस्थ रूप से उचित है, लेकिन यह बिंदु के बगल में है।) - mtraceur
@ माइकल Kjörling स्पष्ट करने के लिए, इसे लाने का मुद्दा था क्योंकि यह कहां का एक उदाहरण है सादा HTTP प्रदान करना उपयोगकर्ता को स्पष्ट लाभ था, जो कि उत्तर देने का मुख्य बिंदु था। यह OpenBSD / LibreSSL परियोजनाओं पर नकारात्मक प्रकाश डालने के किसी भी तरीके से नहीं था, जिसके लिए मेरे पास काफी महत्वपूर्ण सम्मान है। मैंने सोचा कि पहले अनुच्छेद की दूसरी वाक्य इस तरह की नकारात्मक व्याख्या से इंकार कर देगी। अगर आपको लगता है कि अस्पष्ट था या बेहतर कहा जा सकता है, तो कृपया मेरा जवाब संपादित करने या सुधार का सुझाव देने में संकोच न करें। - mtraceur


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

मैक्सथन ने 2 प्रश्न पूछे:

1) एक यादृच्छिक, गैर-नामित साइट ने http और https दोनों प्रस्तुतियों को बनाए रखने का निर्णय लिया है

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

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

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

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


3
2018-04-03 22:52





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


1
2018-04-04 11:52



आप अपने सर्वर का उपयोग प्रॉक्सी को एक SSL'd संस्करण को रिवर्स करने के लिए कर सकते हैं। - Maxthon Chan