कैप्टिव पोर्टल में एसएसएल सर्टिफिकेट त्रुटियां

10

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

ssl redirect

संभव समाधान: एक रेडियस प्रमाणीकरण सर्वर के साथ WPA2-Enterprise।

— Ajedi32

यह एक समाधान नहीं है, लेकिन फिलहाल वर्कअराउंड के रूप में सर्वर के लिए है। उपयोगकर्ताओं को स्वतंत्र रूप से https का उपयोग करने की अनुमति दें, और पहले http हिट पर, उन्हें पुनर्निर्देशित किया जाएगा क्योंकि उद्योग को अधिक से अधिक स्थानांतरित करने के लिए यह अप्रचलित हो जाएगा।

— cusco

6

"कैप्टिव पोर्टल" की पूरी परिभाषा "उसके / उसके ज्ञान के बिना उपयोगकर्ता को पुनर्निर्देशित करने" के चारों ओर घूमती है, जो एसएसएल से बचने के लिए बनाई गई चीजों में से एक है।

यदि पहला URL जो ब्राउज़र खोलने का प्रयास करता है वह HTTPS एक है, तो प्रमाणपत्र त्रुटि बनाए बिना ट्रैफ़िक को पुनर्निर्देशित करने का कोई तरीका नहीं है।

— मास्सिमो
स्रोत

4

हाँ, मुझे लगता है कि ओपी समझता है कि। सवाल था: विकल्प क्या है? (उदा। यदि अस्तित्व में प्रत्येक साइट HTTPS का उपयोग करती है, तो आप "कैप्टिव पोर्टल के बिना" पुष्टिकरण प्रक्रिया पर एक अतिथि लॉग का प्रबंधन कैसे कर सकते हैं?)

— Ajedi32

5

क्रोमियम प्रोजेक्ट में यह वर्णन करने के लिए एक अच्छा पृष्ठ है कि कैप्टिव पोर्टल्स का पता लगाने के लिए उनका तर्क कैसे काम करता है :

एक प्रसिद्ध होस्ट + URI से कनेक्ट करने के लिए (सादे HTTP) का प्रयास करें
उम्मीद HTTP 204 No Content
यदि एक अलग प्रतिक्रिया प्राप्त होती है, तो मान लें कि यह एक कैप्टिव पोर्टल है।

दिए गए लिंक में अन्य विवरण हैं कि वे प्रसिद्ध होस्ट को हल करने की कोशिश में DNS विफलताओं को कैसे संभालते हैं, आदि। यह सिर्फ एक उदाहरण है, लेकिन (मेरे व्यक्तिगत अनुभव में) आधुनिक ओएस डिजाइन पता लगाने के लिए इसी तरह की प्रक्रियाओं का उपयोग कर रहे हैं। और उपयोगकर्ता को कुछ मामलों में, उपयोगकर्ता को ब्राउज़र खोलने से पहले भी संकेत दें। (विचार करें: कोई व्यक्ति जो केवल IMAP क्लाइंट या अन्य गैर-HTTP सेवा का उपयोग करना चाहता है।) उस स्थिति में, SSL / TLS का पता नहीं लगता है, इसलिए आपकी चिंता से बचा जाता है।

RFC 6585 धारा 6 एक नया HTTP स्टेटस कोड प्रस्तावित 511 Network Authentication Requiredकरता है जो आपके SSL / TLS मामले में मदद नहीं करता है, लेकिन एक और मानक है जिस पर आप विचार कर सकते हैं यदि आप पहले से ही इसका उपयोग नहीं करते हैं।

— विलियम प्राइस
स्रोत

कैप्टिव पोर्टल्स का पता लगाने के लिए एंड्रॉइड का भी समर्थन है। जब यह एक कैप्टिव पोर्टल का पता लगाता है तो यह स्टेटस बार पर एक संदेश प्रदर्शित करता है। शब्द "वायरलेस नेटवर्क में साइन इन करें" जैसा कुछ है। ऐसा तब भी होता है जब किसी एप्लिकेशन ने अभी तक कनेक्शन का उपयोग करने की कोशिश नहीं की है। कुछ बिंदु पर मैंने एक कैप्टिव पोर्टल को एक अतिरिक्त HTTP हेडर के साथ 30x रीडायरेक्ट भेजने पर भी ध्यान दिया, यह दर्शाता है कि यह एक कैप्टिव पोर्टल था, और शरीर में कुछ एक्सएमएल डेटा था। मुझे नहीं पता कि यह कुछ मानक व्यवहार है।

— कैस्परड

0

किसी भी स्थिति में, यदि उपयोगकर्ताओं को प्रमाणपत्र त्रुटि मिलती है, क्योंकि प्रमाणपत्र साइट होस्टनाम से मेल नहीं खाता है ।

आपके मामले में, इसका अर्थ है कि आप URL को बदले बिना उपयोगकर्ताओं को आपके पोर्टल पर पुनर्निर्देशित कर रहे हैं। उपयोगकर्ता अपने पता बार में " http://www.google.com " देखते हैं लेकिन स्क्रीन में आपका पोर्टल। ये मेल नहीं खाते, जाहिर है, और प्रमाणपत्र भी नहीं है।

आपको उन्हें अपने पोर्टल पते (या सर्वर नाम) में HTTP (HTTPS जंपिंग से पहले) में रीडायरेक्ट करने की आवश्यकता है , उन्हें वहां लॉग इन करें और फिर उन्हें फिर से इच्छित गंतव्य पर पुनः निर्देशित करें, जो सही तरीके से मेल खाएगा।

HTTP 3xx कोड, विशेष रूप से 303 के साथ इसे कैसे करें, इसके लिए https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx देखें ।

— Envite
स्रोत

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

— विलियम प्राइस

-1

अस्थायी समाधान कनेक्टेड वाईफाई सिग्नल के बाद ही "http" के साथ यूआरएल शुरुआत करने के लिए उपयोगकर्ताओं को गाइड करता है।

लेकिन दुर्भाग्य से, उपयोगकर्ताओं को यह पसंद नहीं है। वे कहते हैं कि "आपके पास कितनी जटिल वाईफाई सेवा है"

— छंद सतु
स्रोत