I’ve been experimenting with the MT hotspot and external loginpage. (external server does https, so i got redirected to https://x.x.x.x/mtlogin.php)
I got it working, though on login the browser spits a security warning: “However this page is secured, all information you’ve entered will be send over an unencrypted connection allowing others to read it easily” (I translated the message myself from dutch)
I’ve got now login-by http-chap, https, http-pap enabled.
I tried enabling only https, but then I can’t login anymore. (I get: configuration error (HTTP/HTTPS login is not allowed))
I’m sure this is something small, but i can’t find the reason causing this.
Any hints?
With no ssl certificate in the router, you should use “login-by=http-chap”.
Here is what is happening: You are sending the initial request http (port 80) to the router. The login.html page redirects your browser to the secure page on your server (port 443). But once the browser gets the login page from the server, it will submit the form on that page unencrypted over http (port 80) to the router hotspot.
With “login-by=http-chap”, the password will be MD5 encrypted. All else, like your username and your original url request, would go clear text.
With http-pap, everything, including the password, is sent clear text.
If you want the whole process secure, you will probably need to install a ssl certificate on the router. I think then you would use “login-by=https”, but fewi is better at that than I am.
Tnx, but as soon as i disable http-pap, i get authentication failed. Radius part sure is ok.
I followed examples in the wiki for setting up the ext. loginpage, but redirect to a https loginpage. That’s the only difference for the moment. I don’t want to install a local ssl cert on the router as i don’t intend to use it that way.
I hope someone can point me to the right settings to do this in mt.
I will experiment a little more here and come back to you.
Btw I remember to see your nickname some years ago on the chillispot forums. I still have a lot of chillispot nas’s out there.
What I eventually want to do is use the same hotspotlogin.php for chillispot and Mikrotik nas’s.
I tried it some weeks ago but got stuck on the uam secret / chap challenge which is handled differently. (authentication failed and showed an error)
Do you happen to have any idea how we can make hotspotlogin.php work on both systems (MT & chilli) ?
I noticed the people from hotspotsystem do it, so it can be done
Kind regards & tnx
B
PS the wiki you pointed to was the one I was using. Didn’t know the page was created by you
I just copied the demo php for the server and local redirect page for the router.
The only difference is that the action= https://x.x.x.x/login.php instead of http://x.x.x.x/login.php
(I did copy md5.js to the server and chmod’d it)
Ok, a little bit further. I found out that the http-chap was failing coz magic_quotes were on on my php server.
I added the php function to replace the slashes and it was working. Now I can login with login-by=http-chap set.
Before it only worked when http-pap was enabled, so this is solved.
BUT, I still get that security warning in my browser (see first post) and I don’t know where this is coming from.
I also just noticed that I only get that warning in Firefox (v3.5.16), not in internet explorer, but still I don’t want it as many people use firefox.
The browser is detecting that you have a secure page that either includes resources from non-secure pages (images, JavaScript, CSS etc. loaded via http rather than https on the page), or that you’re submitting to an http server rather than https in your form target.
If you’re using CHAP the router you’re submitting to doesn’t use https. To test, everywhere you’re referring to $loginlinkonly in PHP refer to a static string of https://example.org/login instead. Does the error still show up?
About http-chap, I would love to only login by https, but then I need a certif. on each MT box, right?
I don’t like the idea when the certif. expires I have to change the certs in all deployed boxes.
That’s one of the reasons I like to use an external login page.
I don’t need to try to replace $loginlinkonly, you’re right, it is that causing the issue.
Just looked in the browser source of the loginpage and it’s posting back to http://hotspot.mtbox.org (the dns name I used in hotspot setup)
EDIT: Just hard coded the static url for $loginlinkonly, but of course now it posts back to https://hotspot.mtbox.org which isn’t recognised and login fails.The error was gone though.
Now what 's the best way to solve this?
Is there any other way then using local https certificates on the MT box? (next to using http of course)
Just noticed something else too.
When I set my homepage to a https site, it doens’t show me the login page when i open my browser or hit the home button.
When my homepage is set to a http site, no problem. Is this normal behaviour?
The Hotspot cannot intercept HTTPS sites and pretend to be them and issue a redirect - that would cause a certificate error for the client. It’s all in how the Hotspot does its actual work.
Yes, you’d need certificates on each router. Really that isn’t too much of a problem in the real world. Either get a wildcard cert and use subdomains with the same cert everywhere, or use the same domain name for each router. I use hotspot.company.com everywhere (through a wildcard cert, but it could be a cert for just that name), and that name resolves to 10.1.0.1 everywhere. Each hotspot router has hotspot VLANs on a physical interface, and the physical interface at each site has 10.1.0.1 on it. The name and IP for a Hotspot service doesn’t have to be on the immediate interface, it can be any interface on the router. You could also use loopbacks for this.
All registrars I am aware of let you extend a certificate well before its expiration, so you can have weeks or months to deploy the new cert on each router as the old one expires. Since you can have multiple certs on a router and refer to it by name in the Hotspot profile configuration, this is entirely seamless. Via SFTP/SCP/FTP push scripts and API calls/automated SSH sessions you can even deploy and implement the certificates in a very automated fashion. It’s work to write that once, but then you can mass execute changes on all your routers going forward, which is a pretty nifty thing to be able to do. A cheapo solution via SSH calls and key based logins really doesn’t take long to deploy.
Of course you can also fix this issue by just using an HTTP site on the external server, and then using CHAP. But for signup solutions it’s just nice to offer HTTPS all the way through.
Personally I prefer HTTPS and its general track record and support on all devices to a proprietary CHAP solution that requires JavaScript. There are some mobile devices out there that don’t do JS by default or have incomplete solutions, there is also NoScript (turns off JS on a site by site basis), which is a surprisingly popular Firefox add-on. There’s also browsers like Opera Mini for mobile devices, which executes the JS on the remote Opera server.
Yes, I do the same as you describe now on our m0n0wall driven hotspots.
I also use one certificate for that (hotspot.mycompany.net) resolving to the private hotspot ip address.
But I had to change the expired certs on all boxes last year and it was quite a job (m0n0wall doesn’t include an ssh server by default, so it was MANUALLY)
I thought I could mimic the same behaviour in MT as I did with chillispot, but ok we can’t.
I also don’t want to use http, it simply doesn’t look professional to begin with.
If I have to go the same way as with m0n0wall, I think i will use a local loginpage on MT also.
I created a javascript based multilingual loginpage before, it can reside on the router and falls back to english if there’s no javascript enabled in the browser.
And about changing the certs when they expire, well I have time to script an automatic procedure for MT, my current certs only expire in 2015
Hi Beone. Yes, that was me on the Chillispot forum. Some of the things I did there was remove a bug in the C code and write a multi-language login page. Then the Chillispot site went Error 404 and it kinda ticked me off that I did that debugging, then the guy closes the site.
I don’t see why the external login.php page couldn’t be used by both Mikrotik and Chillispot, but you would need to send a variable from one or the other so it would know how to retrieve the form variables. It has been too long for me to help much with Chillispot tho. My advice would be: pick one of the form variables and retrieve it first. Then based on whether you find it or not, use the php server to retrieve the remaining form variables and create the page for the correct OS. That is the best I can come up with right now.
BTW, the external login page should not have a problem with ssl. The only thing I can see that might generate a warning is the DOCTYPE link. There are no other non-ssl links. The md5.js is a local link, so it will be secure.
ADD: That is not really true now that I think about it. The login form submission link might generate a “not secure” warning if you don’t have ssl on the router hotspot. That form url would be “http://x.x.x.x”.
Indeed Tim, that was the problem, posting back to the MT doing only http and not https (tnx fewi for pointing me to this)
But like I said before, if I have to install a https certif. on each MT router I prefer to use a local loginpage on them too.
I created a javascript based multilingual loginpage before, which I modded to work with MT now. (still have to test it, but I guess it will be ok)
I’m also thinking on saying goodbye to (coova)chilli (or at least don’t deploy any new ones anymore) as throughput is much less then on MT devices with comparable hardware and community support at MT is way better.
I’ve ran chilli on an ubnt airrouter (400MHz, 32MB ram) and got about 37Mbit througput. The same test on a RB750 (also 400MHz, 32MB ram) resulted in 57MBit (which was the limit of my cable internet connection)