v5.0 28th March, x86

HotSpot

When user opens an https page first (from a bookmark or from history for example)

RouterOS redirects that and the browser displays an SSL error to the user.

Any ideas, thoughts, Solutions (workarounds) or should the redirection be somehow changed in RouterOS HotSpot ?

Thank you.

l can confirm that since 3.X to 5.X..
you can't get the hotspot login page if the server has https enable login page and the client has a proxy configure in the browser.
it shows ssl error.
But works fine in 2.9.X.
Thanks

Maybe the SSL error is displayed because the browser is expecting SSL connection and what is given to it is a non-SSL plain-text connection, probably with the login page.

I wonder if my NAT rules have anything to do with this particular issue. I may check when I have the time.

I know this topic has been on here for a while. I am running into the same issue with https redirect on hotspot. So, I did some research this morning.

I generated my own cert and installed it on the hotspot. It DID detect and redirect the un-authenticated hotspot user. HOWEVER, most browsers still displayed the warning that the domain name was incorrect (in addition to my self-signed cert warning). Afterall, how can I generate a cert for *? It's just impossible. The latest browsers are alot more intelligent about accepting certs. Also, there are more sites requiring https (google and facebook for sure). I highly doubt there is any easy solution to this.

I believe this is more of a browser/popular site thing than a mikrotik thing.

Yes.

I wonder if redirection technique exists that would not break https? and if it is accepted as standard in the browsers.

AFAIR, Sqiud can generate HTTPS certs 'on the fly' for necessary domains

Ah so MikroTik should have done the same/similar ?

it would be nice =)

Hello Chupaka,

please I need your assistance, I just bought a mikrotik router 951-2n, I have been battling with it to set up hotspot.

I have updated to the latest software,

I have read some steps in the hotspot setup guide, but it keeps giving me Error 404: Not Found

please Help!!

hi friends,
i have 2011 v6.13 and no redirect https page to login page,
formerly i had install the same router with the ssl alert but now no redirect
can any help ??, ssl alert never mine

many thx

Before post, make one search on fresh results, not on 2013:

http://forum.mikrotik.com/viewtopic.php ... 83#p409062

There is no solution.

The only solution would be to install a ssl certificate for hotspot IP, not for DNS.

The problem is that it is not possible to buy a certificate for local IP.

You can create a certificate por your hotspot ip with Linux or Mikrotiks commands, but is not a trusted certificate and warning message appears.

Hello.

I got to work with the certificate GlobeSSL, begotten by the CRS / MK certificate and associated it with a valid domain type www.internet.dominio.com made it created an Alias in the valid domain pointing to the IP of my hotspot interface on Mikrotik , imported the certificates for mikrotik gave everything right, then activated the https in the hotspot and activated the www-ssl services linked to the certificate's OK.

when I connect the hotspot appears authenticating screen in safe mode with the lock, authenticates normally without any certificate error message, it is because a valid certificate, the problem is that if I try to access the site https: //www.facebook .com, he does not authenticate and get an error saying that someone is trying to access the site with a certificate invalid.

Has anyone managed to work with https SSL certificate? what can I be doing wrong?

I appreciate if someone can help.

It can't be done by design. The certificate system is designed to not allow intercepting traffic that is planned to go to facebook.com without notice.

The only way to intercept that traffic without a browser warning would be to create a new certificate for facebook.com. This new certificate needs to be signed by a Certificate Authority installed in the users browser. So using your own CA won't help either, because the user doesn't have your CA's certificate in his browser/computer. Then you need to place the new facebook.com certificate in your hotspot and repeat these steps for every domain on the web!
And even then some browser might warn the user because of certificate pinning. You would need to do a man in the middle attack on your users and that is exactly what the certificate system tries to prevent.

All commercial systems I have seen that claim to intercept any SSL/TLS encrypted traffic work with a company owned CA where the company administrator can install the CA's certificate on every company's computer trust store. That is nothing any ISP can do for its users. And I would be the first guy to terminate my agreement when I catch my provider doing a MITM attack on https sites.

My advice: just block https for unauthenticated users. Use tcp reset so users will get a fast response from browsers. Then users will try another (http) site and see your hotspot pages.
People doesn't complain about their mail/rss/... client not functioning until they open a http site to login, so why should it be a problem with https sites?

.. (CUT)..
People doesn't complain about their mail/rss/... client not functioning until they open a http site to login, so why should it be a problem with https sites?

I completely agree with you on technical stuff, the only problem is "users" ..sometimes they even don't know a address bar exists in the browser. So, even with detailed instructions (e.g. visit the URL ..), they are just able to plop something on google search. Default initial page Google.. Google require https .. damage is done.

.. (CUT)..
People doesn't complain about their mail/rss/... client not functioning until they open a http site to login, so why should it be a problem with https sites?

I completely agree with you on technical stuff, the only problem is "users" ..sometimes they even don't know a address bar exists in the browser. So, even with detailed instructions (e.g. visit the URL ..), they are just able to plop something on google search. Default initial page Google.. Google require https .. damage is done.

Hello, have you resolved this problem? I am trying to find a solution, but nothing so far. You are absolutely right. It might sound funny but most users they really don't know what an address bar is.!! I would appreciate it if you let me know if you find a solution and I will do the same too.!

My advice: just block https for unauthenticated users. Use tcp reset so users will get a fast response from browsers. Then users will try another (http) site and see your hotspot pages.

How do I do that? I'm especially interested in how I configure it to use a TCP reset.
Has anyone looked at the HTTP headers that are sent to the client on the first response to an HTTPS request? I'm just wondering what it has for the HOST parameter. If it says google.com for example, and passes a certificate for a different domain, then the warning would make sense. If it says mydomain.com for example, and passes a certificate for mydomain.com, then there might be some hope that the browser would be happy with it. Also, is it a 200? Or a 301?

How do I do that? I'm especially interested in how I configure it to use a TCP reset.

In firewall rules use action "reject" instead of "drop". "Drop" means silently discard the packet without sending any notice to the requests origin. "Reject" means actively telling the source that this packet is not allowed.

Has anyone looked at the HTTP headers that are sent to the client on the first response to an HTTPS request?

That is too late in the process. At this point (sending a response) the browser already compared the certificates name with the domain the user entered into the address bar in his browser, because the browser also has to make sure it sends to the correct server.

I'm just wondering what it has for the HOST parameter. If it says google.com for example, and passes a certificate for a different domain, then the warning would make sense. If it says mydomain.com for example, and passes a certificate for mydomain.com, then there might be some hope that the browser would be happy with it. Also, is it a 200? Or a 301?

Most hotspot systems do not use HTTP redirects but use its firewall capabilities to reject/drop all IP packets, and IP packets to TCP Port 80 gets redirected by the firewall to some internal server. At this point the requested domain is already saved for dns name comparison in the browser and will be compared with the certificate's name of the internal HTTP server. The hotspot system might know the requested dns name (if it monitors dns requests), but as i wrote on March 2nd, then the hotspot would need to generate certificates for every possible (requested) domain on-the-fly and get it signed by a Certificate Authority (CA) that is in the users computer trust store. I can't be done without the power to manipulate users computer.

How do I do that? I'm especially interested in how I configure it to use a TCP reset.

In firewall rules use action "reject" instead of "drop". "Drop" means silently discard the packet without sending any notice to the requests origin. "Reject" means actively telling the source that this packet is not allowed.

Thanks, that makes sense.

Has anyone looked at the HTTP headers that are sent to the client on the first response to an HTTPS request?

That is too late in the process. At this point (sending a response) the browser already compared the certificates name with the domain the user entered into the address bar in his browser, because the browser also has to make sure it sends to the correct server.

Here's a thought - how about doing self-signed wildcard certificates for all of the *.TLD? Can you even do a certificate for say *.com, or do they need to have a domain name?

Or, what happens if the browser makes an HTTP request and the server responds on 443 but has no certificate? It will fail, but what does the failure look like to a user? Is it any more friendly than sending the wrong certificate?

self-signed certificate -> browser warning
server without certificate is http, not https -> browser connect error because TLS expected - in most browsers this looks more like server unreachable.

Imho, any browser warning instead of showing the original page won't help you. It doesn't matter what the exact wording is then.

My advice: just block https for unauthenticated users. 

How can I do this???