coova-chilli: fix defaults for redir and SSL

[nemesifier]

Maintainer: @teslamint
Compile tested: (ramips, yuncore AX820, OpenWrt 24.10)
Run tested: (ramips, yuncore AX820, OpenWrt 24.10)

Description:

The current defaults in coova-chilli make the
package in the official OpenWrt repositories
nearly useless: it can't redirect users to
the login HTML page and doesn't support HTTPS.

Without HTTPS, browsers display security
warnings, discouraging users and making the
package impractical in modern environments.

Without redirects, the user would have to
open the login HTML page manually, which
is extremely bad UX.

Updating these defaults will make the package
published in the official OpenWrt feeds
usable out of the box, lowering the barrier
to entry for users exploring coova-chilli's
hotspot features.

[teslamint]

IIRC, COOVACHILLI_REDIR config means enable fork redirect process by compiling redirection code to separate executable file(chilli_redir). It should not affect handling unauthorized HTTP traffic.

[nemesifier]

IIRC, COOVACHILLI_REDIR config means enable fork redirect process by compiling redirection code to separate executable file(chilli_redir). It should not affect handling unauthorized HTTP traffic.

@teslamint Thanks for your insight. Are you able to get the web redirection without the enabling the redir module? I tried but I do not get redirected at all. The minibrowser of the phone doesn't show up.
I always wondered if this module is mandatory or not. I think enabling these would make the default package more useful to more users and lower the barrier to entry on this.

[teslamint]

@teslamint Thanks for your insight. Are you able to get the web redirection without the enabling the redir module? I tried but I do not get redirected at all. The minibrowser of the phone doesn't show up.

That happened when chilli cannot see HTTP traffic from device or device cannot see response from chilli. Packet capture may help.
Have a look around on upstream issues list including closed one? : https://github.com/coova/coova-chilli/issues

I always wondered if this module is mandatory or not. I think enabling these would make the default package more useful to more users and lower the barrier to entry on this.

I don't see which case you need to chilli handles SSL traffic.
Even today, modern mobile OS still connects specific site via HTTP to detect internet connectivity, so there's not much case to chilli handle HTTPS traffic with frustrating end-user experiences (especially after users' session are timed out) and headaches managing SSL certificates and distribute to end-users.

[nemesifier]

@teslamint Thanks for your insight. Are you able to get the web redirection without the enabling the redir module? I tried but I do not get redirected at all. The minibrowser of the phone doesn't show up.

That happened when chilli cannot see HTTP traffic from device or device cannot see response from chilli. Packet capture may help. Have a look around on upstream issues list including closed one? : https://github.com/coova/coova-chilli/issues

Looking, thanks.

I always wondered if this module is mandatory or not. I think enabling these would make the default package more useful to more users and lower the barrier to entry on this.

I don't see which case you need to chilli handles SSL traffic. Even today, modern mobile OS still connects specific site via HTTP to detect internet connectivity, so there's not much case to chilli handle HTTPS traffic with frustrating end-user experiences (especially after users' session are timed out) and headaches managing SSL certificates and distribute to end-users.

When the user posts their credentials on a login webpage, if the login page isn't served via HTTPS, the browser issues a security warning about the form not being secure. If the login page is served via HTTPS, then chilli needs to receive the GET/POST request on HTTPS, or otherwise the browser would also issue a big fat warning like the one shown below:

Without SSL support, chilli is not able to respond on HTTPS.
Yes, distributing and renewing certificates is tedious, but there's technical solutions for that.
I don't see downsides in enabling these features by default, nobody wants to run a hotspot service in a university, a hotel or any business with such fat warnings about the service being unsecure, it would look really bad for the owners. Whenever new OpenWrt users start trying out chilli on OpenWrt, they bump into these issues and they end up having to compile the package with this option turned on.

Moreover, even if SSL is enabled, it's not mandatory to configure it, if the user doesn't want it because maybe they're still in the playing stage, they can keep it turned off.

[nemesifier]

I updated the patch to only change the default SSL setting.
I think it would be very useful for most users to have this enabled by default.

[teslamint]

When the user posts their credentials on a login webpage, if the login page isn't served via HTTPS, the browser issues a security warning about the form not being secure. If the login page is served via HTTPS, then chilli needs to receive the GET/POST request on HTTPS, or otherwise the browser would also issue a big fat warning like the one shown below:

Indeed, if you try to send POST request from HTTPS web page to HTTP-only host, you get the warning. But, chilli supports GET request and most modern browsers has exception for local/private IP for security check, IIRC.

[nemesifier]

When the user posts their credentials on a login webpage, if the login page isn't served via HTTPS, the browser issues a security warning about the form not being secure. If the login page is served via HTTPS, then chilli needs to receive the GET/POST request on HTTPS, or otherwise the browser would also issue a big fat warning like the one shown below:

Indeed, if you try to send POST request from HTTPS web page to HTTP-only host, you get the warning. But, chilli supports GET request and most modern browsers has exception for local/private IP for security check, IIRC.

That assumes the login page is hosted on the device itself, which is not always the case, especially for more complex applications that can't fit on the limited space of embedded devices. Are you against compiling the default package with SSL support? If so, why? I don't want to waste my time nor yours, so I will ask this directly.