वीपीएन के माध्यम से पहला अनुरोध HTTPS कैसे करें
HTTPS-केवल मोड, वास्तविक HTTPS बुकमार्क और HSTS तीन अलग-अलग फ़िक्सेस हैं। उनके माध्यम से क्रम से चलाएँ ताकि पहला अनुरोध एन्क्रिप्टेड हो, पुनर्निर्देशित न हो।
एक ब्राउज़र जो पहले http:// टाइप करता है और रीडायरेक्ट के बाद https:// पर आता है, वह पहले ही स्पष्ट रूप से एक अनुरोध भेज चुका है, और एक वीपीएन उसे नहीं बदलता है। सुरंग क्लाइंट से निकास नोड तक पैर की रक्षा करती है; यह ट्रांसपोर्ट लेयर के ऊपर कुछ भी एन्क्रिप्ट नहीं करता है, इसलिए निकास और मूल के बीच एक पर्यवेक्षक अभी भी प्लेनटेक्स्ट हॉप देखता है। HTTPS को पहला अनुरोध बनाना तीन भागों के साथ क्लाइंट-साइड परिवर्तन है: एक वास्तविक HTTPS पता, ब्राउज़र का अपग्रेड मोड और साइट की अपनी नीति। नीचे दिए गए चरण वे क्रम हैं जिनका मैं उपयोग करता हूं, प्रत्येक चेक के साथ जो आपको बताता है कि यह हुआ या नहीं।
चरण 1: पुष्टि करें कि पहला अनुरोध वास्तव में क्या है
कुछ भी बदलने से पहले, देखें कि ब्राउज़र क्या भेजता है। कोल्ड कैश से पुनः लोड किए गए पेज के साथ नेटवर्क पैनल खोलें और पहली पंक्ति पढ़ें: यदि योजना http है और स्थिति 301 या 308 है, तो उस पंक्ति के बाद सब कुछ दूसरा अनुरोध है। curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com ब्राउज़र के बाहर उसी अनुक्रम को पुन: उत्पन्न करता है और आपके द्वारा समाप्त किए गए URL को प्रिंट करता है।
दो परिणाम संभव हैं और उन्हें अलग-अलग सुधारों की आवश्यकता है। यदि साइट एक ही होस्ट पर HTTPS परोसती है, तो समाधान HTTP फॉर्म को प्रकाशित करना बंद करना है: बुकमार्क, विकी लिंक, डेस्कटॉप शॉर्टकट और ईमेल टेम्पलेट को अपडेट करें जिस पर लोग क्लिक करते हैं। यदि साइट बिल्कुल भी HTTPS सेवा नहीं देती है, तो कोई भी ब्राउज़र सेटिंग इसे नहीं बनाएगी, और ईमानदार उत्तर यह है कि गंतव्य ही समस्या है। दूसरे मामले को अपवाद के साथ न लिखें, क्योंकि खाता पृष्ठ पर प्रमाणपत्र अपवाद परिवहन समस्या को क्रेडेंशियल समस्या में बदल देता है। किसी सेटिंग को छूने से पहले लिखें कि आप किस स्थिति में हैं।
चरण 2: ब्राउज़र का HTTPS-केवल मोड चालू करें
अपग्रेड मोड दूसरा भाग है, और मोड विनिमेय नहीं हैं। इसे सक्षम करने से पहले जांच लें कि आपका क्या करता है: चुपचाप अपग्रेड करें, चेतावनी के साथ अपग्रेड करें, या लोड करने से इनकार करें।
फ़ायरफ़ॉक्स में नियंत्रण about:config के पीछे और गोपनीयता सेटिंग पृष्ठ में रहते हैं, स्विच के रूप में dom.security.https_only_mode के साथ और पैडलॉक मेनू से प्रति-साइट अपवाद प्रबंधित होते हैं। क्रोम और एज में एक ही विचार सेटिंग्स, गोपनीयता और सुरक्षा, सुरक्षा के अंतर्गत बैठता है, जिसे हमेशा सुरक्षित कनेक्शन का उपयोग करें लेबल किया गया है। लेबल जो भी हो, उस होस्ट के विरुद्ध व्यवहार को सत्यापित करें जो केवल पोर्ट 80 पर उत्तर देता है, क्योंकि एक मोड जो अपग्रेड होता है और फिर चुपचाप वापस आ जाता है वह वह सुरक्षा नहीं है जिसे आप सोचते हैं कि आपने सक्षम किया है। फ़ायरफ़ॉक्स HTTPS-केवल दस्तावेज़ उस ब्राउज़र के लिए अपग्रेड, चेतावनी और अपवाद व्यवहार का वर्णन करता है।
चरण 3: संसाधनों को ठीक करें, न कि केवल पता बार को
जब कोई अपग्रेड विफल हो जाता है, तो पता बार के बजाय सटीक त्रुटि पढ़ें। बिना HTTPS श्रोता वाला एक होस्ट, एक होस्टनाम जो प्रमाणपत्र से मेल नहीं खाता है और एक समाप्त श्रृंखला अलग-अलग संदेश उत्पन्न करती है और विभिन्न मालिकों से संबंधित होती है। केवल पहला सर्वर-साइड गैप है; दूसरा आमतौर पर एक बुकमार्क होता है जिसे कभी अपडेट नहीं किया गया; तीसरी एक नवीनीकरण समस्या है जिसके लिए वीपीएन कनेक्शन अप्रासंगिक है।
किसी अकाउंट साइट पर प्रमाणपत्र अपवाद न जोड़ें क्योंकि वीपीएन चालू है। अपवाद उस चेक को अक्षम कर देता है जो ठीक उसी अवरोधन को पकड़ लेता जिसे वीपीएन रोकने के लिए होता है।
तीसरा भाग पृष्ठ के अंदर है, और यह वह है जिसे लोग चूक जाते हैं। एक पृष्ठ जो HTTPS पर लोड होता है वह अभी भी http URL से चित्र, फ़ॉन्ट या स्क्रिप्ट खींच सकता है, और ब्राउज़र या तो उन्हें ब्लॉक कर देगा या पूरे पृष्ठ के लिए सुरक्षा संकेतक को डाउनग्रेड कर देगा। नेटवर्क पैनल में विफल अनुरोधों का निरीक्षण करें और पता बार प्रत्येक अनुरोध का वर्णन करने के बजाय उनके स्वामी पर संसाधन संदर्भ ठीक करें। आपके द्वारा चलाई जाने वाली साइट पर, इसका मतलब है कि ब्राउज़र में उन्हें दोबारा लिखने के बजाय सीएमएस या टेम्पलेट में संग्रहीत यूआरएल को सही करना। यदि आप स्रोत नहीं बदल सकते हैं, तो मिश्रित सामग्री को ज्ञात अंतराल के रूप में रिकॉर्ड करें, क्योंकि किसी पृष्ठ पर एक ताला जो सादे पाठ संसाधनों को खींचता है, एक गलत संकेत है।
चरण 4: HSTS क्या जोड़ता है, और क्या नहीं
एचएसटीएस एक ब्राउज़र प्राथमिकता के बजाय एक साइट नीति है, और यह यहां एकमात्र तंत्र है जो एक ताजा प्रोफ़ाइल पर टाइप किए गए http:// को बरकरार रखता है। एक बार जब कोई ब्राउज़र किसी होस्ट के लिए Strict-Transport-Security हेडर देख लेता है, तो यह बाद में अनुरोधों को भेजने से पहले https पर फिर से लिखता है, जो बिल्कुल वही संपत्ति है जो आप चाहते हैं। यह उस होस्ट के लिए कुछ नहीं करता है जिस पर ब्राउज़र कभी नहीं गया है, और एक ही एप्लिकेशन पर काम करने वाले किसी भिन्न होस्टनाम के लिए कुछ भी नहीं करता है।
जांचें कि मूल स्रोत curl -sSI https://example.com | grep -i strict-transport-security के साथ क्या भेजता है। एक अनुपलब्ध हेडर एक सर्वर परिवर्तन है और ऐसा कुछ नहीं जिसे क्लाइंट इंस्टॉल कर सके। यदि यह मौजूद है, तो max-age पढ़ें और क्या includeSubDomains सेट है, क्योंकि विज़िट के बीच एक छोटी अधिकतम आयु समाप्त हो जाती है और एक गायब includeSubDomains प्रत्येक उपडोमेन को असुरक्षित छोड़ देता है। आरएफसी 6797 परिभाषित करता है कि एक उपयोगकर्ता एजेंट नीति को कैसे लागू करता है और वह क्या अनदेखा कर सकता है। प्रीलोड एक अलग प्रतिबद्धता है, इसलिए किसी को यह वादा करने से पहले कि डोमेन सूची में है, hstspreload.org एपीआई के माध्यम से स्थिति की जांच करें।
सत्यापन और रोलबैक
क्लाइंट सेटिंग्स के लिए रोलबैक सस्ता है और HSTS के लिए महंगा है। HTTPS-केवल मोड को बंद करने से पिछला व्यवहार तुरंत बहाल हो जाता है; लंबी अधिकतम आयु नहीं होती है, और जिन विज़िटरों को यह पहले ही प्राप्त हो चुका है वे इसे समाप्त होने तक अपग्रेड करते रहते हैं।
इसलिए इसे पूरा करने से पहले सत्यापित कर लें। कोल्ड कैश से पुनः लोड करें और पुष्टि करें कि नेटवर्क पैनल में पहला अनुरोध https है, जिसमें कोई पूर्ववर्ती रीडायरेक्ट नहीं है। फिर एक उपडोमेन की जाँच करें, क्योंकि includeSubDomains वह जगह है जहाँ ये नीतियाँ आमतौर पर अनुमान से अधिक संकीर्ण हो जाती हैं। फिर एक पृष्ठ की जाँच करें जो तृतीय-पक्ष संपत्तियों को खींचता है, क्योंकि मिश्रित सामग्री वह विफलता है जो हर दूसरे सुधार से बची रहती है।
यदि इन सबके बाद भी पहला अनुरोध http है, तो क्लाइंट अब वेरिएबल नहीं है: लोग जिस लिंक पर क्लिक करते हैं वह है। होस्टनाम के http फॉर्म के लिए उन स्थानों को खोजें जिन्हें आप नियंत्रित करते हैं, उन्हें अपडेट करें, और उसी कोल्ड-कैश रीलोड के साथ पुनः परीक्षण करें। वीपीएन प्रश्न को पूरे समय अलग रखें, क्योंकि सुरंग बदल जाती है कि अनुरोध को कौन देख सकता है और यह कभी नहीं बदलता कि अनुरोध एन्क्रिप्ट किया गया है या नहीं। टिकट में डालने वाली पंक्ति यह है कि पहला अनुरोध वह है जो मायने रखता है, और रीडायरेक्ट केवल पहले से भेजे गए अनुरोध की रसीद है।