ক্যাপটিভ পোর্টালগুলিতে এসএসএল শংসাপত্রের ত্রুটি


10

পরিস্থিতি: হোটেল অতিথিরা আমাদের বন্দী পোর্টালের মাধ্যমে ইন্টারনেট অ্যাক্সেসের চেষ্টা করছেন। সমস্যা: গুগল, ইয়াহু এবং এখন আরও অনেক বেশি সাইটগুলি সমস্ত হোম পৃষ্ঠাগুলি এইচটিটিপিএস-এ পুনর্নির্দেশ করে তাই অতিথি যখন আমাদের পৃষ্ঠাটিতে আমাদের লগতে পুনর্নির্দেশ করবেন তখন শংসাপত্রের ত্রুটি ঘটে। এসএসএলের প্রশংসা করার উদ্দেশ্য হ'ল এটি করা কিন্তু আশ্চর্য হওয়া যে ফায়ারওয়ালের মাধ্যমে অ্যাক্সেস সক্ষম করার আগে তাদের পরিচয় নিশ্চিত করার জন্য নিশ্চিতকরণ প্রক্রিয়াতে কোনও অতিথি লগ পরিচালনা করার অন্য কোনও উপায় আছে কিনা wonder এটি অতিথিদের প্রকাশ করছে যারা বুঝতে পারে না। মূলত ক্যাপটিভ পোর্টাল / প্রমাণীকরণ প্রক্রিয়াটির জন্য একটি আলাদা আর্কিটেকচারের প্রয়োজন এবং যে কারও কী চিন্তাভাবনা তা অবাক করে দেয়। ধন্যবাদ।


সম্ভাব্য সমাধান: একটি ব্যাসার্ধ প্রমাণীকরণ সার্ভার সহ ডাব্লুপিএ 2-এন্টারপ্রাইজ।
Ajedi32

এটি কোনও সমাধান নয়, তবে এই মুহুর্তের জন্য সার্ভারগুলি একটি কর্মসংস্থান হিসাবে। ব্যবহারকারীদের অবাধে https অ্যাক্সেস করার মঞ্জুরি দিন এবং প্রথম এইচটিপি হিট-এ, তাদের ইন্ডাস্ট্রি আরও বেশি করে https এ স্থানান্তরিত করায় এগুলি পুনঃনির্দেশিত করা হবে এটি অচল হয়ে যাবে।
কুস্কো

উত্তর:


6

"ক্যাপটিভ পোর্টাল" এর পুরো সংজ্ঞাটি "তার জ্ঞান ছাড়াই ব্যবহারকারীকে পুনর্নির্দেশ করা" এর চারদিকে ঘোরে, যা এসএসএল এড়ানোর জন্য তৈরি করা ঠিক একটি বিষয়।

ব্রাউজারটি যদি প্রথম URL টি খোলার চেষ্টা করে তবে এটি এইচটিটিপিএস হয়, শংসাপত্রের ত্রুটি তৈরি না করে ট্র্যাফিক পুনর্নির্দেশের কোনও উপায় নেই।


4
হ্যাঁ, আমি মনে করি ওপি বুঝতে পারে। প্রশ্ন ছিল: বিকল্প কি? (উদাহরণস্বরূপ, যদি অস্তিত্বের প্রতিটি সাইট এইচটিটিপিএস ব্যবহার করে তবে বন্দি পোর্টাল ব্যতীত কীভাবে আপনি "নিশ্চিতকরণ প্রক্রিয়াতে কোনও অতিথি লগ পরিচালনা করতে পারেন")
আজেদী 32

5

তাদের যুক্তি কীভাবে বন্দি পোর্টালগুলি সনাক্ত করার জন্য কাজ করে তা বর্ণনা করে ক্রোমিয়াম প্রকল্পের একটি ভাল পৃষ্ঠা রয়েছে :

  1. একটি সুপরিচিত হোস্ট + ইউআরআইতে (প্লেইন এইচটিটিপি) সংযোগের চেষ্টা
  2. আশা করা HTTP 204 No Content
  3. যদি কোনও ভিন্ন প্রতিক্রিয়া পাওয়া যায় তবে ধরে নিন এটি একটি বন্দী পোর্টাল।

সুপরিচিত হোস্ট ইত্যাদি সমাধান করার চেষ্টা করার সময় তারা ডিএনএস ব্যর্থতাগুলি কীভাবে পরিচালনা করে সে সম্পর্কিত প্রদত্ত লিঙ্কে অন্যান্য বিবরণ রয়েছে। এটি কেবল একটি উদাহরণ, তবে (আমার ব্যক্তিগত অভিজ্ঞতায়) আধুনিক ওএস ডিজাইনগুলি সনাক্ত করার জন্য এটির মতো প্রক্রিয়াগুলি ব্যবহার করছে এবং ব্যবহারকারীর একটি ব্রাউজার খোলার আগে কিছু ক্ষেত্রে, এমনকি ব্যবহারকারীকে অনুরোধ জানায়। (বিবেচনা করুন:। কেউ শুধুমাত্র একটি IMAP এর ক্লায়েন্ট বা অন্যান্য অ-HTTP- র সেবা ব্যবহার করতে চায়) যে ক্ষেত্রে, সনাক্তকরণ ঘটে না , তাই আপনার উদ্বেগ এড়ানো হয় SSL / TLS করে।

আরএফসি 6585 সেকশন 6 একটি নতুন এইচটিটিপি স্থিতি কোড প্রস্তাব করেছে 511 Network Authentication Requiredযা আপনার এসএসএল / টিএলএস ক্ষেত্রে সহায়তা করে না তবে আপনি যদি ইতিমধ্যে এটি ব্যবহার না করেন তবে আপনি বিবেচনা করতে পারেন এমন আরও একটি মান।


ক্যাপটিভ পোর্টাল সনাক্ত করার জন্য অ্যান্ড্রয়েডেরও সমর্থন রয়েছে। যখন এটি একটি বন্দী পোর্টাল সনাক্ত করে এটি স্থিতি বারে একটি বার্তা প্রদর্শন করে। শব্দবন্ধটি "ওয়্যারলেস নেটওয়ার্কে সাইন ইন" এর মতো কিছু। কোনও অ্যাপ্লিকেশন এখনও সংযোগটি ব্যবহার করার চেষ্টা না করে থাকলেও এটি ঘটে। কিছু সময়ে আমি একটি বন্দী পোর্টাল একটি অতিরিক্ত এইচটিটিপি শিরোনাম সহ 30x পুনর্নির্দেশ প্রেরণ করেও লক্ষ্য করেছি, এটি ইঙ্গিত করে যে এটি বন্দি পোর্টাল ছিল এবং শরীরে কিছু এক্সএমএল ডেটা রয়েছে। আমি জানি না যে এটি কিছু স্ট্যান্ডার্ড আচরণ কিনা।
ক্যাস্পারড

0

যে কোনও ক্ষেত্রে, যদি ব্যবহারকারীরা শংসাপত্র পান তবে ত্রুটি কারণ শংসাপত্রটি সাইটের হোস্টনামের সাথে মেলে না ।

আপনার ক্ষেত্রে, এর অর্থ হ'ল আপনি ইউআরএল পরিবর্তন না করেই আপনার পোর্টালে ব্যবহারকারীদের পুনর্নির্দেশ করছেন। ব্যবহারকারীরা তাদের ঠিকানা বারে " http://www.google.com " দেখতে পান তবে স্ক্রিনে আপনার পোর্টাল। এগুলি মেলে না, স্পষ্টতই, এবং শংসাপত্রটিও হয় না।

আপনাকে এটিকে HTTP- তে (HTTPS জাম্প দেওয়ার আগে) আপনার পোর্টাল ঠিকানায় (বা সার্ভারের নাম) পুনর্নির্দেশ করতে হবে, তাদের সেখানে লগ ইন করতে হবে এবং তারপরে তাদের আবার ঠিক উদ্দেশ্যে গন্তব্যে পুনর্নির্দেশ করতে হবে, যা সঠিকভাবে মিলবে।

এটি এইচটিটিপি 3xx কোডগুলি, বিশেষত 303 দিয়ে কীভাবে সম্পাদন করা যায় তার জন্য https://en.wikedia.org/wiki/URL_redirection#HTTP_status_codes_3xx দেখুন ।


বেশিরভাগ ব্যবহারকারী সম্ভবত টাইপ করেন না https://, তবে কোনও সংরক্ষিত বুকমার্ক বা অন্যান্য পিনিং প্রক্রিয়াগুলির ফলে প্রথম অনুরোধটি এইচটিটিপিএস-ভিত্তিক পরিষেবাতে যেতে পারে এবং ফলস্বরূপ ব্যর্থ হতে পারে কারণ পুনর্নির্দেশের জন্য এইচটিটিপি প্রোটোকল স্তর পৌঁছানোর আগে টিএলএস হ্যান্ডশেকিং ব্যর্থ হয়। বুকমার্ক ব্যতীত, এই জাতীয় "পিনিং" এর উদাহরণগুলির মধ্যে একটি ব্রাউজারের অনুসন্ধান বার অন্তর্ভুক্ত থাকে যা পূর্ববর্তী জ্ঞান থাকে যে অনুসন্ধান সরবরাহকারী এইচটিটিপিএসের মাধ্যমে অনুসন্ধানগুলি পছন্দ করে; বা সুরক্ষিত নেটওয়ার্ক পরিষেবাগুলিতে সংযোগকারী একটি মোবাইল অ্যাপ্লিকেশন।
উইলিয়াম দাম

-1

অস্থায়ী সমাধান ব্যবহারকারীদের সংযুক্ত ওয়াইফাই সংকেতের পরে কেবল "HTTP" দিয়ে URL শুরু করার জন্য গাইড।

তবে দুর্ভাগ্যক্রমে, ব্যবহারকারীরা এটি পছন্দ করেন না। তারা বলে "আপনার কাছে ওয়াইফাই পরিষেবাটি কতটা জটিল ছিল"

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.