Again on Hotspot HTTPS redirection

RouterOS General
1

The user hitting hotspot for the first time with an https request will fail and receive the well known warning.
Installing self-signed certificate , enabling www-ssl service and https login , redirection is possible with some warnings.
When login by HTTP to an HTTP site is done without all the above, hotspot gives you the http login page.
After a succesfully login you can browse all HTTPS site you want.

I use trial login, as I need no immediate web surfing, but a redirection to a specific webpage after login, is it possible a workaround by IGNORING the original HTTPS request, and force the http login page in order to do a trial login and to be redirected to the desired page by alogin.html ???

In few words , https://www.google.com : who cares , hotspot gives back the login page and then www.mysite.web

Any idea ?
Thank you

2

Your problem is that you are playing man-in-the-middle for the encrypted connection between browser and website, and the
ever increasing focus on security for the web has made it impossible to do that. Even when you have a certificate, the
browser will detect that it is not for the site they are trying to visit, and will scream “insecure”, “take me away”, etc all
over the screen. And when the website has HSTS, there even will not be a button to ignore all that.

Fortunately browser makers are aware of this, and they are trying to implement workarounds for this to allow the access
to portal pages. However, there appears to be little standardization (everyone does it in a different way) so it may well
be that on some network it works OK for some users and not for others. Furthermore, that problem will remain when there
are users that just never update their software, so they don’t get those new innovations.

3

Again, you need to understand how it works. What hotspot is doing is basically MITM attack. User wants to open http://someserver.net, hotspot hijacks the connection and redirects it elsewhere. User’s browser actually thinks that the redirection came from someserver.net and has no way to tell that it’s not true.

Https prevents MITM attacks. If browser tries to connect to https://someserver.net, only thing it will accept is response from server with certificate valid for someserver.net (*), and hotspot doesn’t have it. There’s no mechanism for hotspot to say “no, it’s ok, ignore the error just once now, I’m not evil attacker, I’m friendly hotspot”. The reason is clear, it’s exactly what any evil attacker would say.

(*) Users can choose to ignore certificate errors, but it’s extremely bad practice to teach them to do that. Because when they encouter real MITM attack, they will think that it’s ok, as so many errors before.

Since people want to create hotspots and it’s not possible to compromise https, hotpot detection must be done using other method. It’s responsibility of either web browser or operating system. They have own servers that return always the same response. They try to send http request to these servers and check what they get back. If it differs from predefined response, something must have changed it, most likely hotspot. So they open new window with what they got, which is hotspot redirection and resulting login page.

If it doesn’t happen, then either browser or OS is doing something wrong, or the hotspot operator whitelisted some servers and among them the ones used for hotspot detection. So it looks like internet access is available, but it isn’t.

Instead of redirecting https, you can block all https connections (an option was recently added for that), so users won’t get certificate errors. But it doesn’t really solve the problem with failed hotspot detection, because if that doesn’t work, it will look like there’s no internet at all.

4

Thanks, pretty clearer now, it’s really a browser (security) issue then…
So what’s our kindest solutions from user point of view, when he accesses our hotspot and something bans https sites from being visited ?
It wouldn’t be a great thing to teach them “please type this url in order to login and surf”…

5

That is what the browser is supposed to do, as I explained briefly and Sob explained in more detail.
It is not something that can be solved in the hotspot. And for every loophole a hotspot software maker would find, the browser
manufacturers (and rightly so!) come with a fix.
For example, it has been tried to make firewalls that tell you to install a root certificate from that firewall, so it can be man-in-the-middle
for HTTPS sites and it can detect viruses and non-allowed filetypes. Such a device would also be able to re-direct you when you visit
such websites (of course this is only practical for company-owned devices, not for occasional visitors of some site with wifi internet).
However, browsers now in certain cases detect that the certificate issuer on the connection does not match the expected issuer for
the website, and so they again warn the user and/or refuse the connection.
It is a cat and mouse game.

6

I guess from user perspective it would be best if you were super-powerful attacker who can get hands on trusted certificates for any website. :smiley: But more seriously, there’s no perfect solution.

First make sure that it’s not the “whitelisting too much” problem. Nowadays the problem should be rare, hotspots (better term is captive portals) are well known and common browsers and OSes are aware of them. Test it with your device, regular Windows notebook for example, it should work there. If it does, it should works for others too. If it doesn’t, it will need some investigation why not.

There will always be someone with something uncommon and it won’t work for them. Redirecting https (with warnings) is sadly the easiest choice, everyone does it and users are used to it.

7

It seems to be common practice for antivirus programs running on user’s device, they do this local MITM to check encrypted stuff. I don’t like it, but for the type of user who doesn’t even know what certificate is, it may be positive thing after all.

But it’s very bad idea for public hotspot, for the same reason as teaching users that warnings are ok.

8

Just tried https auth with an apple device, it warnings me twice (two web pages sequentially) before to access hotspot , then twice for hotspot authentication , a bit tedious…
Will try to teach users to browse www.mysite.web (http) to gain access to login, at least for now…
One could even ignores issue and let them try for an http site (thus HS login) …
Thank you

9

Warning about invalid certificate before you log in is normal, if you don’t block https completely. But what should happen is either browser or OS checking if internet access is available (as I described previously), independently on your activity. And if it’s not, they should inform you about it and either show you the login page, or at least some info about it.

I don’t have any Apple devices, so I can’t test it, but there should be something called Apple Captive Network Assistant that does this. I quickly browsed through few Google results and it’s possible that it has some additional requirements, there was something that the login page itself should use https with trusted certificate. You can try some research in that direction.

10

That is the whole point, everyone (Microsoft, Google, Apple, Mozilla) do this in a different way, each with their assumptions and requirements, and it becomes impossible to get it working for everyone without testing with many different devices.
That should change ASAP.

11

There’s RFC 7710 (DHCP/RA option informing about captive portal), but I wasn’t able to find if there’s any client device that supports it (but I didn’t look very hard). In any case, it’s from 2015, so if anything supports it, it definitely won’t be everything, so it’s not solution for now.

As for current way, the idea is same for everyone, check their server and see it it returns correct answer. And specific requirements, there shouldn’t be too many. Login page with trusted certificate sounds sensible, after all you’re going to enter sensitive info. And what more you can come with? I wonder if there’s any page where requirements and behaviour is clearly documented for common OSes and browsers. With so many users affected by this, there should be one. Or maybe nobody really minds security warnings, that’s possible too.

12

The issue of course is that a solution that would require local support or setup, isn’t going to fly. You can announce capabilities or requirements with DHCP/RA but who is going to setup those?
Either it has to be done manually, which would require cumbersome actions from the admin if it is at all possible, or it would be automatic in which case it requires a firmware update.
We all know nobody installs firmware updates.

With the lack of support in DHCP/RA instances out there, nobody is going to adapt their client to listen to them. And even when they did, that would only work for people who update their client.
So it is not surprising that solutions focus on something independent of the local portal, like fetching random URLs over http.
But apparently that does not always work either (or @ik3umt would not have come here to ask for advice…)

Difficult problem…

13

Someone has to do something and be first, otherwise nothing will happen, or it will take horribly long (remember IPv6). IMHO “fetching random URLs over http” is very nice temporary solution. But even the best and simplest ideas can sometimes fail. The way forward is to determine why exactly it happens and fix it.

14

Not really sure about this “fetching random URLs over http” thing… can you explain ?

15

Sob explained that above in message https://forum.mikrotik.com/posting.php?mode=reply&f=2&t=150724#pr742614
It is something your device does, or should do, when it detects that it cannot fetch the website you are opening.
Some devices do this as soon as you connect the network, some do it when you open the browser, some do it when they encounter problems (no connection, bad certificate, etc).
The idea is that they invisibly fetch a http page hosted somewhere on internet and when that does not work, they know they have internet connection problems maybe due to a portal.
So they can present you with a message and the result of the fetch (which is your portal page).
But for this to work it is essential that you do not allow access to part of the internet, or temporary access up to some limit, or other special tricks, because that could confuse the mechanism.
You should probably try setting that https-redirect=no option as mentioned in the article linked from the above message. That could reduce the confusion.

16

Ok, it is something the user’s browser should do, but we are not sure any device does , or does it the right way.
Do you mean they should already behave this way , or is it just a plan about the way all devices should work in future as a standard ?

17

It is something they are introducing for some time now.
SO when you have an older device that no longer gets software updates it may be that it does not do it and is never going to work.
For new devices, probably it is something that every manufacturer is going to do.

18

@ik3umt: There are two things:

  • Info about hotspot taken from DHCP/RA probably doesn’t work yet (my guess)
  • Browser or OS checking for internet access by downloading something from their testing server already works (but everything can sometimes fail)
19

Yes, testing deeper (for what my knowledge permits) I’ve found iphone looking for captive.apple.com once new wifi network has been connected, while windows10 machines trigger msftconnecttest.com/redirect, both probably http sites as they make hotspot login page to appear.
Older devices/OS would probably fail as trying to hit directly the requested https site
No way to test android for now…