Re: [Captive-portals] Arguments against (any) Capport "API"

On Tue, Apr 4, 2017 at 9:19 PM, Mikael Abrahamsson <[email protected]> wrote:

On Tue, 4 Apr 2017, David Bird wrote:

For some locations, they may simply WANT to annoy you! (While also collecting per session fees from Boingo or iPass for the privileged of skipping that annoying portal.) More than likely, however, sites like the one you mentioned are just themselves concerned about liability and want that minimal amount of disclaimer...

Let me rephrase the question:

Is there today a mechanism widely deployed in mobile devices for free use by (for instance) a hotel that just wants to make sure that someone enters their credentials (to stop passers-by to use it) and wants to view and accept the TOS *once*, and then subsequenty it's ok if you just enter same credentials each time you connect and it's fine if the user never sees the captive portal for subsequent attempts.

Yes, mechanisms exists today. It is not uncommon, for instance, for the portal to record your acceptance along with your MAC address and then do "MAC authentication" for your device for some time thereafter.

The Hotspot portal could also do a lot of things in the website itself to help with ease of use... (provided you are not using a crippled browser because of a naive captive portal detector) like remembering your state from cookies, etc, and logging you in without you noticing.

Is this available? In that case, what mechanism is that and where can I read up on it?

If it's not available, then that's one thing I think we should do here.

The mechanisms exists... and, this is very much dependent on the access policy of the venue -- not all venues will want the same thing.

What about an enterprise SSID that allows anyone to connect to it, but the only thing you get is a captive portal. After you've accepted terms of service and entered username/password, this is now somehow provisioned into your device as 802.1x credentials and you then disconnect and reconnect with these new credentials, which gives you access as long as these credentials are valid?

You are describing Hotspot 2.0.

802.1x technology already exists today, but there are reasons for it not taking off in public access:

- It isn't easy to use (without Hotspot 2.0) and doesn't necessarily mean you don't have a portal anymore. For instance, what does the network do when you run out of time? Just dump you off the secure wireless or give you a portal on the secure wireless?

- Users don't care (and prefer the ease of use)

- I'd argue it gives a FALSE sense of security to users, who are, after all, using public access with no real trust relationship with the venue or the network provider. Sure, wireless security moves the bar (a little bit) in terms of passive attacks, but doesn't protect the user from active attacks or in-line snooping off the wire. Having users see the SECURE WiFi indication on public access networks (like they see at home) is misleading. The user is better off with end-to-end security. As QUIC deploys, perhaps wireless security in public access will be less of an issue.

[Note: 802.1X can be _implemented_ in ways that still leave the user vulnerable to active attacks. For instance, with EAP-TTLS, if you don't pin the profile to a server certificate, your device can be fooled into revealing your credentials to a rogue AP.]

--
Mikael Abrahamsson email: [email protected]