VPN मार्फत 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-मात्र मोड खोल्नुहोस्

अपग्रेड मोड दोस्रो भाग हो, र मोडहरू आदानप्रदान योग्य छैनन्। तपाईंले यसलाई सक्षम गर्नु अघि तपाईंको के गर्छ जाँच गर्नुहोस्: चुपचाप अपग्रेड गर्नुहोस्, एक चेतावनीको साथ अपग्रेड गर्नुहोस्, वा लोड गर्न अस्वीकार गर्नुहोस्।

फायरफक्समा नियन्त्रणहरू about:config पछाडि र गोपनीयता सेटिङ पृष्ठमा रहन्छन्, dom.security.https_only_mode को रूपमा स्विच र प्रति-साइट अपवादहरू ताल्चा मेनुबाट व्यवस्थित हुन्छन्। क्रोम र एजमा समान विचार सेटिङहरू, गोपनीयता र सुरक्षा, सुरक्षा, सधैं सुरक्षित जडानहरू प्रयोग गर्नुहोस् लेबल गरिएको छ। जुनसुकै लेबल, पोर्ट 80 मा मात्र जवाफ दिने होस्ट विरुद्ध व्यवहार प्रमाणित गर्नुहोस्, किनभने अपग्रेड र त्यसपछि चुपचाप फिर्ता आउने मोड तपाईंले सक्षम गर्नुभएको सुरक्षा होइन। Firefox HTTPS-Only कागजात ले त्यो ब्राउजरको लागि अपग्रेड, चेतावनी र अपवाद व्यवहारको हिज्जे गर्छ।

चरण 3: स्रोतहरू ठीक गर्नुहोस्, ठेगाना पट्टी मात्र होइन

जब अपग्रेड असफल हुन्छ, ठेगाना पट्टीको सट्टा सही त्रुटि पढ्नुहोस्। HTTPS श्रोता नभएको होस्ट, प्रमाणपत्रसँग मेल नखाने होस्टनाम र म्याद सकिएको चेनले फरक सन्देशहरू उत्पादन गर्छ र फरक मालिकहरूसँग सम्बन्धित छ। केवल पहिलो सर्भर-साइड ग्याप हो; दोस्रो सामान्यतया एउटा बुकमार्क हो जुन कहिल्यै अद्यावधिक गरिएको थिएन; तेस्रो एक नवीकरण समस्या हो जुन VPN जडान अप्रासंगिक छ।

खाता साइटमा प्रमाणपत्र अपवाद थप नगर्नुहोस् किनभने VPN सक्रिय छ। अपवादले जाँचलाई असक्षम पार्छ जसले VPN लाई रोक्नको लागि हो।

तेस्रो भाग पृष्ठ भित्र छ, र यो एक मान्छे मिस छ। HTTPS मा लोड हुने पृष्ठले अझै पनि HTTP URL बाट छविहरू, फन्टहरू वा स्क्रिप्टहरू तान्न सक्छ, र ब्राउजरले तिनीहरूलाई ब्लक गर्नेछ वा सम्पूर्ण पृष्ठको सुरक्षा सूचकलाई डाउनग्रेड गर्नेछ। नेटवर्क प्यानलमा असफल अनुरोधहरू निरीक्षण गर्नुहोस् र ठेगाना पट्टीले प्रत्येक अनुरोधलाई वर्णन गरेको मान्नुको सट्टा तिनीहरूको मालिकमा स्रोत सन्दर्भहरू ठीक गर्नुहोस्। तपाईंले चलाउनुहुने साइटमा, यसको मतलब ब्राउजरमा पुन: लेख्नुको सट्टा CMS वा टेम्प्लेटमा भण्डारण गरिएका URL हरू सुधार्नु हो। यदि तपाइँ स्रोत परिवर्तन गर्न सक्नुहुन्न भने, मिश्रित सामग्रीलाई ज्ञात अन्तरको रूपमा रेकर्ड गर्नुहोस्, किनकि सादा पाठ स्रोतहरू तान्ने पृष्ठमा ताला लगाउनु गलत संकेत हो।

चरण 4: HSTS ले के थप्छ र के गर्दैन

HSTS ब्राउजर प्राथमिकताको सट्टा साइट नीति हो, र यो यहाँ एक मात्र संयन्त्र हो जुन ताजा प्रोफाइलमा टाइप गरिएको छ। एक पटक ब्राउजरले होस्टको लागि Strict-Transport-Security हेडर देखेपछि, यसले पठाउनु अघि https मा अनुरोधहरू पुन: लेख्छ, जुन तपाईले चाहानु भएको गुण हो। ब्राउजरले कहिल्यै भ्रमण नगरेको होस्टका लागि यसले केही गर्दैन, र एउटै एप सेवा गर्ने फरक होस्टनामको लागि केही गर्दैन।

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

प्रमाणीकरण र रोलब्याक

ग्राहक सेटिङहरूको लागि रोलब्याक सस्तो र HSTS को लागि महँगो छ। HTTPS-मात्र मोड बन्द गर्दा अघिल्लो व्यवहार तुरुन्तै पुनर्स्थापित हुन्छ; लामो अधिकतम-उमेर गर्दैन, र पहिले नै प्राप्त गरेका आगन्तुकहरूले यसको म्याद समाप्त नभएसम्म अपग्रेड गरिरहन्छन्।

त्यसैले यो सम्पन्न भएको कल गर्नु अघि क्रम मा प्रमाणित गर्नुहोस्। कोल्ड क्यासबाट पुन: लोड गर्नुहोस् र नेटवर्क प्यानलमा पहिलो अनुरोध https कुनै पूर्व रिडिरेक्ट बिना पुष्टि गर्नुहोस्। त्यसपछि एउटा सबडोमेन जाँच गर्नुहोस्, किनकि समावेश सबडोमेन हो जहाँ यी नीतिहरू सामान्यतया अनुमान गरिएको भन्दा साँघुरो हुन्छन्। त्यसपछि तेस्रो-पक्ष सम्पत्तिहरू तान्ने एउटा पृष्ठ जाँच गर्नुहोस्, किनकि मिश्रित सामग्री असफलता हो जुन हरेक अर्को समाधानमा बाँच्दछ।

यदि ती सबै पछि पहिलो अनुरोध अझै पनि http हो भने, क्लाइन्ट अब चर छैन: मानिसहरूले क्लिक गर्ने लिङ्क हो। होस्टनामको http फारमको लागि तपाईंले नियन्त्रण गर्ने ठाउँहरू खोज्नुहोस्, तिनीहरूलाई अद्यावधिक गर्नुहोस्, र उही चिसो क्यास रिलोडको साथ पुन: परीक्षण गर्नुहोस्। VPN प्रश्नलाई अलग-अलग राख्नुहोस्, किनभने सुरंगले अनुरोध हेर्न सक्ने व्यक्ति परिवर्तन गर्दछ र अनुरोध इन्क्रिप्ट गरिएको छ कि छैन भनेर कहिल्यै परिवर्तन गर्दैन। टिकटमा राख्नको लागि लाइन यो हो कि पहिलो अनुरोध महत्त्वपूर्ण छ, र एक रिडिरेक्ट पहिले नै पठाइएको अनुरोधको लागि मात्र एक रसिद हो।