व्हीपीएनद्वारे HTTPS प्रथम विनंती कशी करावी

एक ब्राउझर जो प्रथम http:// टाइप करतो आणि पुनर्निर्देशनानंतर https:// वर येतो आणि आधीच एक विनंती स्पष्टपणे पाठवली आहे आणि VPN ते बदलत नाही. बोगदा क्लायंटपासून एक्झिट नोडपर्यंत लेगचे संरक्षण करते; ते ट्रान्सपोर्ट लेयरच्या वर काहीही कूटबद्ध करत नाही, म्हणून बाहेर पडणे आणि उत्पत्ती दरम्यान एक निरीक्षक अजूनही प्लेनटेक्स्ट हॉप पाहतो. 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-केवळ मोड चालू करा

अपग्रेड मोड हा दुसरा भाग आहे आणि मोड बदलण्यायोग्य नाहीत. तुम्ही ते सक्षम करण्यापूर्वी तुमचे काय करते ते तपासा: शांतपणे अपग्रेड करा, चेतावणीसह अपग्रेड करा किंवा लोड करण्यास नकार द्या.

Firefox मध्ये नियंत्रणे about:config च्या मागे राहतात आणि गोपनीयता सेटिंग्ज पृष्ठावर dom.security.https_only_mode सह स्विच आणि प्रति-साइट अपवाद पॅडलॉक मेनूमधून व्यवस्थापित केले जातात. Chrome आणि Edge मध्ये समान कल्पना सेटिंग्ज, गोपनीयता आणि सुरक्षा, सुरक्षा, नेहमी सुरक्षित कनेक्शन वापरा असे लेबल केलेले आहे. लेबल काहीही असो, फक्त पोर्ट 80 वर उत्तर देणाऱ्या होस्टच्या विरुद्ध वर्तनाची पडताळणी करा, कारण मोड जो अपग्रेड होतो आणि नंतर शांतपणे मागे पडतो ते संरक्षण नाही असे तुम्हाला वाटते की तुम्ही सक्षम केले आहे. Firefox HTTPS-Only डॉक्युमेंटेशन त्या ब्राउझरसाठी अपग्रेड, चेतावणी आणि अपवाद वर्तन स्पष्ट करते.

चरण 3: संसाधनांचे निराकरण करा, फक्त ॲड्रेस बारच नाही

जेव्हा अपग्रेड अयशस्वी होते, तेव्हा ॲड्रेस बारऐवजी अचूक त्रुटी वाचा. HTTPS श्रोता नसलेले होस्ट, प्रमाणपत्राशी जुळणारे होस्टनाव आणि कालबाह्य झालेली साखळी वेगवेगळे संदेश तयार करतात आणि वेगवेगळ्या मालकांचे असतात. फक्त पहिला सर्व्हर-साइड अंतर आहे; दुसरा सहसा एक बुकमार्क असतो जो कधीही अद्यतनित केलेला नाही; तिसरी एक नूतनीकरण समस्या आहे ज्यासाठी VPN कनेक्शन अप्रासंगिक आहे.

VPN चालू असल्यामुळे खाते साइटवर प्रमाणपत्र अपवाद जोडू नका. अपवाद हा चेक अक्षम करतो ज्याने VPN ला रोखण्यासाठी नेमका व्यत्यय पकडला असेल.

तिसरा भाग पृष्ठाच्या आत आहे, आणि तो एक आहे जो लोक चुकतात. HTTPS वर लोड होणारे पृष्ठ अद्याप HTTP URL वरून प्रतिमा, फॉन्ट किंवा स्क्रिप्ट्स काढू शकते आणि ब्राउझर त्यांना ब्लॉक करेल किंवा संपूर्ण पृष्ठासाठी सुरक्षा निर्देशक डाउनग्रेड करेल. नेटवर्क पॅनेलमधील अयशस्वी विनंत्यांची तपासणी करा आणि ॲड्रेस बार प्रत्येक विनंतीचे वर्णन करते असे गृहित धरण्यापेक्षा त्यांच्या मालकाकडे संसाधन संदर्भ निश्चित करा. तुम्ही चालवलेल्या साइटवर, याचा अर्थ ब्राउझरमध्ये पुन्हा लिहिण्याऐवजी CMS किंवा टेम्पलेटमध्ये संग्रहित URL दुरुस्त करणे. तुम्ही स्त्रोत बदलू शकत नसल्यास, मिश्रित सामग्री ज्ञात अंतर म्हणून रेकॉर्ड करा, कारण प्लेनटेक्स्ट रिसोर्सेस खेचणाऱ्या पेजवर पॅडलॉक हा चुकीचा सिग्नल आहे.

चरण 4: HSTS काय जोडते आणि काय नाही

एचएसटीएस हे ब्राउझर प्राधान्याऐवजी साइट धोरण आहे आणि येथे ही एकमेव यंत्रणा आहे जी नवीन प्रोफाइलवर टाइप केलेले http:// टिकून राहते. एकदा ब्राउझरने होस्टसाठी Strict-Transport-Security हेडर पाहिल्यानंतर, ते पाठवण्यापूर्वी https वर नंतरच्या विनंत्या पुन्हा लिहितात, जी तुम्हाला हवी असलेली मालमत्ता आहे. ब्राउझरने कधीही भेट न दिलेल्या होस्टसाठी ते काहीही करत नाही आणि त्याच ऍप्लिकेशनला सेवा देणाऱ्या वेगळ्या होस्टनावासाठी काहीही करत नाही.

curl -sSI https://example.com | grep -i strict-transport-security ने मूळ काय पाठवते ते तपासा. गहाळ शीर्षलेख हा सर्व्हर बदल आहे आणि क्लायंट स्थापित करू शकत नाही. ते उपस्थित असल्यास, max-age वाचा आणि includeSubDomains सेट केले आहे की नाही, कारण भेटी दरम्यान एक लहान कमाल-वय कालबाह्य होते आणि गहाळ समावेश सबडोमेन प्रत्येक सबडोमेन असुरक्षित ठेवते. RFC 6797 वापरकर्ता एजंट धोरण कसे लागू करतो आणि ते कशाकडे दुर्लक्ष करू शकते हे परिभाषित करते. प्रीलोड ही एक वेगळी बांधिलकी आहे, त्यामुळे डोमेन यादीत असल्याचे कोणालाही वचन देण्यापूर्वी hstspreload.org API द्वारे स्थिती तपासा.

सत्यापन आणि रोलबॅक

क्लायंट सेटिंग्जसाठी रोलबॅक स्वस्त आणि HSTS साठी महाग आहे. HTTPS-केवळ मोड बंद केल्याने मागील वर्तन त्वरित पुनर्संचयित होते; एक लांब कमाल-वय होत नाही आणि ज्या अभ्यागतांना ते आधीच मिळाले आहे ते ते कालबाह्य होईपर्यंत अपग्रेड करत राहतात.

म्हणून पूर्ण झाले म्हणण्यापूर्वी क्रमाने पडताळणी करा. कोल्ड कॅशेमधून रीलोड करा आणि नेटवर्क पॅनलमधील पहिल्या विनंतीची पुष्टी करा https आहे, कोणतेही पुर्वीचे पुनर्निर्देशन नाही. नंतर सबडोमेन तपासा, कारण सबडोमेन समाविष्ट आहे जिथे ही पॉलिसी सहसा गृहीत धरल्यापेक्षा अरुंद असतात. नंतर एक पृष्ठ तपासा जे तृतीय-पक्ष मालमत्ता खेचते, कारण मिश्र सामग्री ही अपयश आहे जी इतर प्रत्येक निराकरणात टिकून राहते.

त्यानंतरही जर पहिली विनंती http असेल, तर क्लायंट आता व्हेरिएबल राहणार नाही: लोक क्लिक करतात ती लिंक आहे. होस्टनावाच्या http फॉर्मसाठी तुम्ही नियंत्रित करत असलेली ठिकाणे शोधा, त्यांना अपडेट करा आणि त्याच कोल्ड-कॅशे रीलोडसह पुन्हा चाचणी करा. संपूर्ण VPN प्रश्न वेगळा ठेवा, कारण बोगदा विनंती कोण पाहू शकतो ते बदलते आणि विनंती एन्क्रिप्ट केलेली आहे की नाही हे कधीही बदलत नाही. तिकिटात टाकण्याची ओळ अशी आहे की पहिली विनंती महत्त्वाची असते आणि पुनर्निर्देशन ही आधीपासून पाठवलेल्या विनंतीची पावती असते.