क्या क्रोम में टेक्स्ट इनपुट चेतावनियों से बचने के लिए वेबसाइट को सुरक्षित करने के लिए HTTPS के अलावा अन्य विकल्प हैं?


16

एक सप्ताह पहले Google ने मुझे HTTPS पर जाने के लिए एक ईमेल भेजा था। अगर मैं HTTP को HTTPS में ट्रांसफर नहीं करूंगा तो यह मेरे सभी साइट विज़िटर को असुरक्षित कनेक्शन दिखाएगा, जो मेरी साइट में टेक्स्ट इनपुट करने की कोशिश करेंगे।

SSL का उपयोग किए बिना, क्या मेरे कनेक्शन को सुरक्षित बनाने का कोई अन्य तरीका है? जैसा कि यह वेब URL में SSL का उपयोग करने के लिए महंगी प्रक्रिया से संबंधित है, मैं इसके बजाय किसी अन्य विकल्प की तलाश कर रहा हूं।


27
क्या आपने letencrypt.org पर ध्यान दिया है ? यह मुक्त HTTPS प्रमाणपत्र जारी करता है। यह खरोंच से सेट करने के लिए थोड़ा दर्द है, लेकिन कई होस्टिंग कंपनियों ने इसे आपके लिए लागू किया है।
स्टीफन Ostermiller

6
आप क्लाउडफ़ेयर का भी उपयोग कर सकते हैं जो आपको मुफ्त में एसएसएल प्रमाणपत्र देगा।
Ave

2
सवाल "HTTPS का उपयोग कैसे करें" नहीं है, लेकिन इससे अधिक व्यापक: यदि http://ठीक नहीं है, तो इसके अलावा और क्या है https://? वहाँ एक है abc://, lgbtqiapk+://या dps://?
कोनरक

4
"महंगा प्रक्रिया"? एनक्रिप्ट फ्री है। इसके अलावा: doesmysiteneedhttps.com
एंड्रिया

जवाबों:


41

क्या मेरे कनेक्शन को सुरक्षित बनाने का कोई अन्य तरीका है?

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

आखिरकार, हम सभी HTTP पृष्ठों को गैर-सुरक्षित के रूप में लेबल करने की योजना बनाते हैं, और HTTP सुरक्षा संकेतक को लाल त्रिकोण में बदलते हैं जो हम टूटे हुए HTPPS के लिए उपयोग करते हैं।

अपनी साइट पर एक एसएसएल प्रमाणपत्र स्थापित करना (या एसएलएल को संभालने के लिए क्लाउडफ्लेयर जैसे फ्रंट-एंड प्रॉक्सी का उपयोग करना) आपकी साइट पर यातायात को एन्क्रिप्ट करने का एकमात्र तरीका है।

हालाँकि, यह जरूरी नहीं कि इन दिनों "महंगी प्रक्रिया" हो। Cloudflare में एक "free" विकल्प है और Let’s Encrypt एक मुफ़्त प्रमाणपत्र प्राधिकरण है जो कई होस्ट डिफ़ॉल्ट रूप से समर्थन करता है।


3
"यह सामान्य रूप से केवल तभी होगा जब आप उपयोगकर्ताओं को लॉगिन (उपयोगकर्ता नाम / पासवर्ड सबमिट करने) या एक अनएन्क्रिप्टेड कनेक्शन पर व्यक्तिगत जानकारी सबमिट करने की अनुमति दे रहे हों। सामान्य रूप से" पाठ "जरूरी नहीं होगा।" यह जल्द ही सच नहीं होगा; Chrome किसी भी पाठ प्रविष्टि क्षेत्र के लिए चेतावनी दिखाएगा। यह संभावित संवेदनशील जानकारी और खोजों जैसे सौम्य सामान के बीच का अंतर नहीं बता सकता है, आखिरकार, इसलिए निर्णय सब कुछ पर चेतावनी देने के लिए किया गया था।
मुजेर

2
@Muzer यह भी आम तौर पर डिसाइडेबल नहीं है अगर पाठ इनपुट है संवेदनशील - अगर मैं अपने घर का पता टाइप करें, या मेरे शर्मनाक चिकित्सा समस्या के लिए एक खोज करते हैं, उन एक छिपकर बातें सुनेवाला बहुत दिलचस्प हो सकता है।
अप्सिलर्स

6
आखिरकार, Chrome यह चेतावनी सभी HTTP साइटों के लिए दिखाएगा , इसलिए HTTPS का कोई दीर्घकालिक विकल्प नहीं है।
केविन

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

4
@IllusiveBrian हालांकि यह सवाल वास्तव में "HTTPS के फ़ायदों" के बारे में नहीं है (मौजूदा सवाल हैं जो पहले से ही इसे कवर करते हैं), यह सवाल Google / Chrome में ब्राउज़र सुरक्षा "चेतावनी" से बचने की कोशिश करने के बारे में है। लेकिन HTTPS जरूरी "पहचान साबित नहीं करता है" - ऐसा करने के लिए आपको OV या EV सर्टिफिकेट के लिए ज्यादा पैसे देने होंगे। इस प्रश्न के संदर्भ में यह सभी एन्क्रिप्शन के बारे में है।
DocRoot

4

मैं अनुशंसा नहीं करता, लेकिन मूल इनपुट पाठ फ़ील्ड का उपयोग न करके आप इस संदेश को बायपास कर सकते हैं। आप नियमित रूप divसे onkeypressईवेंट का उपयोग करके अपने स्वयं के इनपुट फ़ील्ड बना सकते हैं । या आप एक divतत्व बना सकते हैं जिसमें contenteditableविशेषता सेट है true

इस तरह, उपयोगकर्ता inputटैग तत्वों का उपयोग किए बिना, आपकी साइट पर जानकारी इनपुट करने में सक्षम होंगे ।


41
यह वास्तव में बुरा विचार है। यह सुरक्षा समस्या को हल नहीं करता है जिसे Google आपको हल करने के लिए प्रोत्साहित कर रहा है, और उन उपयोगकर्ताओं के लिए समस्याएँ पैदा करने की संभावना है जो आपकी साइट का थोड़ा अलग तरीके से उपयोग कर रहे हैं कि आपने इसे कैसे परीक्षण किया है (उदाहरण के लिए एक अलग ब्राउज़र, एक फ़ोन) एक स्क्रीन रीडर आदि)। यह भी पासवर्ड प्रबंधकों को तोड़ने की संभावना होगी।
Thelem

इस दृष्टिकोण के साथ फॉर्म को पोस्ट करना समस्याग्रस्त होगा।
the_lotus

3
आपको फ़ार्म पोस्ट करने की आवश्यकता नहीं है। आप XMLlHTTPRequestसूचना भेजने के लिए (उर्फ AJAX) का उपयोग कर सकते हैं
अमिनाड ग्लिकसेटिन

18
मैं आपको "कभी नहीं ऐसा करने" के लिए "अनुशंसा नहीं" से जवाब बदल दूंगा। आप इतने सारे मानकों को दरकिनार कर रहे हैं, ऐसा करने से आप एक वेब एप्लिकेशन भी नहीं बना सकते हैं।
कैमिन

2
क्या मुझे इस चीज़ को कम करने के लिए वास्तव में 125 बिंदुओं की आवश्यकता है? oO
एंड्रिया लेज़ारोत्तो 16

4

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

वैकल्पिक रूप से आप क्लाउडफ़ेयर जैसी सेवा का उपयोग कर सकते हैं - उनकी मुफ्त योजना मुफ्त https प्रदान करती है।

अंत में, कुछ होस्ट ड्रीमहोस्ट सहित, अब मुफ्त https सेर प्रदान करते हैं । इसलिए जांचें कि क्या आपका वर्तमान होस्ट विकल्प के रूप में इसे प्रदान करता है।

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


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

1
@closetnoc GoDaddy कई तरीकों से चीर-फाड़ है। हम (वेबदेव कंपनी) प्रति वर्ष € 7 के लिए हमारे अनाज खरीदते थे, जो सस्ती थी, लेकिन सौ साइटों के लिए नहीं। अब, हम लेट्स एनक्रिप्ट का उपयोग कर रहे हैं और उन्हें मुफ्त में प्राप्त कर रहे हैं, इसलिए हमने उन सभी पर एसएसएल लगाया है। हमारे ग्राहकों को यह पसंद है और हम HTTP / 2 का उपयोग करके आनंद लेते हैं। नवीनीकरण की कोई समस्या नहीं थी। अनाज 90 दिनों तक रहता है और हम 60 दिनों के बाद रोजाना नवीनीकरण करने की कोशिश करते हैं। ओवरलैप में बहुत कुछ गलत हो जाता है (जो ऐसा नहीं है)। यदि आप झंझट नहीं चाहते हैं तो Cloudflare का उपयोग करें।
मार्टिज़न हेमेल्स

1
@closetnoc ssl एन्क्रिप्शन की तुलना में अधिक है, यह अखंडता, सुरक्षा और गोपनीयता भी सुनिश्चित करता है, इसलिए पृष्ठ पर सामान (जैसे कि आपका नियोक्ता, एक जीवित राज्य) नहीं देखा जा सकता है या एक मित्मीर द्वारा परिवर्तित (जैसे इंजेक्शन वाले)। इसके अलावा, यह मित्र को आपके मित्र के प्रमाणीकरण डेटा (जो संभवतः साइट पर अवांछित सामग्री अपलोड करने के लिए उपयोग किया जा सकता है) को सूँघने से रोकता है। इसके अलावा, एक मार्टिज़न ने कहा, GoDaddy एक विशाल लहर है, और कुल मिलाकर प्रतिकूल है। मैं आपके मित्र को Google डोमेन, नेमस्पेस और गंदी (मैं किसी से संबद्ध नहीं हूं) देखने की सलाह दूंगा।
Ave

1
@MartijnHeemels मैं मानता हूं कि GoDaddy ओवरराइड है। ज़्यादा समय! ऐसा लगता है कि लेट्स एनक्रिप्ट सबसे अधिक साइटों के लिए जाने का तरीका है जो आमतौर पर सामग्री में सौम्य हैं। मैं कुछ साइटों के लिए पूरी तरह से vetted certs के लिए जा रहा देख सकते हैं। क्या आप विश्वास करेंगे कि मैं एक प्रमाणित प्राधिकारी हुआ करता था? मुझे लगता है कि मैं पसंद करता हूं जब एक साल सीरेट्स थे। मुझे कम समय अवधि पर भरोसा नहीं है। लेकिन इन दिनों क्या विकल्प हैं? चीयर्स !!
क्लोजेटनॉक

1
@closetnoc लगभग $ $ $ $ के लिए 1-वर्ष की वैधता के साथ अच्छी तरह से पहचाने गए सीए से भुगतान किए गए एसएसएल सीट्स को खोजना मुश्किल नहीं है। लेकिन यह स्पष्ट रूप से आपको "पूरी तरह से वीटो" प्रमाणपत्र नहीं मिलेगा; यदि आप वास्तव में ऐसा चाहते हैं, तो आपको EV प्रमाणपत्र प्राप्त करने के लिए हुप्स के माध्यम से कूदना होगा, और संबंधित मूल्य का भुगतान करना होगा (और जैसा कि पहले बताया गया है, यहां तक ​​कि ईवी सेर्ट्स भी परिपूर्ण नहीं हैं या बिना केविट के आते हैं)। आइए एनक्रिप्ट को कुछ कारणों के बारे में चर्चा करें कि उनके वेब साइट पर 90 दिनों के लिए उनके सिर्फ़ वैध क्यों हैं, लेकिन लेट्स एनक्रिप्ट के अस्तित्व ने अभी तक वाणिज्यिक सीए को अपने डीवी सर्टिफिकेट को खींचने के लिए प्रेरित नहीं किया है।
बजे एक CVn

4

लगता है कि किसी और का उल्लेख नहीं है,

अगर आप अपनी साइट से जुड़ने वाली हर मशीन के मालिक हैं

उदाहरण के लिए "यह संभवतः वह नहीं है जो आप चाहते हैं"

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

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

हालांकि एक छलनी तैनाती के लिए, यदि आप XCA की कोशिश कर सकते हैं

XCS छोटे तैनाती के लिए सीट्स जारी करने का एक अच्छा तरीका है और इसमें पूरे डॉक्यूमेंट के माध्यम से चलने वाले डॉक्यूमेंटेशन शामिल हैं।


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

1

मेरे पास कुछ विचार हैं।

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

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


Chrome का आगामी संस्करण किसी भी पाठ इनपुट के बारे में चेतावनी देगा, न कि केवल पासवर्ड फ़ील्ड। HTML फॉर्म का उपयोग करने वाले किसी भी डेटा को चेतावनी से बचने के लिए HTTPS होना चाहिए, न कि केवल लॉगिन। Google उन वेबसाइट स्वामियों को खोज कंसोल के माध्यम से सूचनाएँ भेज रहा है, जिनकी वेबसाइटें Google को प्रभावित करती हैं।
स्टीफन Ostermiller

1

नहीं।

आपके द्वारा की गई कोई भी हैक (जैसे जावास्क्रिप्ट के साथ एन्क्रिप्ट करने की कोशिश करना), बहुत सुरक्षित होने के करीब होने की संभावना नहीं है।

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


-3

फ्री, क्विक सॉल्यूशन लेट्स एनक्रिप्ट है। लिंक वे लगभग हर सर्वर ओएस के लिए प्रलेखन है। हम इसे अपने काम में उपयोग करते हैं, और हमारे W2P विक्रेता हमारे प्रत्येक स्टोरफ्रंट को सुरक्षित करने के लिए इसका उपयोग करते हैं।


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