Captive Portal versus iOS 14.x

Gertjan

Before Octobre 30, 2020, iOS based devices executed a

GET  http://captive.apple.com/hotspot-detect.html

(using destination port 80)
This was intercepted by the captive portal 'ipfw' firewall, and redirected to a http or, if you've set up https redirecting and you are using a trusted certificate, a https web server.
This web server returned the login page.
Al l was well.

Now, since 14.x, the iOS launched to support the iPhone 12, this seems to became very important :
Apple Developper : How to modernize your captive network

I wasn't aware of these changes, but since I upgrade to 14.1, (I guess) the build in Safari browser doesn't pop up to ask me my credentials any more.

Check the logs :

11-10-2020	08:19:51	Local5.Info	pfsense	Nov 10 08:19:53 nginx: 192.168.2.75 - - [10/Nov/2020:08:19:53 +0100] "GET /MFgwVqADAgEAME8wTTBLMAkGBSsOAwIaBQAEFH7maudymrP8%2BKIgZGwWoS1gcQhdBBSoSmpjBH3duubRObemRWXv86jsoQISA4pd8X8iYe8mEO49bpkIqVWk HTTP/1.1" 302 5 "-" "com.apple.trustd/2.0"

The encrypted "GET com.apple.trustd/" is new.

I added the mentioned DHCP 114 option as instructed on the DHCP server, the captive portal interface page (named PORTAL or OPT1), using the https://portal....... portal URL.

Btw : "captive portal" will have it's own RFC soon : https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-11 (Juin 2020).

When packet capturing, using UDP on the portal interface, limited to ports 67 and 68, I saw :

      URL Option 114, length 55: "https://portal.brit-hotel-fumel.net:8003/?zone=cpzone1"

which looks fine to me.

Meanwhile, I discovered that iOS 14.2 was aviable.
I upgraded , and suddenly the good old :

11-10-2020	09:03:24	Local5.Info	pfsense	Nov 10 09:03:26 nginx: 192.168.2.75 - - [10/Nov/2020:09:03:26 +0100] "GET /hotspot-detect.html HTTP/1.0" 302 0 "-" "CaptiveNetworkSupport-407.40.1 wispr"

is back

Did I just experiences a glitch ?
Did I just discovered what will be the future : native RFC captive portal support ?

gotshaykes

We're running into this same issue with iOS14 and now Big Sur as of 11.0.1. I haven't found a workaround as of yet. Seems like writing an API per RFC 7710 may be the only workable solution. :(

Gertjan

https://tools.ietf.org/html/rfc7710 = ~~7710~~ updated by RFC8910 still stands. 7710-bis, which I cited above, is still in draft mode.
With iOS 14.1, the issue poppud up right away. The iOS 14.2, which came out several days later does not show the same behaviour, portal access works as usual. The Apple hot line probably went red.

I do like the proposals of ~~7710~~ updated by RFC8910 and 7710bis : no more DNS request redirecting. The device will know it's behind a portal as soon as the DHCP did it's work. The device will know where (URL) to go.

Right now, for me, the access work.
I did de-activate the private (MAC) address setting for my captive portal, so my iPhone presents the real Wifi MAC to my portal, and not some random MAC. I guess this doesn't really matter.

gotshaykes

Sorry, I'll try to be more specific. :) Yes, I was referring to RFC7710bis and the Apple API draft.

Environment: pfSense 2.4.5 community edition. Clients assigned pfSense firewall for DNS. We're using the DNS forwarder.

Today, when iOS13 and older, and macOS 10.15 and older devices connect to the network, the Captive Network Assistant immediately displays the captive portal splash page in a push window. This behavior is desirable for a smooth user experience.

What we're experiencing is users running iOS14 (all versions) and macOS 11 Big Sur (only tested 11.0.1 so far) no longer automatically see the captive portal splash page after connecting. This new behavior is consistent from 14.0-14.2 tested with an iPad, iPhone SE, iPhone X, iPad Air. It does not matter if private MAC feature is on/off: both were tested.

Android 9/10/11, Windows 8/10 continue to operate as expected with the captive portal agreement appearing automatically after connection.

In all cases, HTTP redirect works as expected, but that's a poor experience on the user side. Given modern browser preference for HTTPS, it really only works if a user browsers to an HTTP-only site (e.g., neverssl.com). We do not use HTTPS redirect to avoid certificate errors in browsers and apps. Firefox is very helpful though: it at least displays a notification that you need to login to the network when you try to browse. :)

For comparison: we have a custom-built registration system on another SSID that responds with its own IP for all DNS queries from unregistered devices. All DNS queries are blocked unless sent to the registration server. The CNA push appears as desired on iOS14 (all) and macOS all for this system.

Gertjan

@gotshaykes said in Captive Portal versus iOS 14.x:

Given modern browser preference for HTTPS

And that's a good thing.
And has nothing to do with 'captive portal detection'. edit : that is, how a device detects a portal.
My experiences from here tal about apple products, I do not have oter devices at my disposal. But I know they work the same way : they send out a known http request as soon as the connection comes up. Even Microsoft Windows 10 PC's do this !

A small "how-does-a-portal-work" :
As soon as DHCP finishes it work, the OS (not you !!) throws out a "http" request.

For Apple devices, this is the hard coded : http://captive.apple.com/hotspot-detect.html
If the answer 'page' is -what you see when you click on the link yourself using your browser - "Succes" then device knows it has a direct Internet connection.
If something else comes in, like our captive portal login page, then the OS spaws a minimalist browser - and this browser (a low bud Safari version) repeats the request.
Our login page shows up.
The fact that our captive portal goes over https has also nothing to do with the portal itself. It's just more logic these days - and needs a trued cert. http portal login would work also just fine.

I reconfirm : using iOS 14.2 on an Apple iPhone : the portal pops right after selecting my captive portal wifi network.

In the logs, I see : DHCP handshake :

2020-11-18 16:18:53	Local7.Info	pfsense	Nov 18 16:18:57 dhcpd: DHCPREQUEST for 192.168.2.75 from 02:81:5f:85:a4:a0 via em2
2020-11-18 16:18:53	Local7.Info	pfsense	Nov 18 16:18:57 dhcpd: DHCPACK on 192.168.2.75 to 02:81:5f:85:a4:a0 via em2

iPhone throws out the "http://captive.apple.com/hotspot-detect.html" request
The 'port' 80 connection gets redirected to the captive portal webser, so it shows in it's log the inital request :

2020-11-18 16:18:54	Local5.Info	pfsense	Nov 18 16:18:57 nginx: 192.168.2.75 - - [18/Nov/2020:16:18:57 +0100] "GET /hotspot-detect.html HTTP/1.0" 302 0 "-" "CaptiveNetworkSupport-407.40.1 wispr"

And the redirection according the nginx config file = the domain part, is being replaced by the captive portal pfsense domain - or IP if you use http auth - the original URL is passed as a parameter. The portal zone ID is passed as 'cpzone' :

2020-11-18 16:18:54	Local5.Info	pfsense	Nov 18 16:18:57 nginx: 192.168.2.75 - - [18/Nov/2020:16:18:57 +0100] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/1.0" 200 1662 "-" "CaptiveNetworkSupport-407.40.1 wispr"

Now, the Apple knows that a portal might exist : it did not obtain "Success" as an answer (but our login page). It repeats the question, this time using the build in safari browser :

2020-11-18 16:18:54	Local5.Info	pfsense	Nov 18 16:18:58 nginx: 192.168.2.75 - - [18/Nov/2020:16:18:58 +0100] "GET /hotspot-detect.html HTTP/1.1" 302 5 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148"

... and the URL gets rewritten according the nginx config file :

2020-11-18 16:18:55	Local5.Info	pfsense	Nov 18 16:18:58 nginx: 192.168.2.75 - - [18/Nov/2020:16:18:58 +0100] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/2.0" 200 906 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148"

These steps are optional : the Apple browser get an included CSS file :

2020-11-18 16:18:55	Local5.Info	pfsense	Nov 18 16:18:58 nginx: 192.168.2.75 - - [18/Nov/2020:16:18:58 +0100] "GET /captiveportal-2style.css HTTP/2.0" 200 1097 "https://portal.brit-hotel-fumel.net:8003/index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148"

I also have a logo on my login page :

2020-11-18 16:18:55	Local5.Info	pfsense	Nov 18 16:18:58 nginx: 192.168.2.75 - - [18/Nov/2020:16:18:58 +0100] "GET /captiveportal-nvxx-logo.png HTTP/2.0" 200 16886 "https://portal.brit-hotel-fumel.net:8003/index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148"

The next 4 lines are not clear to me : Apple gets impatient ? :
Note the 2 times identical "hotspot-detect.htm" request,s and the http return code "302" which means : you are redirected.

2020-11-18 16:18:55	Local5.Info	pfsense	Nov 18 16:18:59 nginx: 192.168.2.75 - - [18/Nov/2020:16:18:59 +0100] "GET /hotspot-detect.html HTTP/1.0" 302 0 "-" "CaptiveNetworkSupport-407.40.1 wispr"

2020-11-18 16:18:55	Local5.Info	pfsense	Nov 18 16:18:59 nginx: 192.168.2.75 - - [18/Nov/2020:16:18:59 +0100] "GET /hotspot-detect.html HTTP/1.0" 302 0 "-" "CaptiveNetworkSupport-407.40.1 wispr"

... the 2 redirections (status "200") :

2020-11-18 16:18:55	Local5.Info	pfsense	Nov 18 16:18:59 nginx: 192.168.2.75 - - [18/Nov/2020:16:18:59 +0100] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/1.0" 200 1662 "-" "CaptiveNetworkSupport-407.40.1 wispr"

2020-11-18 16:18:55	Local5.Info	pfsense	Nov 18 16:18:59 nginx: 192.168.2.75 - - [18/Nov/2020:16:18:59 +0100] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/1.0" 200 1662 "-" "CaptiveNetworkSupport-407.40.1 wispr"

And the final POST, when I entered my credentials and hit the Login button :

11-18-2020	16:47:43	Local5.Info	pfsense	Nov 18 16:47:47 nginx: 192.168.2.75 - - [18/Nov/2020:16:47:47 +0100] "POST /index.php?zone=cpzone1 HTTP/2.0" 302 0 "https://portal.brit-hotel-fumel.net:8003/index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 14_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148"

And now : more portal web server logs, as my Apple iPhone IP/MAC are now entered into the ipfw tables that permit pass through the firewall.

Btw : I use the resolver - as it is the default, the future ( see these : https://forum.netgate.com/topic/158399/sad-dns-and-unbound-question/10 and second post ) and I was told to do so by the original Netgate Captive's portal videos.
What really counts is : DNS should work.

I'm not using the build in pfSense user manager, but the FreeRadius package which permits me to play with criteria like speed, time out, quota and other nifty things. I guess not related with your issues.

As said, I'm using https portal login, as http is something of the past. - http is still used in the back ground - very needed as our captive portal wouldn't work otherwise.

I guess Apple is using right now the old and new way of 'portal testing'. Using the new way aka 7710-bis only would break most portals on planet earth right now, as I don't think they would 'just switch' like that.
On the other hand, as I always watch https://www.youtube.com/watch?v=9tQVQUd94Aw& ( Louis Rossmann - a Apple device repair guy ....) Apple is very capable of upgrading Apples ... and disabling the charging capabilities so your Apple just ... stops working. Looks like Apple hired Microsoft knowledge or people.

I saw the Apple .../API https (!) requests when I was using iOS 14.1, otherwise I wouldn't even know that the captive portal approach wasn't already standardized in RFC's.
I'm asking myself : is pfSense aware of this ? Or am I as a pfSense user just the first one who sees and writes about it ?

gotshaykes

We have resolved the issue we experienced with iOS14 / Big Sur CNA by switching from the DNS forwarder to DNS resolver, and enabling SSL/TLS queries and DNSSEC support. We've been meaning to do this for awhile anyway.

Regarding the API: Since Android and Apple already have support for the draft spec, it would be awesome to see this come to the captive portal roadmap.