They don't! Isn't that amazing?

The only use I know for captive portals is EULAs, and I'm not sure those ever had legal weight (though obviously IANAL).

But honestly they were starting to be outdated (technologically) even before this. Since a lot of popular sites use HTTPS, I usually have to try and think of a non-HTTP site before I can get through. They're just a nuisance at this point.

This is not to defend Google's actions as "altruistic" in any way. But sometimes Google's interests and the public's do align.

> I usually have to try and think of a non-HTTP site before I can get through.

http://neverssl.com/ is built for that problem; it's what I use

I just use http://example.com for those

>The only use I know for captive portals is EULAs

What? You use them to log in with some criteria more than just a username/password. For example CableWifi hotspots that let you log in with TWC, Optimum, or others.

Wifi has supported that kind of login for ages (15 years?) at the protocol level, without fucking with the traffic in a MITM fashion. OS support was there already for XP and iOS 2.0.

https://en.m.wikipedia.org/wiki/IEEE_802.1X

except there is no provisions for UI indications whatsoever, not even what login you should be using, or what you are logging into, or why.

Every hotel room in which I've stayed has a placard on the table with the BSSID name, userID and password for the portal login.

It would be identical with 802.1X. The only difference in the UI flow is that the authentication prompt is generated by the OS, not on some HTTP page that I only remember about when I wonder why my VPN isn't coming-up.

So why don't captive portals at e.g. cafés use 802.1X? Are they just stupid and don't know it exists, or is it really user unfriendly in that setting?

> log in with some criteria more than just a username/password

The problem there is that captive portals don't add any extra link-layer security. The network is open, so literally anyone can sniff packets.

It's uncommon, but a network using WPA2-Enterprise and user/pass uses different keys for each person (not sure if per device or per user), so you don't have to trust everyone in the room.

Most portals I use intercept your request to a HTTP site and redirect you to their logic form which is served over HTTPS.

Yes, but after authentication, all traffic can be sniffed - including unencrypted connections.

How is this different from the case without a captive portal, again?

Using WPA-Enterprise, each connection is encrypted separately, eliminating that hole.

Now you don’t have to trust the other customers, only the bar you’re at, their ISP and a million other parties between you and the site you’re visiting.

That's a reasonable point, but I'm speaking from the perspective of the bar owner - I feel I have a duty to provide better security even if the patrons have no reason to trust me.

Like a bar is going to run account administration.. at most they’re going to set a proper password with WPA2-PSK which provides protection against outsiders. But it can’t provide protection against an active attacker that has the password.

You could have a wifi access product that used a voucher system. The code could be on the bar receipt.

They're probably also not putting up a captive portal, so what's your point?

Using WPA-Enterprise, as I understand it, requires devices to be preconfigured to authenticate with the radius server, which makes it a non-starter for the kinds of networks that use a captive portal.

No, there's no preconfiguration needed, it's just a username/password account. You choose the network, then the OS asks you for your user/pass, then you're connected.

It's the router that connects to the RADIUS server, not the device directly. And some routers have one embedded, so you don't even need to configure that, it "just works".

Wouldn't it be nice if there was an encryption mode for Wifi that ensures integrity without requiring authentication? At CCC events, the workaround is to have a WPA2-Enterprise network that accepts every username/password combination, but that's going to be hard to explain to non-technical users.

I think WPA3 is going to support this use case.

Companies can easily adapt by changing your username to the form of an email (e.g. "[email protected]"). Many of those already offer email addresses anyway.

How do you communicate "log in with an email address" to a user if you can't display a web page?

No, I mean the only username given by Optimum et all would be the email address.

They are in fact legally required in many jurisdictions.

How do you implement them properly when the user has to agree to certain terms to connect?

What if this isn’t possible? The world implodes? Or suddenly the lawyers discover it isn’t that ‘required’ anyway?

Then your country will look like Germany did until a few years ago, with no WiFi hotspots anywhere, not even in Starbucks, and people being careful not to open their WiFi to guests at a party even.

That's what has happened before, that's what's just going to happen again. In Germany, the owner of a WiFi hotspot was liable for anything users on the WiFi did, unless the owner could prove that every user had signed an agreement that they would not do illegal stuff

>they were starting to be outdated (technologically) even before this

So what is the proper technology today for limited guest Wi-Fi access?

If it's unauthenticated, the portal doesn't give you any advantage beyond showing a message.

If it's authenticated, you should be using WPA-Enterprise anyway, which supports different logins, and actually isolates the traffic between clients, whereas those "portals" don't, allowing any other user to sniff your traffic.

It's surely authenticated, but I don't want guests to use WPA-Enterprise. I just need a way to communicate temporary passwords to them.

Right, and WPA-Enterprise (which even many cheap home routers support nowadays) is that way - you can just generate temporary logins.

WPA-Enterprise is a way to authenticate users, not a way to distribute logins/passwords. Am I missing something about it?

I guess I misunderstood you before. You're using the portal to provide passwords to the users? How does that work?

Portal shows a message like "here's your temporary login/password for 4 hours". Then a user enters them to the login form. When using WPA-Enterprise, a user can also set up WPA on their device with these credentials.

If the portal provides you with the credentials and also asks for them, what's the point of that portal in the first place?

You can use them across multiple sessions and devices.

I use cbc.ca. It's short, memorable and to date, hasn't implemented http->https redirect.

When macOS connects to a Wi-Fi network it makes an HTTP connection to captive.apple.com, and if it doesn't get the expected page in response it pops up a little browser window. I much prefer this solutions to hijacking page loads in my browser (which tends to have lots of annoying side effects).

There are proposed standards to serve a URL for a captive portal via DHCP.

But hopefully, many captive portals will just die off.

Captive portals have always been a hack. I'm sure there'd be some interim solution, even if it's just hardcoded captive.apple.com as an exception.