To explain this problem with an analogy:
Suppose you go to a police station, and ask to speak with officer "Lindsey Smith" because you have been told you can trust her. Then a large, burly-looking male officer comes to you, shows "his" police officer ID and it says "Officer James McBurley" and has his photo, and a valid-looking police department seal. He says "Hi, I'm officer McBurley. You have to talk to me first."

Even if the I.D. is valid and it is really officer McBurley, you didn't ask for officer McBurley. You asked for Lindsey Smith. You immediately know something is different than you expected. If you don't trust the police, then you're going to be nervous now, right?

Different scenarios:

If you try to spoof DNS replies (i.e. http://www.google.com = 192.168.1.1) then in the above analogy, Officer McBurley would show up with his own (valid) ID, but speak in an obviously-fake female voice "Hi, I'm officer Lindsey Smith."

If you make up your own certificate for google.com, it would be as if Officer McBurley hands you a post-it note with a stick-figure drawn where the photo should be, and writing in pencil: "Offissur Lynn Z. Smith (this iz reel poleese badj and not fake)"

Long story short - a hotspot re-direction is EXACTLY the type of thing that SSL is designed to protect users against.
If a browser gives a warning, then it's SSL working as designed.

If you can take someone's request for google and present a different web site to them without anything suspicious happening, then you are doing a man-in-the-middle attack. You could do this for their bank's web page and steal their bank login credentials, etc.

Adding google.* to the walled garden is the best solution to the SSL warning problem that I've seen so far.

No, you can't. You can't impersonate an HTTPS site without either causing a certificate error or getting your own CA certificate onto the client. That's just how HTTPS works.

People don't understand it, i've tried to explain it multiple times in this forum.

The problem not is the people,,, Te problem is MIKROTIK Team,, dont answer never nothing !!!!!

This is not support forum.

The problem not is the people,,, Te problem is MIKROTIK Team,, dont answer never nothing !!!!!

And I think you should convinced by people's guidance ....

I finally tried my own suggestion about issuing a certificate to an IP address, and trusting that certificate, as opposed to a DNS bound certificate... And I'm sad to report that is not a solution.

Even if you are at the actual hotspot IP (not being nat-ed from Google), even if the DNS name corresponds to that same IP... The browser still complains. The only way the certificate works is if it is explicitly issued to that domain or subdomain. What's worse is that setting a wildcard to an entire TLD (e.g. "*.com" or even "*.*") doesn't work... I'm going to guess by design.

There is however good news... sort of...

At least in Windows 8.1, the captive portal always appears by default upon connecting to the network (regardless of the home page set), and the HTTPS version at that (win!). The only way to get the error is to explicitly type another HTTPS site before logging in, or after logging out.

And to solve THAT annoying bit (and perhaps with earlier Windows versions; Assuming they don't do that; I haven't checked)...

Using OpenSSL, it's possible to create certificates that have MULTIPLE alternative names, and thus you can add "google.com", "*.google.com", "facebook.com", "*.facebook.com", and other common HTTPS pages that users specify as their home page, all in addition to the real site name of course. RouterOS however does not support adding multiple alternative names though, and using this feature with OpenSSL directly is a PITA.


There's also an easier alternative... block all HTTPS connections before login, using the following two rules: This is not exactly the best alternative... Users will see an error equivalent to not having internet access, as opposed to being redirected... But that's still more "accurate", in that they indeed don't really have internet yet. If they explicitly type in a site (without a scheme that is), that will result in an HTTP connection, which will in turn be redirected normally, and then (potentially) to the HTTPS login.

Didn't you miss a tiny little bit? You can create certificate containing all *.google.com, *.facebook.com", etc.. But no trusted CA will ever sign it for you. And if you sign in yourself, no user browser will trust it, unless you install your CA into it first.

Didn't you miss a tiny little bit? You can create certificate containing all *.google.com, *.facebook.com", etc.. But no trusted CA will ever sign it for you. And if you sign in yourself, no user browser will trust it, unless you install your CA into it first.

Sounds like an acceptable sacrifice to me.

If access to devices is problematic, you could always instruct your first time users to install the certificate out of the login page itself, perhaps printing the fingerprint on their vouchers or what have you, for the more security cautious.

"Not everyone is so security cautious" I hear you say, and you're right... Most users that aren't would have no problem bringing in their PC to your office when it's just a "one time" configuration, and if you're installing any cables, you'd end up in their home anyway, with access to their device, at which point you could install the CA certificate yourself.


At the end of the day, there's always also the alternative of blocking all other HTTPS, as above.

I give you points for blocking https for unauthenticated users, no connection is better than certificate error. Well, maybe not much better, but at least proper.

But I was under impression that the problem is random Joe Visitor who somehow accesses hotspot and then gets confused, when he receives neither his https homepage, nor hotspot login page. And the goal is to just make it work, so he automatically gets the latter.
If you have to interact with him, you might skip whole juggling with untrusted certificate and simply tell him, that in order to access internet, he must first log in by going to https://hotspot.your-actual-domain-with ... ficate.com (or skip https and save on certificate, if you don't mind credentials going in plaintext over your network).

But I was under impression that the problem is random Joe Visitor who somehow accesses hotspot and then gets confused, when he receives neither his https homepage, nor hotspot login page.

That's not a problem, at least with Windows 8.1, since the HTTPS login page always opens as soon as the user connects.

Again, I don't know about earlier versions.

If you have to interact with him, you might skip whole juggling with untrusted certificate and simply tell him, that in order to access internet, he must first log in by going to https://hotspot.your-actual-domain-with ... icate.com/

My point exactly. At that very point, you can also give install instructions for the CA (or actually do the installation), if you don't have an "official" certificate.

(or skip https and save on certificate, if you don't mind credentials going in plaintext over your network).

There's CHAP even for HTTP, so plaintext is not really the problem...

Still though, a self-signed HTTPS certificate you have to install is better than no certificate at all, because that way, you can guarantee to users they're giving their credentials to the right server. Otherwise, a random rogue DHCP server could come, and intercept everyone's passwords.

Sure, a lot of users won't notice, unless you explicitly tell them to look for the "padlock" icon, but once they learn, they'll be better off.

That's not a problem, at least with Windows 8.1, since the HTTPS login page always opens as soon as the user connects.

And that's with your certificate installed as trusted in client browser or without?

If it's with the certificate, then it won't happen to random visitor (at first access at least), because they won't have it and will get ssl error instead.

It it's without it, then it gets interesting, because the only way how that could happen would be some kind of hotspot detection mechanism in browser. And that's exactly what got me interested in this thread, because someone wrote that it worked for them in IE on Win8.1. But when I tried it here, nothing, always ssl error no matter which browser or OS I tried.

That's not a problem, at least with Windows 8.1, since the HTTPS login page always opens as soon as the user connects.

And that's with your certificate installed as trusted in client browser or without?

If HTTPS is enabled on the hotspot, it goes to it, and if not, to HTTP, regardless of whether the certificate is trusted or not.
(But never to the user's homepage, regardless of whether that homepage is HTTP or HTTPS; That's the important bit)

If the HTTPS certificate of the hotspot itself is not trusted (i.e. is a self signed, non installed certificate), a warning would still be (rightfully) displayed.

If it's with the certificate, then it won't happen to random visitor (at first access at least), because they won't have it and will get ssl error instead.

If your certificate is self signed, yes, as expected by design.

If it is issued by a trusted authority, they won't get an error.

So yeah, if you care too deeply about random unregistered users passing by the login page, and want to make them feel safe, rather than alerted and/or confused, you'll want to get your certificate from a trusted authority, and block other HTTPS requests, to minimize "exposure" to certificate errors.

I personally wouldn't be too worried even with a self signed certificate. Most people would, despite the strongly worded warning messages in browsers, click through such warnings, at least out of curiosity (coupled with the fact that they won't have internet access, so it's not like they feel they have anything to "loose"). As long as the login page contains your phone and a link to the CA certificate, people can always call you (and be like "I just stumbled on your web site, and would like to get internet access, but... uhm... It's giving me some creepy warnings... What? That's NORMAL?!"), and be told the signature the certificate should have, so that they can be sure they're importing the right CA certificate (rather than a rogue CA certificate to a rogue hotspot server).

If someone would ask me to install a CA just to get rit of a warning i would not use that Hotspot at all. It shows me that the operator of the hotspot has no sense for security. From a security point of view installing random CAs is very dangerous.

Think of a person who is travailing a lot, (s)he would end up with dozens of hotspot CAs added to the browser/system. All these CAs can be abused for man in the middle attacks. We have already enough problems as even the "real" CAs to get compromised sometimes. How can you expect that the manual added "hotspot" CAs are safe?

As Sob already mentioned the right way to do it is to tell your customers to browse to https://hotspot.you-company.com rather than telling them to install your creepy CA.

If someone would ask me to install a CA just to get rit of a warning i would not use that Hotspot at all. It shows me that the operator of the hotspot has no sense for security. From a security point of view installing random CAs is very dangerous.

A "random" one, sure. But one that you know belongs to the party you're communicating with, and have verified by other means (e.g. phone or "physical" confirmation by the very person registering you) is not any less secure.

Inconvenient, yes, but not less secure... Assuming the operator you call is knowledgeable enough to tell you the fingerprint, and tell you to look for it, as opposed to them saying "Just click Install, Next, Next, Next, OK"... And yes, I realize few hotspot operators would go to that length, but that's not a technological problem - it's a human problem.

Think of a person who is travailing a lot, (s)he would end up with dozens of hotspot CAs added to the browser/system.

And would have dozens of different hotspot accounts by dozen of different providers? Sounds like installing a random CA is the least of such a person's problems, security wise...

All these CAs can be abused for man in the middle attacks. We have already enough problems as even the "real" CAs to get compromised sometimes. How can you expect that the manual added "hotspot" CAs are safe?

By virtue of being used by fewer people, fewer attackers would target the PCs where you keep your CA's private key. => The fewer people you have, the more secure a custom CA is compared to preinstalled ones.

Now, if you're already a very big ISP with a very big subscriber base that's like a monopoly in an entire state area... It's about time you get yourself a certificate from a trusted authority, and in fact, at that point, you may as well make it an EV one. For small ISPs, price is a big factor, but big ones have no excuse.

As Sob already mentioned the right way to do it is to tell your customers to browse to https://hotspot.you-company.com rather than telling them to install your creepy CA.

I agree it's the better way.

But it's not "the only" right way. If the price of the certificate is a big limiting factor, installing CA is a secure way to eliminate the cost... At the expense of the process being less convenient.

And yes, as a customer, if there are multiple ISPs in an area, all using hotspot, I would prefer to register with the one that doesn't require a CA installation. If multiple ones have such certificates, I would prefer one with an EV certificate at that...

But that is only if I have access to all such ISPs from my area. If I don't, I wouldn't care - I would pick the one I have access to (regardless of requirements), or if I have access to multiple, all requiring a CA installation, I'd pick the one who's office is closest, all other things being equal.

A "random" one, sure. But one that you know belongs to the party you're communicating with, and have verified by other means (e.g. phone or "physical" confirmation by the very person registering you) is not any less secure.

Just because i communicating with you as the party who offers me internet access via a hostspot makes you not trustworthy enough to accept you as a CA. As you are operating the network between me and the internet you could easily do a man in the middle attack, therefore you're one of the last partys i should accept as a trusted CA.

Inconvenient, yes, but not less secure... Assuming the operator you call is knowledgeable enough to tell you the fingerprint, and tell you to look for it, as opposed to them saying "Just click Install, Next, Next, Next, OK"... And yes, I realize few hotspot operators would go to that length, but that's not a technological problem - it's a human problem.

You can tell me the fingerprint of your certificate for hotspot.your-campany.com and i could add that to my browser. No need to trust your CA certificate which can sign every other certificate.

But it's not "the only" right way. If the price of the certificate is a big limiting factor, installing CA is a secure way to eliminate the cost... At the expense of the process being less convenient.

For your hotspot login you don't need an EV certificate. You just need a just need a cert which proves you own hotspot.your-company.com such certificates you can get for less than $5 per year.

It's not the only way, i agree. If the users have to get in connect with you anyway you could just handout username/password and use 802.1x. 802.1x also has the benefit that the wireless traffic of you customers is encrypted.

You can tell me the fingerprint of your certificate for hotspot.your-campany.com and i could add that to my browser. No need to trust your CA certificate which can sign every other certificate.

AFAIK, if the hotspot certificate is signed by my CA, you need to add the CA too.

Unless I'm missing something, and you could just add that one certificate and its chain, without trusting every other thing its CA has signed.

If browsers allow for that, then yes, it's better to go for that. I'm not sure if they allow for that though...

EDIT: OK, I checked... IE11 for one doesn't let you do that (or I'm not seeing how). You need to add some certificate as a root CA. Even if the certificate is a single self signed certificate (one that is explicitly tied to your hotspot page, and isn't tied to a separate CA certificate), that certificate must still be able to act as a root CA, meaning that if you trust that certificate, you're also trusting any other certificates it might sign. I don't see a way to only trust specific certificates signed by the root CA.

For your hotspot login you don't need an EV certificate. You just need a just need a cert which proves you own hotspot.your-company.com such certificates you can get for less than $5 per year.

From where? The cheapest certificates I've seen are more around $11 a year... Which admittedly is not prohibitively expensive either, but still.

EDIT: Found one, if you pay for 3 years together... Which is reasonable. I'm even more impressed by the EV certificates price though... The cheapest one I've seen before are about 2.5 times as expensive. Their EVs are still prohibitively expensive for my relatively small network, but yeah, an EV is not a "must" anyway, just a "nice to have".

If the users have to get in connect with you anyway you could just handout username/password and use 802.1x. 802.1x also has the benefit that the wireless traffic of you customers is encrypted.

For WiFi, yes. I agree. Hotspot in general is not as good of a solution as WPA2-EAP.

It is however good for wired connections, hence my earlier comment about you having access to user's computers when you get cables on their premises the first time around (and installing the certificates then).

AFAIK, if the hotspot certificate is signed by my CA, you need to add the CA too.

Unless I'm missing something, and you could just add that one certificate and its chain, without trusting every other thing its CA has signed.

If browsers allow for that, then yes, it's better to go for that. I'm not sure if they allow for that though...

EDIT: OK, I checked... IE11 for one doesn't let you do that (or I'm not seeing how). You need to add some certificate as a root CA. Even if the certificate is a single self signed certificate (one that is explicitly tied to your hotspot page, and isn't tied to a separate CA certificate), that certificate must still be able to act as a root CA, meaning that if you trust that certificate, you're also trusting any other certificates it might sign. I don't see a way to only trust specific certificates signed by the root CA.

I have to admit i don't know how that is in IE. I'm not a Windows person at all. In Firefox i'm 100% sure it's possible. But i would be a bit shocked if you only can add self signed certs in a way you give full trust to it.

From where? The cheapest certificates I've seen are more around $11 a year... Which admittedly is not prohibitively expensive either, but still.

EDIT: Found one, if you pay for 3 years together... Which is reasonable. I'm even more impressed by the EV certificates price though... The cheapest one I've seen before are about 2.5 times as expensive.

Last time a checked, as i needed a cheap cert for a project, i found a few <$5/year offers. Ok as you mentioned they where all for at least 3 years. If you look for 1 year certs i think we talk about around $10/year. Still not that much money.

It is however good for wired connections, hence my earlier comment about you having access to user's computers when you get cables on their premises the first time around (and installing the certificates then).

Why not use PPPoE on wired connections or have vlans?

Why not use PPPoE on wired connections or have vlans?

How can users be certain they're not connecting to a rogue PPPoE server? Last I checked, PPPoE supports encryption, but no certificates.

I now looked a little closer, and it seems Windows at least supports PPPoE with EAP, meaning that there's a way for a client to demand a particular certificate, but not only is setup not as trivial (or so it seems; It's not occurring at a wizard, just an extra option in the properties, post creation), but there's a bigger problem: RouterOS doesn't seem to support that at all.

But if we're talking just "in principle"... Yes, I believe a combined approach of PPPoE-EAP, WPA2-EAP and HTTPS-Hotspot is the best combo. That last one being useful for devices that may not support the former two for one reason or another. Also, as a means to advertise in front of randomly connected wireless clients (over a separate, unencrypted virtual AP).

Now if only User Manager supported EAP, and RouterOS supported PPPoE-EAP...

I have to admit i don't know how that is in IE. I'm not a Windows person at all. In Firefox i'm 100% sure it's possible. But i would be a bit shocked if you only can add self signed certs in a way you give full trust to it.

Yes. I just checked it too, and it's there indeed. Chrome however uses the OS' certificate store, as does IE, and that option is missing from there.

(One more thing to add to the list of reasons Firefox is the best browser for power users...)

How can users be certain they're not connecting to a rogue PPPoE server? Last I checked, PPPoE supports encryption, but no certificates.

Usually you can achieve it with port-isolation on your switch.

I now looked a little closer, and it seems Windows at least supports PPPoE with EAP, meaning that there's a way for a client to demand a particular certificate, but not only is setup not as trivial (or so it seems; It's not occurring at a wizard, just an extra option in the properties, post creation), but there's a bigger problem: RouterOS doesn't seem to support that at all.

But if we're talking just "in principle"... Yes, I believe a combined approach of PPPoE-EAP, WPA2-EAP and HTTPS-Hotspot is the best combo. That last one being useful for devices that may not support the former two for one reason or another. Also, as a means to advertise in front of randomly connected wireless clients (over a separate, unencrypted virtual AP).

Now if only User Manager supported EAP, and RouterOS supported PPPoE-EAP...

The problem is most home routers do not support PPPoE-EAP.

Usually you can achieve it with port-isolation on your switch.

It would be too expensive to have the entire network with managed switches (i.e. ones that would support this).

The problem is most home routers do not support PPPoE-EAP.

Yeah, that one's a (separate) big problem too.

So in practice, the perfect combo is more like PPPoE-PAP/CHAP (for home routers; sadly, they're an important factor too, and yet at that point, those users would essentially have to take the risk...), PPPoE-EAP (for Windows PCs and the few routers that might support this), WPA2-EAP (for WiFi enabled devices), HTTPS-Hotspot (for everyone else; notably WiFi guests).

It would be too expensive to have the entire network with managed switches (i.e. ones that would support this).

All my cheap TP-Link managed switches have such feature. As far as i can see the Mikrotik CRS support it as well. Even with a RB2011 using the switch rule table you can ensure that a client ports can only talk (pppoe) towards the router and not towards other clients. If you are afraid of users doing bad things like a fake pppoe-server on the network you need a managed switch anyway. Think about arp spoofing, dhcp spoofing, floods, etc.

But maybe even these devices are to expensive for someone who would not spend 5-10$ for a certificate?

So in practice, the perfect combo is more like PPPoE-PAP/CHAP (for home routers; sadly, they're an important factor too), PPPoE-EAP (for Windows PCs and the few routers that might support this), WPA2-EAP (for WiFi enabled devices), HTTPS-Hotspot (for everyone else; notably WiFi guests).

From my point of view hotspot is only nice if you offer a open WiFi where the user get the login page and can directly buy/signup without any interaction with the operator. But you miss encryption on the WiFi and in 2015 even a 12 year old script kiddy can sniff unencrypted wifi-traffic.

If you are afraid of users doing bad things like a fake pppoe-server on the network you need a managed switch anyway. Think about arp spoofing, dhcp spoofing, floods, etc.

I'm personally not "too" afraid in all honesty, hence my reluctance to needlessly spend a lot of money on that. But if it can be done with little to no monetary cost, I'm all for it, willing to invest the time and effort to set it up, and maintain it.

If anything, I'm afraid users will plug their cables the wrong way on their new home router, resulting in an unintentional rogue DHCP server, but that's the kind of problem PPPoE, even a plain one, can solve.

All my cheap TP-Link managed switches have such feature.

How cheap? Which models? I can't find an 8 or 16 port managed switch worth a 2 figure sum. Only unmanaged ones.

Replacing 1 is fine. But I have more like nearly two dozen. Replacing all of them is too much, especially if, like a lot of my existing routers, they are bricked at the first electrical surge and/or lightning storm.

But maybe even these devices are to expensive for someone who would not spend 5-10$ for a certificate?

For my network, I'm willing to pay that for a certificate. But I install other networks for others (mostly offices), where customers may not want to pay even that (i.e. they think of my work as a "one time thing" rather than "a recurring service"), and yet want the same features.

From my point of view hotspot is only nice if you offer a open WiFi where the user get the login page and can directly buy/signup without any interaction with the operator.

That's the ultimate goal I'd like to eventually reach with my network. It's a little further off though, as online payments aren't exactly popular where I live, and SMS payments, while more embraced, are an extra cog to be set up after everything else is ready.

But you miss encryption on the WiFi and in 2015 even a 12 year old script kiddy can sniff unencrypted wifi-traffic.

Amen.

How cheap? Which models? I can't find an 8 or 16 port managed switch worth a 2 figure sum. Only unmanaged ones.

I'm using the "jetstream" devices. For example TL-SG3210 8x Cupper + 2xSFP ~100€. It looks even the "smart switches" have port isolation. At least i found it in the manual of the TL-SG2008

Replacing 1 is fine. But I have more like nearly two dozen. Replacing all of them is too much, especially if, like a lot of my existing routers, they are bricked at the first electrical surge and/or lightning storm.

Have you so many lightning storms in you area? Maybe you need to review your grounding concept? I always ask my electrician how to do proper grounding at a place.

For my network, I'm willing to pay that for a certificate. But I install other networks for others (mostly offices), where customers may not want to pay even that (i.e. they think of my work as a "one time thing" rather than "a recurring service"), and yet want the same features.

That's obviously a problem if the customer is not willing to pay. Who is maintaining their network afterwards if your work is a "one time thing" for them?

If i would offer hotspot wifi solutions i would offer es as a full service with a monthly fee. And then just tunnel everything from the APs to my datacenter.

I'm using the "jetstream" devices. For example TL-SG3210 8x Cupper + 2xSFP ~100€. It looks even the "smart switches" have port isolation. At least i found it in the manual of the TL-SG2008

Yeah, too much for all switches... Somewhat bearable if I had just 2 or 3 in the entire network, at key junctions.

Have you so many lightning storms in you area? Maybe you need to review your grounding concept? I always ask my electrician how to do proper grounding at a place.

At least twice a year, usually at summer time, where each time, at least 4 go down.

Due to... let's call it "territorial disputes"... sometimes it's just physically impractical to do grounding well.

During the rest of the year, sometimes, the local electricity provider will do maintenance unannounced, or will have outages in their old grid that cause large electrical surges that fry not just switches, but even tower PCs that are plugged in, or more often their LAN cards.

And unlike ISPs, I can't choose my electricity provider. They're a regional (well... a 1/3rd of the country to be precise) monopoly.

In fairness, last year, I haven't had a single such outage (I mean, there were some shutdowns, but no damaging surges), but I consider this more of a statistical anomaly than a sign of electrical grid stability.

That's obviously a problem if the customer is not willing to pay. Who is maintaining their network afterwards if your work is a "one time thing" for them?

I do, but only when they need me to, and they pay per visit (or per hardware piece, if needed), rather than per month. Requirements change often (like, as soon as a device is introduced for one reason or another), so this suits me, as much as it suits them (as they don't feel "shackled" to me, giving them a sense of "flexibility"; The fact this feeling is more of an illusion is something that so far, only one client found out the hard way ).

Our company does offer an annual subscription model, where each visit and configuration change is free for the entire year, and only hardware is paid for in addition, and only if necessary and with explicit approval by the client each time. Before the crash of 2008, we had a few customers who subscribed to that (including said 1 customer above), but after that, pretty much everyone decided this is not for them, and they want to cut ties... Only to then bring us back, "just this once!", a few times throughout the year, which for some of them resulted in more expenses (i.e. higher annual profit for us), soooo... We'll let them figure it out, reminding them we offer the annual subscription for when they're ready.

If i would offer hotspot wifi solutions i would offer es as a full service with a monthly fee. And then just tunnel everything from the APs to my datacenter.

Well, I haven't previously deployed hotspot solutions... I've done mostly DHCP and static setups, often with one or few APs involved in the mix... So this is certainly an interesting idea. Hadn't thought about it.

The only problem I see with it on first inspection is the electric grid... If my neighborhood network goes down, users in the neighborhood will understand, but one on the other side of the city, where it all looks fine on the surface, will be extremely pissed, and rightfully so.

AFAIK, if the hotspot certificate is signed by my CA, you need to add the CA too.

You can manually trust individual certificates if they're not signed by a CA you recognise. If you trust a CA, however, it can sign certs for *anything* which is what jaykay2342 was worrying about.

The cheapest certificates I've seen are more around $11 a year... Which admittedly is not prohibitively expensive either, but still.

StartCom do free SSL certs which I think are limited to one per domain. Also there's this Cisco/Mozilla CA project in the works [the name of which escapes me] that will issue free certs soon.

Their EVs are still prohibitively expensive for my relatively small network, but yeah, an EV is not a "must" anyway, just a "nice to have".

The trusted CA model is so broken that in my opinion, EV is just fiddling around the edges. About the only purpose I can see to it is to extract a bit more money from people who buy certs [and I can see why CAs would want to do this, when you can get a cert for either $0 or $10].

You can manually trust individual certificates if they're not signed by a CA you recognise. If you trust a CA, however, it can sign certs for *anything* which is what jaykay2342 was worrying about.

StartCom do free SSL certs which I think are limited to one per domain. Also there's this Cisco/Mozilla CA project in the works [the name of which escapes me] that will issue free certs soon.

StartCom free SSL certs are not for business use. The free certs CA you mean is called letsencrypt https://letsencrypt.org/

The trusted CA model is so broken that in my opinion, EV is just fiddling around the edges. About the only purpose I can see to it is to extract a bit more money from people who buy certs [and I can see why CAs would want to do this, when you can get a cert for either $0 or $10].

Full ack on that, maybe dnssec+dane can fix/replace the CA model. But i'm sure it will not happen in the near future.

You can manually trust individual certificates if they're not signed by a CA you recognise. If you trust a CA, however, it can sign certs for *anything* which is what jaykay2342 was worrying about.

As jaykay2342 later informed me, this is possible in Firefox, after which I found out how to do that.

But... How to do this for IE and Chrome (on Windows)? I certainly don't see such an option with them. Do you?

Not a Solution, But a Work Around

We Walled Garden'd all Google.

Due to the fact that Google is a very popular Homepage, and the fact that although FF and IE will throw up and error - which is ok, due to the nature of connection, however Chrome would not allow continue (assumedly, due to the fact that it would believe google's Cert to always be valid and working), We decided that Bypassing http://www.google.(Whatever) was a suitable solution to an otherwise sticky problem.

Those who do then get to google search free, Image as well, however on click of a website, the get the redirect - and as a large chunk of the web is http - no cert errors (unless dates are having a spaz)

Youtube is not included in the free, gmail is also not free (tested), only thins that start with http://www.google.

Have used in the garden...
http://www.google.com
http://www.google.co.??
http://www.google.com.??
http://www.google.??

From what I gather, google in chrome is the only site to not allow a continue option - other https is "Errored" and allows to "Continue"

It's a little free data - that has saved us roughly 50-60 phone calls this last couple of months

Again, I re-refer to my earlier post. As far as I can tell 80%+ of people have google as a home page. That is why my calls have dropped by over 80%. I now cannot remember the last time I had a call with this issue. This issue becomes more of an issue in chrome due to google not allowing chrome to continue to "psuedo google" if the cert is wrong, and with chrome being one of the big browsers, this came up a lot.

Yes, it allows "free" searching of videos, web and news. However all of these are hosted off google, so when linking, they are re-directed to login, due to the largest proportion of links being http only.

In saying that, I have found it to bug occasionally and not allow through. Particularly after a log out. Can replicate, but hard to track. In saying that, anyone who chooses to log out, can usually read the instructions they have been given . Anyone logged out from a timeout is now getting mac-cookied back in, so are logged in before the web kicks in.

You can manually trust individual certificates if they're not signed by a CA you recognise. If you trust a CA, however, it can sign certs for *anything* which is what jaykay2342 was worrying about.

As jaykay2342 later informed me, this is possible in Firefox, after which I found out how to do that.

But... How to do this for IE and Chrome (on Windows)? I certainly don't see such an option with them. Do you?

If you save the CA certificate as a file on your computer, you can then import it into windows' certificate store.
http://www.cs.virginia.edu/~gsw2c/GridT ... icates.htm

As Troffasky said, trusting certificates can be quite serious. Trusting your OWN certificates is fine so long as you trust yourself not to lose the private key for your private CA. Trusting someone else's CA - well, I would not ever trust a hotspot's CA - They could easily MITM attack at will after that with no warnings. At the very most, I would create a local account on the computer, trust the CA for only that local user, I wouldn't do anything sensitive while using it, and I would remove the CA and account later.

And no - I don't live in a bomb shelter.

If you save the CA certificate as a file on your computer, you can then import it into windows' certificate store.
http://www.cs.virginia.edu/~gsw2c/GridT ... icates.htm

I know about that, but that trusts the certificate for all sites. I was asking if there's the ability to trust a certificate per domain.

If you save the CA certificate as a file on your computer, you can then import it into windows' certificate store.
http://www.cs.virginia.edu/~gsw2c/GridT ... icates.htm

I know about that, but that trusts the certificate for all sites. I was asking if there's the ability to trust a certificate per domain.

There are Name Constraints in x.509. https://tools.ietf.org/html/rfc5280#section-4.2.1.10 but most SSL implementations do not really check it, therefore i would not trust on it.

We have to admit that the ssl/tls trust model is quite broken.

I know about that, but that trusts the certificate for all sites. I was asking if there's the ability to trust a certificate per domain.

I'm sure you can trust an individual certificate. I saw some of my local corporate-only certificates in there as well when I followed along on my own workstation here.

There are Name Constraints in x.509. https://tools.ietf.org/html/rfc5280#section-4.2.1.10 but most SSL implementations do not really check it, therefore i would not trust on it.

limited-scope CA certs would be so much better than wildcard certs. Too bad this isn't done more.

my solution to this long time problem as high percentage of browsers home pages are set to google.com

add this expression to your walled garden in the host field

:^www\.google\.com$ with port 443

now when they are directed to https://google.com the google page will load instead of an error, Better in my opinion than an error. 99 times out of a 100 the user will click on a http link and get the login page.

Anyway to change this so it apply's to any https domain that ends with google.com?

If you select authentication method MAC and MAC as username and password will this prevent them from being forced through the login page until the HTPP cookie lifetime expires?

Seems like if they are idle for a while even if there cookie has not expired it forces them through the login page to verify the cookie and it fails since its https. I wonder if I just add MAC to this it will not need to do that?

Seems like if they are idle for a while even if there cookie has not expired it forces them through the login page to verify the cookie and it fails since its https. I wonder if I just add MAC to this it will not need to do that?

To solve this, just enable the : login by "MAC Cookie" option (in the server profiles-login options). With this option they will be automatically logged in as long as the cookie is active(it will not force them to login page each time the sesion runs out).
This option has saved me a lot of troubles. Without this option it was almost impossible to use the hotspot in a hotel enviroment. Most of the pages are now https, so the guest didnt realize why they suddenly lost connection (as the redirect page would not appear on https and the session had timed out), also many iphone and other devices had problem with getting to the login page at all.

I am a bit in the dark here.

To start the SSL connection, doesn't the browser need first to connect to the server? By sending a request for connection, isn't it visible to the router on port 443 and as result redirected to hotspot login page? What am I missing here?

To start the SSL connection, doesn't the browser need first to connect to the server? By sending a request for connection, isn't it visible to the router on port 443 and as result redirected to hotspot login page? What am I missing here?

When the client wants to connect to https://google.com, the certificate offered must have a common name or subject alt name that includes google.com. If not, a certificate error will be displayed to the user. You can't get a certificate for google.com, so you can't intercept the request and redirect it without the user seeing a certificate error.

To start the SSL connection, doesn't the browser need first to connect to the server? By sending a request for connection, isn't it visible to the router on port 443 and as result redirected to hotspot login page? What am I missing here?

When the client wants to connect to https://google.com, the certificate offered must have a common name or subject alt name that includes google.com. If not, a certificate error will be displayed to the user. You can't get a certificate for google.com, so you can't intercept the request and redirect it without the user seeing a certificate error.

So what is actually happening, is that router does see the initial request from client and does redirect it, but client is not able to get the certificate and thus the browser displays an error, right?
I have not looked at it thoroughly, but this seem to happen only with google as homepage, and not other https pages. If so, what is google doing differently?

Hi Guys,

Finally after long forum reading and googling, I am able to work with SSL and HTTPS sites. I will post all the details after few other test and post a video also if its a 100% success. Finger crossed.

https://youtu.be/gth9SG_O8j0

Hi Guys,

Finally after long forum reading and googling, I am able to work with SSL and HTTPS sites. I will post all the details after few other test and post a video also if its a 100% success. Finger crossed.

https://youtu.be/gth9SG_O8j0

That video didn't show that much how were you doing it. Can you post some details on it? What was the SSL certificate you were using?

Unless you control all the devices connecting to your hotspot, there is no possible way to redirect https traffic to your login page! If such a way existed, it would mean anyone else on the network would be able to intercept and modify https traffic, breaking the security promise that https gives. The only way to make this possible is if you own all the client devices and can install your own root certificate. This way you can force clients to trust your custom root certificate, and using that root, issue your own certificates for google.com, etc. These certificates would only ever work on devices where you installed the root certificate.

This is less and less of an issue these days, as most devices connecting to a hotspot are smart enough to automatically issue a regular http request and if it's redirected, present the user with the login page.

This is less and less of an issue these days, as most devices connecting to a hotspot are smart enough to automatically issue a regular http request and if it's redirected, present the user with the login page.

Not at the moment though, there are still a lot of devices which don't do that, which gives a lot of headache since customers do not care about technical issue, they just want solution. The situation is a bit sad

I was able to get the result in my testing environment. But I want to do a field test and then only put this solution in forum. Please be patient.

Unless you control all the devices connecting to your hotspot, there is no possible way to redirect https traffic to your login page! If such a way existed, it would mean anyone else on the network would be able to intercept and modify https traffic, breaking the security promise that https gives. The only way to make this possible is if you own all the client devices and can install your own root certificate. This way you can force clients to trust your custom root certificate, and using that root, issue your own certificates for google.com, etc. These certificates would only ever work on devices where you installed the root certificate.

This is less and less of an issue these days, as most devices connecting to a hotspot are smart enough to automatically issue a regular http request and if it's redirected, present the user with the login page.

I guaranty you that I am using CA authorized certificate which I bought from Comodo. Not using self-signed certificate.

Hi Guys,

Finally after long forum reading and googling, I am able to work with SSL and HTTPS sites. I will post all the details after few other test and post a video also if its a 100% success. Finger crossed.

https://youtu.be/gth9SG_O8j0

That video didn't show that much how were you doing it. Can you post some details on it? What was the SSL certificate you were using?

Sorry for the video. Actually I was so happy when it worked for me. And I just capture the video as it is. Will post a video once the field test is done.

Hi Guys,

Finally after long forum reading and googling, I am able to work with SSL and HTTPS sites. I will post all the details after few other test and post a video also if its a 100% success. Finger crossed.

https://youtu.be/gth9SG_O8j0

That video didn't show that much how were you doing it. Can you post some details on it? What was the SSL certificate you were using?

Sorry for the video. Actually I was so happy when it worked for me. And I just capture the video as it is. Will post a video once the field test is done.

Your video shows you ignoring the certificate warning (which is caused by 3rd party antivirus TLS interception).

So what is actually happening, is that router does see the initial request from client and does redirect it, but client is not able to get the certificate and thus the browser displays an error, right?

The client always gets a certificate but because the certificate offered doesn't have a common name or subject alt name that includes the requested hostname, an error is detected [because it knows it's not talking to who it thinks it should be].

I have not looked at it thoroughly, but this seem to happen only with google as homepage, and not other https pages. If so, what is google doing differently?

You need to look more thoroughly. No matter how thoroughly you look, you will find that you cannot intercept HTTPS without causing an error

hello there
I've tried to understand the cause of the probleme and i need a help
1- I have a mikrotik hotspot server with the ip address 10.0.0.5 (it's a private address).
2- My hotspot server redirect to an external login page (in the cloud) for users authentications.
3- I'm using socile media API for user authentication so i need SSL certificate for the hotspot .
Could you please help me to get SSL trusted certificate and wich domaine it wil contain .
Best-regards

Use let's ecnrypt willcard.

For example you own the domain myhotspot.com

Create a certificate for *.myhotspot.com using DNS Only mode.
Then you have to add a DNS Record to your hosting provider

Get the .cer .key files and import them

How to get staretd
https://www.ollegustafsson.com/en/letsencrypt-routeros/

Automatic renewal
https://github.com/gitpel/letsencrypt-routeros