https redirect problem with default browser setup

Hi everyone,

I have a PirateBox running on the TP-LINK device successfully. Everything works as expected, except for one annoying problem. Many browsers (Chrome, Firefox, etc) now default to Google search via https when you type something into the address bar. This means if you were to come across a PirateBox 'in the wild' and perhaps refreshed a Gmail window, or typed any old random thing into your address bar to see what would happen - PirateBox would fail and be unable to redirect you to the primary PirateBox homepage.

This is a difficult issue, because you can't just bounce 443 to 80 without a certificate, and without one you'd confuse the user even more by displaying an insecure site error.

So while the dnsmasq daemon is able to capture all web requests and redirect the user to the PirateBox homepage by defaulting all name resolution to the IP of the PirateBox, it is unable to do so if you start by requesting a https page, which in todays web is almost the default.

Any ideas on how this could be solved?

No that is not possible, if you redirect the traffic from 443 to 80 you would get a ssl handshare error.
And if you stick with port 443 and offer a certificate the browser will tell you it is a fake one.

Irritating yes, a solution alas but no.
[github.com]

Is it possible to force a user to a page when the WIFI connection to the box is established? We see this sometimes with paid WIFI hotspots, where the user is automatically pushed to a login page.

Force a user to a page is not possible, but you can have a sort of popup html.
[github.com]

Do you know what the technical name for this is, or if there is a method for doing this under Linux - to me this seems like a critical problem for the discovery of PirateBox's in public spaces by non-technical people who don't know what they are.

I would call it captive portal detection, see also [github.com]

The reason that it is forced to the success message, on ios the piratebox becomes unusuable otherwise.

Yes, FriedZombie is right.
And we have that iOS fake message a while ago included.

The only "real" issue left is the point about https which we can't change.
We can't even force a OS to open a browser, well that sounds like a security leak in times of Windows98

I have the same problem.

I am not using PirateBox but I have a very similar system that I use at meetings and events. Recently I used it at an artists show.

My solution so far has been to tell users to visit a .com address after they are connected to the access point.

This is done through signs and posters, or announcements to the group.

The address could be anything like z.com or name_of_our_event.com.

If the address has a top-level domain like .com, .net etc. then the browser knows that it is not a search request but a DNS query, and DNSMasq will resolve it to the local server.

But commercial captive portals don't seem to have this problem. How do they solve it?

Couldn't we simply buy and share an SSL certificate for piratebox.lan with an official root certificate already built in devices?

Interesting idea, but won't help.
The effect would be:

open https-google
get a certificate error because of non matching domain names

Okay, as getting an error message is really a showstopper when trying to connect to a piratebox, let's think it the pirate way.

As https://[www.]google.com is very likely the first page which users open after having selected the PirateBox WLAN, we probably could fake a Google landing page on the PirateBox with an SSL certificate for [www.]google.com, and then redirect from there to piratebox.lan. A cheap SSL provider such as FreeSSL might not check the organisation name, when you order a certificate. Whether https://[www.]google.com is really the first page on most devices' browsers and if we really could get such a certificate would be needed to be further investigated.