2026 সালে HTTPS Captive Portals: কেন HSTS এবং ব্রাউজার হার্ডেনিং পুরনো পদ্ধতি ভেঙে দিচ্ছে

এই নির্দেশিকাটি বিস্তারিতভাবে ব্যাখ্যা করে কিভাবে HSTS এবং ব্রাউজারের HTTPS-ফার্স্ট নীতিগুলি 2026 সালে পুরনো HTTP-ইন্টারসেপ্ট Captive Portals ভেঙে দিচ্ছে। এটি নেটওয়ার্ক আর্কিটেক্টদের জন্য CAPPORT API এবং Passpoint (Hotspot 2.0) সহ আধুনিক বিকল্পগুলি বাস্তবায়নের জন্য কার্যকর প্রযুক্তিগত নির্দেশনা প্রদান করে, যা নিরাপদ এবং নির্ভরযোগ্য Guest WiFi অ্যাক্সেস নিশ্চিত করে।

📖 6 মিনিট পাঠ📝 1,495 শব্দ🔧 2 উদাহরণ❓ 3 প্রশ্ন📚 8 মূল শব্দসমূহ

🎧 এই গাইডটি শুনুন

ট্রান্সক্রিপ্ট দেখুন

PODCAST SCRIPT: HTTPS Captive Portals in 2026 — Why HSTS and Browser Hardening Are Breaking the Old Patterns
Runtime target: ~10 minutes | Voice: UK English, senior consultant tone

---

[INTRO — ~60 seconds]

Welcome back. I'm going to cut straight to it today, because if you're running guest WiFi at scale — hotels, retail estates, stadiums, conference centres — you've probably already hit this problem, or you're about to.

The classic captive portal pattern — the one where your network intercepts an HTTP request and redirects the user to a splash page — is breaking. Not gradually. It's breaking hard, and the browser vendors are the ones doing it.

In the next ten minutes, I want to walk you through exactly what's changed, why it's changed, and what your realistic options are in 2026. This isn't theoretical. This is the conversation I'm having with network architects and IT directors every week right now.

Let's get into it.

---

[TECHNICAL DEEP-DIVE — ~5 minutes]

So let's start with the mechanism. The legacy captive portal pattern works like this: a device connects to your open or PSK-protected WiFi network. It tries to load a web page. Your network controller intercepts that HTTP request — port 80 traffic — and issues a 302 redirect to your portal page. The user sees your splash screen, accepts terms, maybe logs in, and then you open the walled garden. Simple. It's worked for twenty-plus years.

The problem is that pattern depends entirely on the device making an unencrypted HTTP request that you can intercept. And browsers are systematically eliminating those requests.

Here's the timeline of what's happened. HSTS — HTTP Strict Transport Security — has been around since RFC 6797 in 2012. The mechanism is straightforward: a site sends a Strict-Transport-Security header, and the browser remembers it. For the duration of the max-age period, the browser will refuse to load that site over plain HTTP. It upgrades the connection to HTTPS automatically. If HTTPS isn't available, the connection fails — hard. No bypass, no redirect, just a certificate error.

Now, HSTS on its own is manageable. The browser only enforces it after the first visit. But then came the HSTS preload list. Chrome maintains a hardcoded list of domains that are HTTPS-only, baked directly into the browser binary. Firefox, Safari, and Edge all consume the same list. As of 2026, that list covers well over 100,000 domains, including essentially every major consumer destination — Google, Facebook, Twitter, banking sites, government portals, the lot.

What that means in practice is this: when your guest device connects to your network and tries to load gmail.com, or bbc.co.uk, or any preloaded domain, the browser doesn't even attempt an HTTP request. It goes straight to HTTPS. Your network controller never sees a plain HTTP request to intercept. The redirect never happens. The user just gets a certificate error, because your portal's self-signed certificate is not trusted for gmail.com. They see NET::ERR_CERT_AUTHORITY_INVALID and they're stuck.

And it's getting worse. In October 2025, Google announced that Chrome 154 — shipping October 2026 — will enable "Always Use Secure Connections" by default for all users on public sites. Chrome 147, which shipped in April 2026, already enabled this for the one-billion-plus users who have Enhanced Safe Browsing turned on. Firefox has been moving in the same direction. Safari has had HTTPS-first behaviour on iOS for some time.

The net effect: by the end of 2026, the majority of your guests' browsers will attempt HTTPS for every navigation, regardless of whether the domain is on the preload list. The HTTP intercept pattern is not just unreliable — it's dead.

Now, there's a secondary problem that compounds this. Even when the OS-level Captive Network Assistant — the CNA — fires up its mini-browser to handle the portal, that mini-browser has its own HSTS enforcement. On iOS, the CNA uses a sandboxed WebKit instance. On Android, it uses a Chrome Custom Tab. Both enforce HSTS. Both will fail to load your portal if you're trying to serve it via a hostname that has an HSTS policy.

The correct technical response here is to serve your portal from a dedicated hostname that has never had an HSTS header and is not on the preload list — something like portal.yourvenue.com — with a valid, CA-signed TLS certificate. That's table stakes now. But even that doesn't fully solve the detection problem, because the device still needs to discover that it's behind a captive portal in the first place.

That's where RFC 8910 and RFC 8908 come in. RFC 8910 defines a DHCP option — option 114 — and an IPv6 Router Advertisement option that tells the client device the URL of the captive portal API endpoint. RFC 8908 defines that API: a simple JSON endpoint that the OS queries to determine whether internet access is restricted, and if so, where the portal is. Modern operating systems — iOS 14 and later, Android 11 and later, Windows 11 — all support this. When you implement CAPPORT correctly, the device knows it's behind a portal before it ever tries to load a web page. The OS fires up the CNA with the correct portal URL directly. No HTTP intercept required.

That's the first modern alternative: DNS and DHCP signalling via CAPPORT, with a properly-signed portal served from a dedicated hostname.

The second alternative is Passpoint, based on IEEE 802.11u and the Wi-Fi Alliance's Hotspot 2.0 specification. Passpoint takes a fundamentally different approach. Instead of intercepting traffic, the access point advertises its identity and authentication requirements via ANQP — Access Network Query Protocol — before the device even associates. The device checks whether it has valid credentials for this network. If it does, it authenticates via 802.1X and WPA2 or WPA3 Enterprise, and gets full network access immediately. No portal, no redirect, no browser involvement at all.

Passpoint is the right answer for a specific set of deployments: multi-site operators, enterprise environments, healthcare, transport hubs, anywhere you have repeat users who benefit from zero-touch connectivity. Purple's SecurePass product line is built around this model, and for the right deployment profile it eliminates the captive portal problem entirely.

The third option, which sits between the two, is OWE — Opportunistic Wireless Encryption. OWE is defined in RFC 8110 and provides per-client encryption on open networks without requiring credentials. It doesn't replace the portal, but it removes the open-network security exposure that makes regulators nervous, particularly under GDPR and PCI DSS.

---

[IMPLEMENTATION RECOMMENDATIONS & PITFALLS — ~2 minutes]

Right, so what should you actually do? Let me give you the practical framework.

If you're running a captive portal today and it's working, your immediate priority is to implement CAPPORT. That means configuring DHCP option 114 on your controller to point to your portal API endpoint, implementing the RFC 8908 JSON API on your portal server, and ensuring your portal is served from a dedicated hostname with a valid CA-signed certificate. This will restore reliable portal detection on modern devices and eliminate the certificate error problem.

Do not — I repeat, do not — attempt to serve your portal from a hostname that appears on the HSTS preload list. And do not use a self-signed certificate. Both of these are instant failure modes.

The second thing to address is your walled garden configuration. Your DHCP server, your DNS resolver, and your portal hostname all need to be accessible before authentication. That includes the OS detection probe URLs: captive.apple.com for Apple devices, connectivitycheck.gstatic.com for Android, and msftconnecttest.com for Windows. If any of these are blocked pre-auth, the CNA won't fire and your users will be stuck.

For new deployments, particularly in hospitality and multi-site retail, I'd strongly recommend evaluating a hybrid architecture: a Passpoint SSID for repeat visitors and a CAPPORT-compliant portal SSID for first-time guests, with the portal offering Passpoint profile installation as part of the onboarding flow. This gives you the marketing touchpoint for new visitors while delivering zero-friction connectivity for returning ones.

The pitfall I see most often is operators who've invested in portal customisation and data collection treating Passpoint as a threat to their marketing stack. It isn't. Purple's platform, for example, supports progressive onboarding where the initial portal interaction captures consent and profile data, and then provisions a Passpoint credential for future visits. You get the first-party data on the first visit and the seamless experience on every subsequent one.

---

[RAPID-FIRE Q&A — ~1 minute]

Quick-fire questions I get asked constantly:

"Can I just use a self-signed cert for my portal?" No. Modern browsers and CNA implementations will reject it. You need a CA-signed certificate.

"Does CAPPORT work on all devices?" iOS 14+, Android 11+, Windows 11 — yes. Older devices fall back to legacy detection behaviour. Plan for both.

"Is Passpoint GDPR-compliant?" Yes, when implemented correctly. The credential provisioning step is where you capture consent. Purple handles this as part of the SecurePass onboarding flow.

"What about PCI DSS scope?" If your guest network carries any cardholder data, you need network segmentation regardless of portal type. Passpoint's WPA3-Enterprise encryption significantly reduces your attack surface and simplifies scope arguments with QSAs.

---

[SUMMARY & NEXT STEPS — ~1 minute]

To wrap up: the HTTP intercept pattern is broken by HSTS preloading and Chrome's move to HTTPS-first by default. The fix for existing deployments is CAPPORT — RFC 8910 plus RFC 8908 — with a properly-signed portal on a dedicated hostname. For new deployments or major refreshes, evaluate Passpoint, particularly if you have repeat-visitor traffic or compliance requirements that benefit from WPA3-Enterprise encryption.

The browser vendors have made their position clear. The question isn't whether to adapt — it's how fast.

If you want to dig into the specifics for your deployment, the Purple team can walk you through a CAPPORT readiness assessment and a Passpoint feasibility analysis. Links in the show notes.

Thanks for listening. See you next time.

---
END OF SCRIPT

মূল বিষয়সমূহ

✓Legacy HTTP intercept captive portals are fundamentally broken by HSTS preloading and browser HTTPS-first policies.
✓Chrome 154 (October 2026) enforces HTTPS-first by default, eliminating unencrypted port 80 traffic for portal detection.
✓Network architects must immediately implement the CAPPORT API (RFC 8908/8910) to restore reliable OS-level portal detection.
✓Portals must be hosted on dedicated hostnames with valid CA-signed certificates; self-signed certs and preloaded domains will fail.
✓Passpoint (Hotspot 2.0) is the definitive replacement for portals in enterprise and multi-site environments, offering WPA3 security and zero-touch roaming.
✓A hybrid approach—using CAPPORT for initial data capture and provisioning a Passpoint profile for return visits—balances marketing needs with seamless UX.
✓Proper walled garden configuration, including allowlisting OS probe URLs, is critical for the Captive Network Assistant (CNA) to function.

নির্বাহী সারসংক্ষেপ

পুরনো Captive Portal পদ্ধতি—HTTP ট্র্যাফিক ইন্টারসেপ্ট করা এবং একটি 302 রিডাইরেক্ট জারি করা—এখন অচল। HTTP Strict Transport Security (HSTS) এবং আক্রমণাত্মক ব্রাউজার হার্ডেনিং দ্বারা চালিত, ঐতিহ্যবাহী 'ইন্টারসেপ্ট এবং রিডাইরেক্ট' প্রক্রিয়াটি Hospitality , Retail , এবং এন্টারপ্রাইজ পরিবেশ জুড়ে বড় আকারে ব্যর্থ হচ্ছে। 2026 সাল নাগাদ, Chrome ডিফল্টরূপে HTTPS-ফার্স্ট আচরণ প্রয়োগ করায় এবং HSTS প্রিলোড তালিকা 100,000 ডোমেন ছাড়িয়ে যাওয়ায়, নেটওয়ার্ক কন্ট্রোলাররা আর পোর্টাল সনাক্তকরণের জন্য এনক্রিপ্টবিহীন HTTP অনুরোধের উপর নির্ভর করতে পারে না।

IT ম্যানেজার এবং নেটওয়ার্ক আর্কিটেক্টদের জন্য, এটি একটি গুরুত্বপূর্ণ স্থাপত্যগত পরিবর্তন। নির্বিঘ্ন Guest WiFi অ্যাক্সেস বজায় রাখার জন্য এখন আপনার অনবোর্ডিং ফ্লোকে আধুনিকীকরণ করা প্রয়োজন। এই নির্দেশিকাটি পুরনো পোর্টালগুলি ভেঙে দেওয়া প্রযুক্তিগত প্রক্রিয়াগুলি বিস্তারিতভাবে ব্যাখ্যা করে এবং বিক্রেতা-নিরপেক্ষ বাস্তবায়নের পথরেখা তুলে ধরে: তাৎক্ষণিক স্থিতিশীলতার জন্য CAPPORT API (RFC 8908/8910) স্থাপন করা, এবং নিরাপদ, জিরো-টাচ সংযোগের জন্য Passpoint (Hotspot 2.0) এবং OpenRoaming-এ স্থানান্তরিত হওয়া।

প্রযুক্তিগত গভীর বিশ্লেষণ: কেন HSTS ইন্টারসেপ্ট প্যাটার্ন ভেঙে দেয়

ঐতিহ্যবাহী Captive Portal একটি মৌলিক অনুমানের উপর নির্ভর করে: ক্লায়েন্ট ডিভাইস পোর্ট 80-এ একটি এনক্রিপ্টবিহীন HTTP অনুরোধ করবে যা নেটওয়ার্ক অ্যাক্সেস সার্ভার (NAS) বা কন্ট্রোলার ইন্টারসেপ্ট করে পোর্টালের স্প্ল্যাশ পৃষ্ঠায় রিডাইরেক্ট করতে পারে।

এই অনুমান আর বৈধ নয়।

HSTS প্রিলোড সমস্যা

RFC 6797-এ সংজ্ঞায়িত HTTP Strict Transport Security (HSTS), একটি ওয়েব সার্ভারকে ঘোষণা করার অনুমতি দেয় যে ওয়েব ব্রাউজারগুলি শুধুমাত্র সুরক্ষিত HTTPS সংযোগ ব্যবহার করে এর সাথে ইন্টারঅ্যাক্ট করবে। যখন একজন ব্যবহারকারী HTTP এর মাধ্যমে একটি HSTS-সুরক্ষিত ডোমেন অ্যাক্সেস করার চেষ্টা করে, তখন ব্রাউজার অভ্যন্তরীণভাবে অনুরোধটিকে HTTPS-এ আপগ্রেড করে কোনো নেটওয়ার্ক ট্র্যাফিক পাঠানোর আগেই।

যেহেতু অনুরোধটি এনক্রিপ্ট করা হয়, তাই নেটওয়ার্ক কন্ট্রোলার হোস্ট হেডার পরিদর্শন করতে বা একটি HTTP 302 রিডাইরেক্ট জারি করতে পারে না। পরিবর্তে, কন্ট্রোলার HTTPS ট্র্যাফিক ইন্টারসেপ্ট করে এবং তার নিজস্ব পোর্টাল সার্টিফিকেট উপস্থাপন করে। যেহেতু এই সার্টিফিকেট অনুরোধ করা ডোমেনের (যেমন, google.com) সাথে মেলে না, তাই ব্রাউজার একটি মারাত্মক NET::ERR_CERT_AUTHORITY_INVALID ত্রুটি দেখায়। ব্যবহারকারী অবরুদ্ধ হয়, এবং পোর্টাল কখনও লোড হয় না।

HSTS প্রিলোড তালিকা এই সমস্যাকে আরও বাড়িয়ে তোলে। ব্রাউজারগুলি এমন ডোমেনগুলির একটি তালিকা হার্ডকোড করে যা সর্বদা HTTPS এর মাধ্যমে অ্যাক্সেস করতে হবে, এমনকি প্রথম ভিজিটেও। 2026 সালে, এই তালিকায় কার্যত সমস্ত প্রধান ভোক্তা গন্তব্য অন্তর্ভুক্ত। যখন একজন অতিথি আপনার নেটওয়ার্কে সংযুক্ত হয় এবং একটি সাধারণ URL টাইপ করে, তখন ব্রাউজার HTTPS প্রয়োগ করে, যার ফলে সার্টিফিকেট ত্রুটি দেখা যায় এবং Captive Portal ফ্লো ভেঙে যায়।

ব্রাউজার হার্ডেনিং: HTTPS-ফার্স্ট মোড

HSTS ছাড়াও, ব্রাউজার বিক্রেতারা পদ্ধতিগতভাবে তাদের ডিফল্ট আচরণগুলিকে কঠোর করেছে। 2025 সালের শেষের দিকে, Google ঘোষণা করেছে যে Chrome 154 (অক্টোবর 2026-এ প্রকাশিত) পাবলিক সাইটগুলিতে সমস্ত ব্যবহারকারীর জন্য ডিফল্টরূপে "Always Use Secure Connections" সক্ষম করবে। Safari এবং Firefox একই ধরনের HTTPS-ফার্স্ট মোড বাস্তবায়ন করেছে।

এর মানে হল যে HSTS প্রিলোড তালিকায় না থাকা ডোমেনগুলির জন্যও, ব্রাউজার প্রথমে একটি HTTPS সংযোগের চেষ্টা করবে। HTTP ইন্টারসেপ্ট প্যাটার্ন কার্যকরভাবে অপ্রচলিত।

আধুনিক বিকল্প: CAPPORT এবং Passpoint

কার্যকারিতা পুনরুদ্ধার করতে এবং ব্যবহারকারীর অভিজ্ঞতা উন্নত করতে, নেটওয়ার্ক আর্কিটেক্টদের আধুনিক Captive Portal সনাক্তকরণ প্রক্রিয়া এবং প্রমাণীকরণ কাঠামোতে স্থানান্তরিত হতে হবে।

1. CAPPORT API (RFC 8908 এবং RFC 8910)

ইন্টারনেট ইঞ্জিনিয়ারিং টাস্ক ফোর্স (IETF) CAPPORT আর্কিটেকচারের মাধ্যমে Captive Portal সনাক্তকরণ সমস্যার সমাধান করেছে। ইন্টারসেপ্ট করা ওয়েব ট্র্যাফিকের উপর নির্ভর না করে, CAPPORT একটি সুস্পষ্ট সিগন্যালিং প্রক্রিয়া প্রদান করে।

RFC 8910 (Captive-Portal Identification): নেটওয়ার্ক DHCP (Option 114) বা IPv6 Router Advertisements ব্যবহার করে ক্লায়েন্ট ডিভাইসকে Captive Portal API এর URI প্রদান করে।
RFC 8908 (Captive Portal API): ক্লায়েন্ট প্রদত্ত URI (একটি JSON এন্ডপয়েন্ট) কোয়েরি করে এটি Captive কিনা তা নির্ধারণ করতে এবং ব্যবহারকারী-মুখী পোর্টাল পৃষ্ঠার URL পেতে।

বাস্তবায়িত হলে, ক্লায়েন্ট OS (iOS, Android, Windows) ব্যবহারকারী একটি ব্রাউজার খোলার আগেই পোর্টালটিকে নেটিভভাবে সনাক্ত করে। OS তার Captive Network Assistant (CNA) চালু করে এবং একটি সুরক্ষিত HTTPS সংযোগের মাধ্যমে সরাসরি পোর্টাল URL লোড করে। এটি HTTP ইন্টারসেপশনের প্রয়োজনীয়তা দূর করে এবং সার্টিফিকেট ত্রুটি এড়ায়।

2. Passpoint (Hotspot 2.0) এবং OpenRoaming

পুনরাবৃত্ত দর্শক বা উচ্চ নিরাপত্তা প্রয়োজনীয়তা সহ পরিবেশের জন্য, Passpoint (IEEE 802.11u এর উপর ভিত্তি করে) Captive Portal এর চূড়ান্ত প্রতিস্থাপন।

Passpoint MAC স্তরে কাজ করে। Access Point (AP) এর সাথে যুক্ত হওয়ার আগে, ক্লায়েন্ট ডিভাইস Access Network Query Protocol (ANQP) ব্যবহার করে নেটওয়ার্কের ক্ষমতা এবং রোমিং কনসোর্টিয়ামগুলি আবিষ্কার করে। যদি ডিভাইসটি একটি ম্যাচিং ক্রেডেনশিয়াল ধারণ করে (যেমন, পূর্ববর্তী ভিজিট চলাকালীন বা একটি পরিচয় প্রদানকারীর মাধ্যমে ইনস্টল করা একটি প্রোফাইল), তবে এটি স্বয়ংক্রিয়ভাবে 802.1X এবং WPA2/WPA3-Enterprise ব্যবহার করে প্রমাণীকরণ করে।

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

বাস্তবায়ন নির্দেশিকা

একটি স্থিতিস্থাপক অতিথি অ্যাক্সেস আর্কিটেকচার স্থাপন করতে একটি পর্যায়ক্রমিক পদ্ধতির প্রয়োজন, যা তাৎক্ষণিক প্রতিকার থেকে কৌশলগত রূপান্তরের দিকে এগিয়ে যায়।

পর্যায় 1: CAPPORT দিয়ে বিদ্যমান পোর্টালগুলিকে স্থিতিশীল করুন

যদি আপনাকে ডেটা ক্যাপচার বা WiFi Analytics এর জন্য একটি ঐতিহ্যবাহী captive portal বজায় রাখতে হয়, তাহলে HSTS ভাঙ্গন এড়াতে আপনাকে CAPPORT বাস্তবায়ন করতে হবে।

DHCP Option 114 কনফিগার করুন: আপনার DHCP সার্ভার বা নেটওয়ার্ক কন্ট্রোলার আপডেট করুন যাতে Option 114 সম্প্রচারিত হয়, যা আপনার পোর্টালের API এন্ডপয়েন্টের দিকে নির্দেশ করে (যেমন, https://portal.yourvenue.com/capport)।
RFC 8908 API বাস্তবায়ন করুন: নিশ্চিত করুন যে আপনার পোর্টাল সার্ভার API অনুরোধে বৈধ JSON দিয়ে সাড়া দেয় যা captive অবস্থা এবং ব্যবহারকারী-মুখী URL নির্দেশ করে।
একটি ডেডিকেটেড, বৈধ হোস্টনেম ব্যবহার করুন: পোর্টালটি একটি বৈধ, CA-signed সার্টিফিকেট ব্যবহার করে HTTPS এর মাধ্যমে পরিবেশিত হতে হবে। কখনোই একটি স্ব-স্বাক্ষরিত সার্টিফিকেট বা HSTS প্রিলোড তালিকায় থাকা একটি হোস্টনেম ব্যবহার করবেন না।
OS প্রোবগুলিকে Allowlist করুন: নিশ্চিত করুন যে OS-স্তরের captive portal সনাক্তকরণ প্রোবগুলি (যেমন, captive.apple.com, connectivitycheck.gstatic.com) walled garden প্রি-অথেন্টিকেশনের মাধ্যমে অনুমোদিত।

পর্যায় 2: সুরক্ষিত, নির্বিঘ্ন অ্যাক্সেসের জন্য Passpoint স্থাপন করুন

Passpoint-এ রূপান্তর নিরাপত্তা এবং ব্যবহারকারীর অভিজ্ঞতাকে উল্লেখযোগ্যভাবে উন্নত করে, বিশেষ করে Healthcare এবং Transport স্থাপনায়।

অবকাঠামো সমর্থন যাচাই করুন: নিশ্চিত করুন যে আপনার APs এবং কন্ট্রোলারগুলি Hotspot 2.0/Passpoint এবং 802.1X প্রমাণীকরণ সমর্থন করে।
ANQP প্রোফাইল কনফিগার করুন: আপনার নেটওয়ার্ক কন্ট্রোলারে ভেন্যু নাম, রোমিং কনসোর্টিয়াম OIs এবং NAI রিয়েলমগুলি সংজ্ঞায়িত করুন।
একটি RADIUS/AAA ব্যাকএন্ড স্থাপন করুন: EAP প্রমাণীকরণ (যেমন, EAP-TLS, EAP-TTLS) পরিচালনা করতে সক্ষম একটি RADIUS সার্ভার বাস্তবায়ন করুন।
প্রোফাইল প্রভিশনিং বাস্তবায়ন করুন: একটি অনলাইন সাইন-আপ (OSU) সার্ভার ব্যবহার করুন বা ব্যবহারকারীর ডিভাইসে Passpoint প্রোফাইল প্রভিশন করতে Purple SecurePass এর মতো একটি প্ল্যাটফর্মের সাথে একত্রিত করুন।

পর্যায় 3: হাইব্রিড প্রগ্রেসিভ অনবোর্ডিং মডেল

যেসব ভেন্যুতে নির্বিঘ্ন অ্যাক্সেস এবং প্রাথমিক ডেটা ক্যাপচার উভয়ই প্রয়োজন (যেমন, আনুগত্য বাড়াতে চাওয়া খুচরা পরিবেশ), তাদের জন্য একটি হাইব্রিড পদ্ধতি সর্বোত্তম।

প্রথম ভিজিট: ব্যবহারকারী একটি খোলা SSID এর সাথে সংযুক্ত হন এবং একটি CAPPORT-সক্ষম captive portal এ নির্দেশিত হন। পোর্টালটি প্রয়োজনীয় ডেটা (যেমন, ইমেল, শর্তাবলী গ্রহণ) ক্যাপচার করে এবং ডিভাইসে একটি Passpoint প্রোফাইল প্রভিশন করে।
পরবর্তী ভিজিট: ব্যবহারকারীর ডিভাইস স্বয়ংক্রিয়ভাবে ANQP এর মাধ্যমে Passpoint নেটওয়ার্ক সনাক্ত করে এবং 802.1X ব্যবহার করে নির্বিঘ্নে প্রমাণীকরণ করে। captive portal সম্পূর্ণরূপে বাইপাস করা হয়।

সর্বোত্তম অনুশীলন

'Frictionless' মার্কেটিং কথা এড়িয়ে চলুন: প্রযুক্তিগত বাস্তবতার উপর মনোযোগ দিন। দীর্ঘমেয়াদী নির্বিঘ্নতা অর্জনের জন্য Passpoint এর প্রাথমিক প্রভিশনিং ঘর্ষণ প্রয়োজন।
অতিথি ট্র্যাফিককে বিভক্ত করুন: প্রমাণীকরণ পদ্ধতি নির্বিশেষে, অতিথি ট্র্যাফিককে VLANs এবং ফায়ারওয়াল ব্যবহার করে কর্পোরেট নেটওয়ার্ক থেকে যৌক্তিকভাবে আলাদা করতে হবে, যা Internet of Things Architecture: A Complete Guide এর সাথে সামঞ্জস্যপূর্ণ।
সার্টিফিকেট মেয়াদোত্তীর্ণতা নিরীক্ষণ করুন: আপনার পোর্টাল বা RADIUS সার্ভারে একটি মেয়াদোত্তীর্ণ TLS সার্টিফিকেট বিপর্যয়কর প্রমাণীকরণ ব্যর্থতার কারণ হবে। স্বয়ংক্রিয় নবায়ন এবং নিরীক্ষণ বাস্তবায়ন করুন।
ডেটা গোপনীয়তা প্রবিধান মেনে চলুন: নিশ্চিত করুন যে আপনার ডেটা ক্যাপচার এবং ধারণ নীতি স্থানীয় আইনের সাথে সঙ্গতিপূর্ণ। নির্দিষ্ট আঞ্চলিক নির্দেশনার জন্য, Brazil LGPD and Guest WiFi: A Compliance Guide এর মতো সংস্থানগুলি দেখুন।

সমস্যা সমাধান ও ঝুঁকি প্রশমন

লক্ষণ: iOS ডিভাইসগুলি একটি ফাঁকা CNA স্ক্রিন দেখায়।
- কারণ: পোর্টাল পৃষ্ঠায় বাহ্যিক ডোমেনে হোস্ট করা সংস্থান (ছবি, স্ক্রিপ্ট) রয়েছে যা walled garden দ্বারা অবরুদ্ধ।
- সমাধান: সমস্ত প্রয়োজনীয় পোর্টাল সম্পদ স্থানীয়ভাবে হোস্ট করুন অথবা প্রয়োজনীয় বাহ্যিক ডোমেনগুলিকে প্রি-অথ allowlist এ যোগ করুন।
লক্ষণ: Android ডিভাইসগুলি পোর্টালের পরিবর্তে একটি সার্টিফিকেট সতর্কতা প্রদর্শন করে।
- কারণ: কন্ট্রোলার একটি প্রিলোডেড HSTS ডোমেনে HTTPS ট্র্যাফিক ইন্টারসেপ্ট করছে, অথবা পোর্টালের TLS সার্টিফিকেট অবৈধ/স্ব-স্বাক্ষরিত।
- সমাধান: CAPPORT বাস্তবায়ন করুন এবং নিশ্চিত করুন যে পোর্টালটি একটি ডেডিকেটেড হোস্টনেমে একটি CA-signed সার্টিফিকেট ব্যবহার করে।
লক্ষণ: Windows 11 এ Passpoint প্রোফাইল ইনস্টলেশন ব্যর্থ হয়।
- কারণ: প্রভিশনিং সার্ভারের সার্টিফিকেট চেইন অসম্পূর্ণ বা OS দ্বারা অবিশ্বস্ত।
- সমাধান: যাচাই করুন যে সম্পূর্ণ সার্টিফিকেট চেইন (মধ্যবর্তী CAs সহ) TLS হ্যান্ডশেকের সময় পরিবেশিত হয়।

ROI এবং ব্যবসায়িক প্রভাব

ঐতিহ্যবাহী HTTP ইন্টারসেপ্ট পোর্টাল থেকে আধুনিক CAPPORT এবং Passpoint আর্কিটেকচারে রূপান্তর পরিমাপযোগ্য ব্যবসায়িক মূল্য প্রদান করে:

হ্রাসকৃত সাপোর্ট টিকিট: HSTS-সম্পর্কিত সার্টিফিকেট ত্রুটিগুলি দূর করা অতিথি সংযোগ সমস্যা সম্পর্কিত IT হেল্পডেস্কের পরিমাণ সরাসরি হ্রাস করে।
বর্ধিত সংযোগ হার: নির্ভরযোগ্য OS-স্তরের পোর্টাল সনাক্তকরণ নিশ্চিত করে যে আরও বেশি অতিথি সফলভাবে অনবোর্ডিং ফ্লো সম্পন্ন করে, যা বিপণন উদ্যোগের জন্য আপনার পৌঁছানোর যোগ্য শ্রোতাদের প্রসারিত করে।
উন্নত নিরাপত্তা অবস্থান: Passpoint এবং WPA3-Enterprise এ স্থানান্তরিত হওয়া উন্মুক্ত নেটওয়ার্কগুলির সাথে সম্পর্কিত ঝুঁকিগুলি হ্রাস করে, যা আড়ি পাতা এবং evil twin আক্রমণ থেকে রক্ষা করে, যা অর্থ ও স্বাস্থ্যসেবার মতো ক্ষেত্রগুলিতে সম্মতির জন্য অত্যন্ত গুরুত্বপূর্ণ।
উন্নত ব্যবহারকারীর অভিজ্ঞতা: Passpoint এর মাধ্যমে জিরো-টাচ রোমিং উচ্চতর ব্যবহারকারীর সন্তুষ্টি এবং পুনরাবৃত্ত ব্যস্ততা বাড়ায়, যা Indoor Positioning System: UWB, BLE, & WiFi Guide এবং Your Guide to Enterprise In Car Wi Fi Solutions এর মতো বৃহত্তর ডিজিটাল উদ্যোগগুলিকে সমর্থন করে।

মূল শব্দ ও সংজ্ঞা

HSTS (HTTP Strict Transport Security)

A web security policy mechanism that forces web browsers to interact with domains only via secure HTTPS connections, preventing protocol downgrade attacks and HTTP interception.

When IT teams see an increase in certificate errors on guest networks, HSTS enforcement on popular domains is typically the root cause, breaking legacy redirect mechanisms.

HSTS Preload List

A hardcoded list built into modern web browsers containing domains that must always be accessed via HTTPS, even on the very first visit.

If a user attempts to navigate to a preloaded domain (like google.com) while behind a legacy captive portal, the browser will refuse the HTTP connection, preventing the portal redirect.

CAPPORT (Captive Portal Architecture)

An IETF standard (RFC 8908 and 8910) that uses DHCP or IPv6 Router Advertisements to explicitly signal the presence and URL of a captive portal to a client device.

Implementing CAPPORT is the primary remediation strategy for network architects to fix broken portal detection on modern iOS, Android, and Windows devices.

Passpoint (Hotspot 2.0)

A Wi-Fi Alliance specification based on IEEE 802.11u that enables devices to automatically discover and securely authenticate to Wi-Fi networks without user intervention.

Used in enterprise and multi-site deployments to replace captive portals entirely, providing cellular-like roaming and WPA3-Enterprise security.

ANQP (Access Network Query Protocol)

A layer 2 protocol used by client devices to query Access Points for network information (like roaming partners and supported authentication types) before associating.

ANQP is the discovery mechanism that allows a Passpoint-enabled device to determine if it has the correct credentials to join a specific network silently.

CNA (Captive Network Assistant)

The OS-level pseudo-browser that automatically opens when a device detects it is behind a captive portal, allowing the user to authenticate before gaining full internet access.

IT teams must ensure their walled garden allows access to the OS-specific probe URLs (e.g., captive.apple.com) so the CNA triggers correctly.

OpenRoaming

A global Wi-Fi roaming federation that allows users to connect automatically and securely across different venues using a single set of credentials provided by an identity provider.

Venues adopt OpenRoaming to provide seamless access for guests, leveraging identity providers like Purple to manage authentication without complex bilateral agreements.

Walled Garden

A restricted network environment where unauthenticated users can only access a specific set of pre-approved IP addresses or domains necessary for the login process.

Misconfigured walled gardens that block OS detection probes or external portal assets are a leading cause of blank screens and failed guest onboarding.

কেস স্টাডিজ

A 400-room enterprise hotel is experiencing a 30% drop in successful guest WiFi connections. Users report seeing 'Your connection is not private' (NET::ERR_CERT_AUTHORITY_INVALID) errors on their smartphones when trying to access the network. The hotel currently uses a legacy open SSID that intercepts port 80 traffic to redirect to a branded splash page.

The IT team must immediately implement the CAPPORT API (RFC 8908/8910). First, configure the network controller's DHCP server to broadcast Option 114, providing the URI of the captive portal API. Second, deploy the RFC 8908 JSON endpoint on the portal server. Third, ensure the portal is hosted on a dedicated subdomain (e.g., wifi.hoteldomain.com) with a valid, CA-signed TLS certificate. Finally, verify that OS detection URLs (like captive.apple.com) are allowed pre-authentication.

বাস্তবায়ন সংক্রান্ত নোট: This approach directly addresses the HSTS breakage by utilizing out-of-band signalling (DHCP) to inform the OS of the portal's location, rather than relying on intercepting encrypted web traffic. It restores the native Captive Network Assistant (CNA) experience without triggering browser certificate warnings.

A large retail chain with 500 locations wants to implement seamless WiFi roaming for their loyalty app users, eliminating the need for customers to interact with a captive portal on every visit, while still maintaining high security standards (WPA3).

The architect should deploy a Passpoint (Hotspot 2.0) architecture. The initial onboarding can occur via the retailer's loyalty app, which provisions a Passpoint profile (credential) to the user's device. The APs across all 500 locations must be configured to broadcast the appropriate ANQP roaming consortium OIs. A centralized RADIUS infrastructure will handle the 802.1X EAP authentication when the device automatically associates with the network.

বাস্তবায়ন সংক্রান্ত নোট: Passpoint is the correct solution for multi-site roaming and high security. By moving authentication to the MAC layer (802.1X) and utilizing WPA3-Enterprise, the network avoids the vulnerabilities of open SSIDs and the UX friction of repeated captive portal logins.

দৃশ্যপট বিশ্লেষণ

Q1. Your organisation is deploying a new guest WiFi network across 50 regional offices. Security policy mandates that all wireless traffic must be encrypted over the air, but the marketing team insists on capturing user email addresses upon first connection. Which architecture should you propose?

💡 ইঙ্গিত:Consider how to balance the requirement for initial data capture with the mandate for over-the-air encryption.

প্রস্তাবিত পদ্ধতি দেখুন

Propose a hybrid progressive onboarding architecture. First-time users connect to an open SSID and are directed to a CAPPORT-enabled captive portal to provide their email address. Upon submission, the portal provisions a Passpoint profile to the device. The device then automatically transitions to a secure, WPA3-Enterprise encrypted Passpoint SSID for all subsequent traffic and future visits. This satisfies marketing's data capture requirement while enforcing security policy for the vast majority of network usage.

Q2. A client complains that their newly designed, highly customized captive portal page is displaying a blank white screen on all modern iOS devices, although it works perfectly on older Android phones. The portal relies heavily on external web fonts and a third-party analytics script.

💡 ইঙ্গিত:Think about how the iOS Captive Network Assistant (CNA) interacts with external resources before the device is fully authenticated.

প্রস্তাবিত পদ্ধতি দেখুন

The issue is a misconfigured walled garden. The iOS CNA is attempting to render the portal page, but the external domains hosting the web fonts and analytics scripts are blocked by the network controller pre-authentication. Because these resources cannot load, the CNA stalls and displays a blank screen. The solution is to either host all required assets locally on the portal server or add the specific external domains (FQDNs) to the controller's pre-authentication allowlist.

Q3. During a network audit, you discover that the legacy captive portal is intercepting traffic and serving a self-signed certificate. You are tasked with upgrading the system to use the CAPPORT API. What specific certificate requirements must be met for the new portal server?

💡 ইঙ্গিত:Consider how modern browsers and OS CNAs handle certificate validation during the captive portal detection phase.

প্রস্তাবিত পদ্ধতি দেখুন

The new portal server must be accessed via a dedicated Fully Qualified Domain Name (FQDN) that is NOT on the HSTS preload list. Furthermore, it must use a valid TLS certificate issued by a publicly trusted Certificate Authority (CA). Self-signed certificates will be rejected by the OS CNA and modern browsers, preventing the portal from loading and halting the onboarding process.