Chromebook and Captive portal unsafe page

[PierreFrench]

Hello
I run smoothly a pfsense with a captive portal.
The captive portal has it own real certificate ( Let's encrypt ACME )
Everything was running fine since .... Some one tryed to connect using a Chromebook
At connection time and before the portal page was displayed the Chromebook issue a warning stating that
the connection to http://gtstaic.... is not same ???
As far as I understand that initial connect is always in http and not https so defacto "unsafe".
That warning only occurs with Chromebook , not with other OS.
The Chromebook machine is brand new so I guess it's all updated from an OS perspective.
As anybody experiement the same issue ???
Is there a workaround?
As different customers can connect to my portal this as to be cleared to make it feel safe again from a user perspective.
Thanks for your anwser
Regards
Pierre

[Gertjan]

@PierreFrench said in Chromebook and Captive portal unsafe page:

the connection to http://gtstaic.... is not same ???
As far as I understand that initial connect is always in http and not https so defacto "unsafe".

This "http://gtstaic...." is used by the Chrome OS to check if a direct, open, not filtered Internet is available right after the network interface comes up.
Every OS uses its own 'http' test URL. Here is the one from my iphone :
http://captive.apple.com/hotspot-detect.html - click on it and you'll se what happens.
When my phone request this page, and get a simple html page back with the text "Success", then it knows that it probably has a direct connection.
All it knows is that DNS works, and port 80 TCP is open.
If something else came back, the the OS knows that something is going on. Maybe there is a portal ?
So, it launches a fulls screen default browser, with the same test URL as a destination.

On the pfSense side of things, there will first be a DNS request from the portal client. In my case : what is the A record of "apple.com". The IPv4 is given to the requester, your portal device. This is all part of DNS.

Be warned : if your your device doesn't use the DHCPv4 IP it got during DHCP - most typically the pfSense portal IPv4, but some other DNS IPv4, then you have issues : this destination is blocked. So : no DoH, no DoT etc. Just plain old school DNS over port 53 to the local gateway.

Now, pfSense, the pf firewall, will receive a browser request : traffic to 'some IPv4' with destination port TCP 80 : a typical http:// browser request. This "TCP port 80" request will get redirected to the captive portal's web server, using something like TCP 800x. The web server will send over the login page.
Important to know : only http traffic can get redirected like that. https can't.
If you use the https portal login page, then your http web page request get redirected to a TLS TCP (800x+1) port. The redirection isn't an IPv4 anymore (the pfSense portal interface IP) but a host name should resolves to this IPv4. The certificate send by the web server should contain the very same host name, so the portal client's web browser accepts the certificate.

All this means : most of the captive portal support isn't build into pfSense, but in the device that connects to the portal !
Captive portals all work the same way.
Microsoft OS devices will test for a connectivity to http://www.msftncsi.com/ncsi.txt
Apple device will use http://captive.apple.com/hotspot-detect.html
And the android/chrome/whatever have their own URL as well.

Btw : http is used and that's ok, there are no security issues as close to nothing is send to the server - the traffic will never even reach the remote server, as it will get redirected and intercepted by the pfSense portal web server : traffic will never leave your site.
If you use a https captive portal login page, the portal page traffic is encrypted using TLS 1.2 so your very secret captive portal password ( ) is also very well protected, even if the traffic goes over an open (non WPA) encrypted wifi radio channel.

Back to you Chrome issue :
Check if DNS works on the pfSense side : if the resolver is listing on captive portal interface.
Check if DNS traffic is handled by pfSense.
Check what the chrome book is sending ; Status > System Logs > System GUI Service

Have a look at the captive portal firewall rule :
See /tmp/rules.debug : and look for the word "portal" - there are several rules.