I am shure, you are wrong here. Looking at one of my chilli based commercial CPs, I did several years ago, still in production, and now being updated to latest openwrt, this is some excerpt:
I too run many commercial CPs. Initial hands on testing and research showed conclusively that all ios devices blocked external third party js downloads and most android did too regardless of any walled garden settings. This has not been revisited by me since. Non of my "production" systems depend on external js downloads as it will in most cases not work for the client. I have no reason to believe things have changed apart from many Android implementations following ios restrictions. Perhaps they have changed relaxing this, but I doubt it.
It is different where css is concerned where you have an Internet based "splash page" with "All the URLs are referencing the authorizing server". Css is not executable code, it is formatting information and an extension to html. Css can even be on third party servers as long as those servers are included in the CP's walled garden.
In your example, the css will be fine (as long as it does not depend upon the client running downloaded code), but the javascript is code the client must download and execute. It is this that is blocked, and for security should be blocked, by clients.
There is the question of why a captive portal would need the client to execute javascript?
The answer might be "Because I can use third party libraries to make the page look really smart without having to think about the coding myself".
Equally it might be "For my man-in-the-middle attack, I want the CP to do things on the client device without the user being aware of it".
Only a disagreement in the sense it is not conclusively proven either way.
As @DrKamp says, this is an interesting discussion.
A couple of questions:
If you connect to your system with, say, a laptop, where you have disabled javascript in the browser, does the login still work?
If not, does this mean you are deliberately excluding ios devices?
On a laptop with win7, Firefox will, by default, accept JS from a CP.
On win10 +, linux, and MacOS, the inbuilt Captive Portal Detection (CPD) has its own built in "mini-browser" and blocks JS just as in the ios and android(some) case.
Sounds like a lot of extra unnecessary complexity to me.
Just for sake of verification: Pls, provide one of the android(some) cases. Which device, Android version ? Special handling not only required regarding JS, but also regarding auto close of minibrowser on Android, in case of connection available. Some hotspot operators have above average requirements, i.e. to display remaining traffic limit, after login and connection establishment. Or to force user to see some ads, after connection establishment.
Not to limit requirements, but to fulfill them.
Devices were tested some time ago and those found to block js were:
Google Nexus tablet - android version not known
Google Pixel 3 - android 9
Samsung Galaxy S5 - android 6
All of these also immediately closed the CPD browser on getting a positive can_check after being authenticated.
More recent testing for models with CPD browser closure gave:
Samsung Galaxy S5 through to S21 - android 6 to 12
Google Pixel 3 through to 6 - android 9 to 12
Ulefone Armour x9 - android 11
Ulefone Armour 10 - android 12
For advertising or news delivery, the CP should display the relevant html page before it authenticates the client. (The user clicks continue after scrolling down through the page(s) of information/ads). This is, for example, the default provided by openNDS.
Displaying after authentication cannot be reliably accomplished with CPD (Captive Portal Detection, the de-facto standard). It is however supported if both the CP and client support CPI (Captive Portal Information) as described in RFC8910/8908.
CPI is not widely supported yet both in clients and CPs (openNDS does).
Of the few clients that do support it, not all of them support it fully. Only time will tell if CPI becomes widely accepted as a standard.
Hello everyone,
regarding the configuration of openNDS as CP with external FAS, could you confirm that my understanding of the process is OK "so far" ?
I need to configure OpenNDS with
Enabled = 1 (obviously)
Login Option = 0 (to enable FAS)
Gateway interface = "wlan0" (the OpenWrt interface that will present the CP to users)
Gateway name = "MyGateway" (mainly used when having multiple opennds and a single FAS server)
FASPort = 80 (port used by the FAS server to serve the php script.
FASfqdn = myserver.com (remote FAS server domain name)
FASremoteIP = 123.45.67.89 (remote FAS server IP adress)
FASKey = '314159" (encryption key. NEEDS to be the same in the myAuthScript.php)
Fas_secure_enabled = "3" (depending of secure settings (3 enforces https)
On the remote FAS server :
Just need a "classic web server" with Apache and PHP
The php script should be located in myserver/[faspath/script.php]
My questions now :
If I use fas_secure_enabled = "3", do I NEED to use the fasport = 443 (because of https ?) or can I still use fasport = 80 (http) ?
what should I use as fasFQDN if my server does not have a domain name (but only a fixed IP ) ?
I'll use the fas-aes-https.php script to start with. (I changed the faskey on both opennds and php file).
I've seen on the web (which is why I'm checking this with you ) some config with UseOutdatedMHD = 1. Should I Use this ? I don't really like things that are outdated...
Thanx. Will try to get my hands on such ones. I assume, your test was with JS enabled, which is not always default.
This is not correct. Of course, it can be done for Android. For certain period of time, at least. Which then is good enough, i.e. to display remaining money on wifi account, remaining traffic etc. User must be authed, and web connection established, to do this, of course.
Unfortunatey, this closure of the CP is for long time already default of Android, thus, not limited to certain devices. Ref. to long ongoing complains on google.
Anyway, this discussion now goes out of scope of openwrt.
As it is 100% determined by the client operating system, and as the client operating system is built to prevent external influences from changing its configuration, it is VERY much true. You might think of some dirty hack to compromise the security of a particular device, but you will find it will rapidly be closed by client updates unless it is a an old and outdated device.
If this was true, "man in the middle spoofing attacks" would be rife.
The tests were done with mobile devices in whatever configuration the vendor supplied them (by doing a factory reset in Android).
The time you will see a "landing page" after authentication will be at best the can_check_interval of the particular Android CPD implementation. Most check once per second if a CP is detected, but some check only once per 300 seconds. Once a positive can_check is received, the browser window closes.
Of course, in case, JS not enabled by default, JS in CP will not run.
So, this does not justify your disagreement with my statement, that on Android CP you can run JS.
It is more of an annoyance for the criminal/hacking fraternity trying to do what they do.
Mitigating the effects of such attempts is what whole departments within Apple and Google are dedicated to.
Yes, DNS hijacking to make unsuspecting users think they are somewhere they are not on the Internet, usually for a scam exploit of one sort or another.
Very outdated and simplistic. All this does is generate successive errors and dire warnings on older client devices that were using that list of can-probe urls. Modern can-probes (many more than listed there) expect specific responses such that the CPD can detect blocking of its probes and act accordingly.
I think we need to agree to disagree.
Your point of view is monitisation of the CP.
Mine is security of the user.
There are other ways to monitise without compromising security.
From one of your links: https://issuetracker.google.com/issues/37046898#comment61
